Ugly mistake for Pretty Good

"If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography."

-- Bruce Schneier

Pretty Good Privacy (PGP) has a long and colorful history. When it was debuted in 1991 by cryptographer Phil Zimmermann, PGP attracted immediate attention. The notion of public key encryption for the masses achieved instant recognition, not only from privacy advocates, but from the National Security Agency. Over the years, PGP stood as a bulwark for personal privacy amidst the introduction of the US government's Clipper proposal and increasingly expansive wiretapping legislation.

PGP's turbulent political history is coupled with an equally rocky legal history. Complications arising from PGP's use of the RSA Security public key implementation, along with charges that PGP violates the US International Traffic in Arms Regulations, have continually dogged both the program and its author. To stave off these complications, PGP formed strategic partnerships with ViaCrypt and MIT. Then, in 1998, Network Associates Inc. (NAI) acquired PGP.

PGP timeline and brief history: http://www.cypherspace.org/~adam/timeline/

PGP version matrix: http://www.freedomfighter.net/crypto/pgp-history.html

PGP had finally come of age. Its banditware reputation faded into the background, and it quickly achieved legitimacy in the eyes of corporate America. In December 1999, the US government, long PGP's greatest nemesis, granted it an export license. Everything seemed rosy.

However, NAI also happened to belong to the Key Recovery Alliance (KRA), an organization advocating government key escrow. Though NAI disavowed its membership with the KRA in 1997, it has since quietly resumed ties with the organization. To that end, NAI also continued its work with Additional Decryption Keys (ADK) and PGP. ADK, introduced as an alternative to key escrow, was touted as a feature for businesses using PGP. With ADK, a company could add a master key to a user's public key. That way, if an employee left the company, the company could still decrypt that employee's files. What could possibly be wrong with that?

Plenty.

Mailing list debate on NAI/PGP and KRA: http://www.fitug.de/debate/9811/msg00233.html

"The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption," Hal Abelson et al. (1998): http://www.cdt.org/crypto/risks98/

Shortly after ADK's 1998 inclusion into PGP, many in the cryptographic community began voicing concerns regarding its use. The most ominous warnings were contained in Ralf Senderek's evaluation. It read, in part:

"I do not know which mechanism will prevent a user's public key [from being] linked with another faked message recovery key without the user's consent or knowledge."

Two years later, his concern was validated. On August 24, 2000, Senderek discovered vulnerability in PGP version five, and also found six PGP public keys vulnerable to unauthorized ADK modification. Some versions of PGP respond to ADK subpackets in the nonsigned part of the public key data structure, meaning any third party could issue a tampered copy of someone's PGP public key containing their own. Anything encrypted on Jane User's public key would then be encrypted on Joe Intruder's public key, giving Joe access to any private data meant only for Jane's eyes.

"Key Experiments: How PGP Deals with Manipulated Keys," Ralf Senderek (August 2000): http://senderek.de/security/key-experiments.html

"Serious Bug in PGP Versions 5 and 6," Ross Anderson (August 2000): http://cryptome.org/pgp-badbug.htm

As Senderek points out, the problem won't go away until all vulnerable PGP versions are retired, because it's the sender's responsibility to encrypt to the ADK, not the recipient's. Keep in mind that the vast majority of NAI PGP users also use programs such as Microsoft Outlook (already demonstrably insecure, considering the Melissa and ILOVEYOU variants that brought such systems to their knees). It's easy to suppose that such systems would not detect an unauthorized ADK attack if they experienced it.

Fallout from this revelation came swiftly. Amongst the hue and cry over Senderek's report came wholesale PGP keyserver cleansing efforts, along with a sudden groundswell of opposition to PGP's use; those opposed instead favored other public key cryptographic programs such as GNU Privacy Guard (GPG). Even seasoned users of the older versions of PGP questioned its continued use.

"[They] became so preoccupied with whether or not they could that they didn't stop to think if they should," says Ian Malcolm in Jurassic Park.

PGP's philosophy and use is sound; however, NAI sacrificed the core security on which every public key cryptographic system relies in its rush to implement new value-added features. In doing so, it has also risked the hard-won confidence PGP cultivated since it was first distributed across the Internet.

Many, including myself, have abandoned the use of any cryptographic system that does not make its source code freely available. This latest incident only serves to galvanize my stance. While I will continue using NAI's version of PGP as my customers may require, I will only trust the version that I have personally reviewed and compiled. This may seem backward to some, but it is essential to me. In looking back on the events of this past week, I have to concur with Senderek's latest comment:

"This is not a bug, this is a scandal..."