Desktop Email Encryption

 View Only

Why Standards are Necessary for Future-proofing your data security solution 

Aug 18, 2009 01:26 PM

Brian Tokuyoshi - Product Marketing Manager

I recently met with a customer who was concerned about his data retention policies. He’s responsible for a number of servers and data on mainframes, and he fully supports the idea of doing encryption to keep it safe.

This particular customer understands the  value of using open standards for encryption. He said the following to me. “We’re encrypting data and backing it up. So let me ask you what you think, you backup the data, you backup the key, but do you backup the application?” That’s a problem that never occurred to me, because PGP Encryption Platform applications use the OpenPGP standard. Files encrypted with PGP software can be decrypted with other software that supports the OpenPGP standard, as long as you have the key and the ciphertext.

The problem my customer discovered is that many encryption solutions do not encrypt data with an open standard. In fact, even with the key, you still need to have the application in order to decrypt the data.

So suppose your data retention policy requires keeping backup tapes for 10 years. That’s a long time, imagine trying to recover a 10 year old tape today? That’s hard enough even if the data wasn’t encrypted. If it was encrypted, and it used proprietary encryption, then getting the application to run could pose a significant road block. Perhaps the original company is no longer in business. Do you still have a copy of the application that created it? Do you have the supported OS and will it run on the hardware that you have? Getting these factors wrong could spell the difference between what you thought was recoverable data to yet another scenario where the data is forever lost when you thought it was preserved.

Don’t make the same mistake, and test this scenario out for yourself. Can you recover your encrypted data if you have the key but not  the application that encrypted it? You may be surprised with what you find out.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Oct 25, 2010 03:51 PM

Thank you, Mr. Tokuyoshi, that was an excellent blog article. However, my personal experience with PGP Desktop 10 leaves me a bit puzzled regarding PGPD10's adherence to the OpenPGP standard.
I am finding that key pairs from PGPD10 cannot be accessed by at least one other OpenPGP compatible product, resulting in the potential inability to access and use the keys due to password failure. In particular, I have tried this with the Enigmail OpenPGP add-on to Mozilla's Thunderbird 3.1.5 email client. Enigmail claims, just as PGP claims, to support the OpenPGP standards.
What I am finding is that passwords and keys generated by Enigmail work just fine in PGP, but not the other way around. Keys generated by PGPD10 constantly fail during password access with errors about algorhythms for certain PGP features not supported. This situation has the potential to create precisely the type of data-retention disaster you address in your article.
Please understand, I am not a student of OpenPGP standards, so there may be another reason for the issue I'm experiencing. However, I would fully expect any keys generated by PGPD10 to work on any other OpenPGP supported product, as your blog article suggests. Now, assuming my fairly limited understanding of OpenPGP compatibility standards is correct, can you please clarify and confirm that, under current normal circumstances, key pairs and passwords generated by PGP Desktop 10 will be accessible on any other key management product that truly adheres to OpenPGP standards?
Furthermore, if the password failure I'm encountering seems to indicate some malfunction of what should otherwise be normal interoperability between PGPD10 and other OpenPGP products, then I would appreciate knowing that information so I may resolve the issue.
Kind regards,
MrPisky

Related Entries and Links

No Related Resource entered.