Misconceptions about PGP 2.6 from MIT

-----BEGIN PGP SIGNED MESSAGE-----

To:   All Users of PGP
~From: Philip Zimmermann, creator of PGP
Re:   Misconceptions about PGP 2.6 from MIT
~Date: 18 Aug 94

I'd like to clear up some widely held misconceptions about PGP version 2.6 from MIT. I get a lot of email and phone calls from people who report a lot of misinformation on many Internet newsgroups about this MIT version of PGP.

(For those of you who need an introduction to Pretty Good Privacy (PGP), it is a free software package that encrypts email. PGP is the worldwide defacto standard for email encryption. It's available via FTP from net-dist.mit.edu, in the pub/PGP directory. But then, if you haven't heard of PGP, you don't need to read this letter.)

Here is a list of misconceptions:

Myth #1: PGP 2.6 is incompatible with previous versions.
Myth #2: PGP 2.6 is weaker than previous versions, with a back door.
Myth #3: PGP 2.6 was released without Zimmermann's cooperation.

All of these misconceptions would be cleared up if you read the PGP User's Guide that comes with PGP 2.6, but a lot of people seem to be spreading and believing these myths without looking into the matter empirically and getting the new PGP and reading the manual. Let's go over these myths in detail.

Myth #1: PGP 2.6 is incompatible with previous versions.

This is untrue. PGP 2.6 will ALWAYS be able to read stuff from earlier versions.

PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4, or 2.5. However, because of a negotiated agreement between MIT and RSA Data Security, PGP 2.6 will change its behavior slightly on 1 September 1994, triggered by a built-in software timer. On that date, version 2.6 will start producing a new and slightly different data format for messages, signatures and keys. PGP 2.6 will still be able to read and process messages, signatures, and keys produced under the old format, but it will generate the new format. This change is intended to discourage people from continuing to use the older (2.3a and earlier) versions of PGP, which Public Key Partners contends infringes its RSA patent (see the section on Legal Issues). PGP 2.4, distributed by Viacrypt (see the section Where to Get a Commercial Version of PGP) avoids infringement through Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and 2.6 avoid infringement by using the RSAREF(TM) Cryptographic Toolkit, under license from RSA Data Security, Inc.

According to ViaCrypt, which sells a commercial version of PGP, ViaCrypt PGP will evolve to maintain interoperability with new freeware versions of PGP, beginning with ViaCrypt PGP 2.7.

It appears that PGP 2.6 has spread to Europe, despite the best efforts of MIT and myself to prevent its export. Since Europeans now seem to be using version 2.6 in Europe, they will have no problems maintaining compatability with the Americans.

Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. Canadians may use PGP without using RSAREF, and there are legal ways to export PGP to Canada. In environments where RSAREF is not required, it is possible to recompile the same PGP source code to perform the RSA calculations without using the RSAREF library, and re-release it under the identical licensing terms as the current standard freeware PGP release, but without the RSAREF-specific restrictions. The licensing restrictions imposed by my agreement with ViaCrypt apply only inside the USA and Canada. It seems likely that any versions of PGP prepared outside the US will follow the new format, whose detailed description is available from MIT. If everyone upgrades before September 1994, no one will experience any discontinuity in interoperability.

Some people are attracted to PGP because it appeals to their rebellious nature, and this also makes them resent anything that smacks of "giving in" to authority. So they want to somehow circumvent this change in PGP. Even though the change doesn't hurt them at all. I'd like to urge them to think this one through, and see that there is absolutely no good reason to try to get around it. This new version is not "crippled" -- in fact, it is the old versions that are now crippled. I hope that PGP's "legalization" does not undermine its popularity.

This format change beginning with 2.6 is similar to the process that naturally happens when new features are added, causing older versions of PGP to be unable to read stuff from the newer PGP, while the newer version can still read the old stuff. All software evolves this way. The only difference is that this is a "legal upgrade", instead of a technical one. It's a worthwhile change, if it can achieve peace in our time.

Future versions of PGP now under development will have really cool new features, some of which can only be implemented if there are new data format changes to support them. Like 2.6, the newer versions will still read the older stuff, but will generate new stuff that the old versions can't read. Anyone who clings to the old versions, just to be rebellious, will miss out on these cool new features.

There is a another change that effects interoperability with earlier versions of PGP. Unfortunately, due to data format limitations imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or signatures made with PGP version 2.2 or earlier. Since we had no choice but to use the new data formats, because of the legal requirement to switch to RSAREF, we can't do anything about this problem for now. Not many people are still using version 2.2 or older, so it won't hurt much.

Beginning with version 2.4 (which was ViaCrypt's first version) through at least 2.6, PGP does not allow you to generate RSA keys bigger than 1024 bits. The upper limit was always intended to be 1024 bits -- there had to be some kind of upper limit, for performance and interoperability reasons. But because of a bug in earlier versions of PGP, it was possible to generate keys larger than 1024 bits. These larger keys caused interoperability problems between different older versions of PGP that used different arithmetic algorithms with different native word sizes. On some platforms, PGP choked on the larger keys. In addition to these older key size problems, the 1024-bit limit is now enforced by RSAREF. A 1024-bit key is very likely to be well out of reach of attacks by major governments. In some future version, PGP will support bigger keys. This will require a carefully phased software release approach, with a new release that accepts larger keys, but still only generates 1024-bit keys, then a later release that generates larger keys.

Myth #2: PGP 2.6 is weaker than previous versions, with a back door.

This is not true. I would not allow MIT or anyone else to weaken PGP or put a back door in. Anyone who knows me will tell you that.

This is not to say that PGP doesn't have any bugs. All versions have had bugs. But PGP 2.6 has no known bugs that have any net effect on security. And MIT should be releasing a bug-fixed version of PGP 2.6 Real Soon Now.

Myth #3: PGP 2.6 was released without Zimmermann's cooperation.

Well, that's not true, either. Or I wouldn't be telling you all this.

MIT did not steal PGP from me. This was a joint venture by MIT and myself, to solve PGP's legal problems. It took a lot of manuevering by me and my lawyers and by my friends at MIT and MIT's lawyers to pull this off. It worked. We should all be glad this came off the way it did. This is a major advance in our efforts to chip away at the formidable legal and political obstacles placed in front of PGP; we will continue to chip away at the remaining obstacles.

I hope this clears up the myths about PGP 2.6. I urge all PGP users to upgrade to the new version before September. And I urge you all to use the official 2.6 release, not anyone else's incompatible bastardized mutant strain of PGP. Please pass the word around, and help dispel these misguided rumors. This letter may be (and should be) quickly reposted to BBS's and all appropriate newsgroups.

--Philip Zimmermann

pannier@cs.tu-berlin.de