-------------------------------------------------------------------------------
Questions and Answers
about MIT's Release of PGP 2.6
by
Hal Abelson, Jeff Schiller, Brian LaMacchia, and Derek Atkins
June 2, 1994
Q: Is PGP 2.6 an official release from MIT?
A: Yes. PGP 2.6 is distributed via the Internet to non-commercial
U.S. users by MIT Information Systems, via anonymous ftp from
net-dist.mit.edu in the directory pub/PGP. Planning for the PGP 2.6
release was conducted with the knowledge and approval of the MIT
administration. The MIT News Office officially announced the
availability of PGP 2.6 in a press release dated May 26, 1994.
***
Q: Was PGP 2.6 released in cooperation with RSA Data Security, Inc.?
A: Yes. PGP 2.6 uses the RSAREF(TM) Free Cryptographic Toolkit
(Version 1) licensed by RSADSI. RSADSI has granted MIT permission to
access the non-published routines in RSAREF required to support PGP.
***
Q: Was Phil Zimmermann involved in the PGP 2.6 release?
A: Yes. Zimmermann has been fully involved in the release process.
In addition, he approved all code changes from earlier versions of
PGP and updated the PGP documentation for version 2.6.
***
Q: Can PGP 2.6 interoperate with previous versions of PGP?
A: Not completely. There are two different incompatibilities between
PGP 2.6 and earlier versions of PGP. The first incompatibility is a
deliberate format change that will trigger on September 1, 1994. The
intent of this change is to discourage PGP users in the U.S. from
using PGP 2.3a, which potentially infringes patents. The second
incompatibility is that PGP 2.6 requires signatures to be in PKCS
format, which has been the default since PGP 2.3, although PGP 2.3
was able to process non-PKCS signatures.
***
Q: What's the effect of the September 1 format change? Will I still
be able to use my old keys? Will I still be able to decrypt old
messages?
A: Both now and after September 1, PGP 2.6 will decrypt messages and
uses keys generated by PGP 2.3a. To quote from the PGP 2.6 manual:
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 read and
process messages, signatures, and keys produced under the old
format, but it will generate the new format.
***
Q: What about the PKCS requirement?
A: PKCS Stands for Public Key Cryptography Standards and is a
voluntary standard created by RSA Data Security and several industry
leading organizations, including MIT. PKCS specifies standard
encodings for encrypted and signed objects as well as some key
formats. The standard documents themselves may be obtained via
anonymous FTP from rsa.com.
Starting with PGP version 2.3, PGP signatures have conformed to the
PKCS signature standard. Although PGP version 2.3 generated PKCS
format signatures, it was capable of understanding the non-PKCS format
generated by PGP 2.2 and earlier versions. PGP 2.6 removes this
compatibility code. This makes some of the PGP 2.6 code cleaner and
ensures compatibility with future versions of RSAREF and other future
standard software. Making the change now also encourages people to
obtain fresh signatures on their keys, which is a prudent thing to do
every so often.
Note: The PKCS requirement has nothing to do with the September 1 PGP
format change. It is an independent decision of the PGP development
team.
***
Q: Is there a technical reason for the September 1 format change?
A: No. The format change is being made for legal reasons, not
technical reasons. MIT wanted to bring out a version of PGP that
would have the support of RSADSI. RSADSI would not lend their support
to a product that fully interoperates with PGP 2.3, which, when used
in the United States, potentially infringes patents licensed to them
by Stanford and MIT. The intent of this format change is to
discourage people from continuing to use the earlier software, which
will mitigate the patent-caused problems that have hampered use of PGP
within the U.S. The time delay between now and September is to give
people adequate time to upgrade to the new software.
***
Q: Does using RSAREF make PGP 2.6 run more slowly than previous
versions of PGP?
A: No. The speed-critical portions of PGP 2.6 use the same
multi-precision integer libraries as in PGP 2.3a. We have noticed no
appreciable speed difference between PGP 2.3a and PGP 2.6 on any of
the platforms we have tried. If you observe a performance problem
with PGP 2.6, please send details to pgp-bugs@mit.edu. Be sure to
tell us what platform and compiler you are using.
***
Q: Is there a back door in PGP 2.6?
A: No. You need not take our word for it. PGP is distributed in
source code, so that you can verify its integrity yourself, or get
someone you trust to verify it for you. The 2.6 MSDOS executable file
that we distribute has been digitally signed, so you will know that it
has not been tampered with. In general, you should be wary of using
encryption programs that you receive as object code, whose origin you
cannot authenticate.
***
Q: Why is PGP 2.6 limited to 1024-bit keys? Does this compromise the
security of PGP 2.6?
A: To quote from the PGP 2.6 manual:
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. 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.
Cracking a 1024-bit key is far beyond any publicly known computational
capability. The table below, originally posted to Usenet in October,
1993, gives some numbers for the expected amount of work required to
crack keys of various sizes. The prediction for RSA129, which was
finally factored in April, 1994, was very close to the actual time
required. (The time was about 5000 MIPS-years, depending on your
definition of a MIPS.)
RSA129 (429 bits): 4,600 MIPS-YEARS
a 512 bit key 420,000 MIPS-YEARS (safe for a little while!)
a 700 bit key 4,200,000,000 MIPS-YEARS (seems pretty safe to me!)
a 1024 bit key 2.8 x 10^15 MIPS-YEARS (Wow!)
The above table is based on the Multiple-Polynomial Quadratic Sieve
(MPQS). Other algorithms under development may have slightly better
performance.
The bottom line is that cracking a 1024-bit key using anything like
presently known factoring methods will probably not happen within the
lifetime of anyone reading this FAQ at the time of this writing
(1994). A breakthrough in computer technology or algorithm efficiency
that threatens a 1024 bit key is likely to be so powerful that it will
threaten much larger keys as well, and then all bets are off!
Any successful attack on PGP with large key sizes is more likely to
come from exploiting other aspects of the system (such as the prime
number generation algorithm) than by brute-force factoring of keys.
Given this, it is not at all clear that key sizes larger than 1024
bits provide increased security in any practical sense.
Nevertheless, RSADSI has granted MIT permission to modify RSAREF to
increase the key size, and larger keys will be supported in a future
PGP release. These larger keys, however, will not be manipulated by
PGP 2.6 and earlier releases, so users will need to upgrade in order
to use them.
***
Q: There is no patent problem with using PGP 2.3a outside the U.S.
Isn't it offensive to impose a change on PGP users around the world
to accommodate a legal problem in the U.S.?
A: To quote from the PGP 2.6 manual:
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. Hopefully,
implementors of PGP versions outside the US will also switch
to the new format, whose detailed description is available
from MIT. If everyone upgrades before 1 September 1994, no
one will experience any discontinuity in interoperability.
We apologize to PGP users outside the U.S. We are asking them to
undergo the inconvenience of making a change to the non-U.S. version
of PGP for no technical reason. We hope that the effect of this
change, which will remove any legal controversy from the use of PGP in
the U.S., will benefit PGP users outside the U.S. as well as within
the U.S.
***
Q: How can PGP users outside the U.S. upgrade, if PGP 2.6 might be
subject to U.S. export controls?
A: The format change that will become effective on September 1, 1994
can be accomplished by a simple modification to the PGP 2.3a code,
which was developed outside the U.S. MIT has published the new format
specification. Consequently, a non-U.S. version of PGP that
interoperates with PGP 2.6 can be produced without the need
for anyone to attempt to export PGP software from the U.S.
***
Q: With this incompatible change, what provisions are being made for
users of ViaCrypt PGP (PGP 2.4) ?
A: ViaCrypt has announced a new release of their product, called PGP
2.7, that supports both the old and new formats. They will also
provide upgrade kits for users for version 2.4. For further
information, contact
Paul E. Uhlhorn
Director of Marketing, ViaCrypt Products
Mail: 2104 W. Peoria Ave
Phoenix AZ 85029
Phone: (602) 944-0773
Fax: (602) 943-2601
Internet: viacrypt@acm.org
Compuserve: 70304.41
***
Q: Does PGP 2.6 use RSAREF version 1, or RSAREF 2.0?
A: PGP 2.6 uses RSAREF version 1. PGP 2.5 used RSAREF version 2.0.
During the discussions that led to the creation of PGP 2.6, RSA Data
Security requested that MIT switch to RSAREF 1. Furthermore, RSADSI
gave MIT formal written permission to make calls to internal program
interfaces in RSAREF 1, consistent with the RSAREF 1 license. From
a technical standpoint, it doesn't matter which version of RSAREF is
used by PGP. The major enhancements to RSAREF 2.0 have to do with
functionality not required by PGP. Also, RSADSI's licensing
restrictions (which require non-commercial use only) are not
significantly different from RSAREF 1 to RSAREF 2. It is possible that
later releases of PGP from MIT may use a different release of RSAREF,
but we see no reason to do so at this time.
***
Q: What is PGP 2.5 and what is its status?
A: MIT initially released PGP 2.5 for beta test on May 9, 1994.
During the beta test period, we continued discussions with RSA Data
Security. These discussions led us to decide to install the September
1 format change, as well to use RSAREF 1 (see question above). PGP
2.5 contained several important bugs that have been fixed in PGP 2.6.
PGP 2.5 does *not* contain the software necessary to understand
messages generated by PGP 2.6 after September 1. We therefore urge all
U.S. users to upgrade to PGP 2.6 (or a subsequent version).
***
Q: What is PGP 3.0?
A: PGP 3.0 is an anticipated upgrade to PGP. Unlike PGP 2.6, PGP 3.0
will be a major rewrite and reconstruction of the PGP internal
software. PGP 3.0 might be ready before the end of 1994, but there
are no specific release plans yet.
***
Q: Will there be further incompatible changes to PGP?
A: Almost certainly. As new features are added, the format of
messages and other data structures will no doubt be changed. For
example, we have considered adding a new packet type for signatures
that places the signature at the end of a signed packet rather then
the beginning. This will permit restructuring the PGP software so
that it can operate in one pass, with no need to create the numerous
temporary files that PGP now creates. This will facilitate
applications that are not now currently possible. For example, a
one-pass PGP could be used to encrypt data to a tape drive during
backup. This cannot be done with PGP today because it would need to
create temporary files that consume almost twice as much disk space as
the data being backed up!
***
Q: Will keys generated prior to PGP 2.6 continue to be usable?
A: Yes. PGP 2.6 will always be able to use keys created by prior
versions. New keys, generated *after* September 1 will *not* be
usable by prior versions of PGP. However we hope that all PGP users
will have upgraded to PGP 2.6 or better (or its non-U.S. equivalent)
by September.
***
Q: Why did MIT release PGP 2.6, when PGP 2.3 is already available?
A: Using PGP 2.3 in the U.S. potentially infringes patents licensed
exclusively to Public Key Partners by Stanford University and MIT.
This sticky patent situation has deterred the spread of PGP, because
many people and institutions did not wish to risk violating
intellectual property restrictions.
MIT has addressed this problem in PGP 2.6 by using RSAREF, which is
licensed by RSA Data Security, Inc. RSADSI acknowledges that PGP 2.6
is a legitimate RSAREF application. The RSAREF license includes
rights to all of the relevant U.S. patents on public key cryptography
for non-commercial use.
***
Q: Will there be version of PGP 2.6 for the Mac?
A: People are working on this, but it's not ready yet. We hope it
will be available within a couple of weeks.
***
Q: Is MIT distributing PGP 2.6 to Canada?
A: No, or at least not yet. There are some legal issues involved,
having to do with possible U.S. export control restrictions, and we're
getting advice on how to deal with these. We hope to sort this out
next week.
***
Q: Who are the people who are working on the PGP 2.6 release?
A: People outside MIT working directly on the 2.6 release are Phil
Zimmermann and Colin Plumb.
People at MIT coordinating the PGP 2.6 release are Jeff Schiller, MIT
Network Manager; Hal Abelson, Prof. of Computer Science and
Engineering; Brian LaMacchia, graduate student in Computer Science;
and Derek Atkins, graduate student in Media Arts and Sciences.
Support from the MIT administration was provided by Jim Bruce, MIT
Vice-President for Information Systems; David Litster, MIT
Vice-President and Dean for Research; Karen Hersey, MIT Intellectual
Property Counsel; and John Preston, MIT Director of Technology
Development.
***
Q: Are there more questions?
A: Certainly. If there are other questions about PGP 2.6 that you
think ought to be answered here, please send us to them (at
pgp-bugs@mit.edu) and we will try to include answers in future versions
of this FAQ.
-------------------------------------------------------------------------------
Compilation Copyright (c) 1994 by the Massachusetts Institute
of Technology. All rights reserved.
Permission to use, copy, modify, and distribute this compilation for
any non-commercial purpose is hereby granted without fee, subject to
the following license:
1. Any copy or modification of this compilation must include the above
copyright notice and this license.
2. Software included in this compilation includes a feature that
causes the format of messages generated by it to change on September
1, 1994. Modification to this software to disable this feature is not
authorized and will make this license, and the license in the
underlying software, null and void.
3. Users of the software included in this compilation agree to use
their best efforts to provide MIT with any modifications containing
improvements or extensions and hereby grant MIT a perpetual,
royalty-free license to use and distribute such modifications under
the terms of this license. Such modifications may be provided to MIT
by email to pgp-bugs@mit.edu.
4. The software included in this compilation makes use of the
RSAREF(TM) Cryptographic Toolkit, use and distribution of which are
covered by the RSA Data Security, Inc., Program License Agreement
included in this compilation. This compilation also contains
materials copyrighted by Philip Zimmermann under terms also included
in this compilation. (See the "Legal Issues" section of the PGP
User's Guide, Volume 2.)
5. MIT makes no warranty or representation that the operation of the
software in this compilation will be error-free, and MIT is under no
obligation to provide any services, by way of maintenance, update, or
otherwise. THE SOFTWARE AND ANY DOCUMENTATION ARE PROVIDED "AS IS"
WITHOUT EXPRESS OR IMPLIED WARRANTY INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. IN NO EVENT WILL MIT OR ANY OTHER CONTRIBUTOR BE LIABLE FOR
DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF MIT HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
6.Users will not use the name of the Massachusetts Institute of
Technology nor any adaptation thereof in any publicity or
advertising, without prior written consent from MIT in each case.
7. Export of this software from the United States may require a
specific license from the United States Government. It is the
responsibility of any person or organization contemplating export
to obtain such a license before exporting.
-------------------------------------------------------------------------------
RSA LABORATORIES
PROGRAM LICENSE AGREEMENT
January 5, 1993
RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA")
GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM:
1. LICENSE. RSA grants you a non-exclusive, non-transferable,
perpetual (subject to the conditions of section 8) license
for the "RSAREF" program (the "Program") and its associated
documentation, subject to all of the following terms and
conditions:
a. to use the Program on any computer in your possession;
b. to make copies of the Program for back-up purposes;
c. to modify the Program in any manner for porting or
performance improvement purposes (subject to Section 2)
or to incorporate the Program into other computer programs
for your own personal or internal use, provided that you
provide RSA with a copy of any such modification or
Application Program by electronic mail, and grant RSA
a perpetual, royalty-free license to use and distribute
such modifications and Application Programs on the terms
set forth in this Agreement.
d. to copy and distribute the Program and Application Programs
in accordance with the limitations set forth in Section 2.
"Application Programs" are programs which incorporate all or any
portion of the Program in any form. The restrictions imposed on
Application Programs in this Agreement shall not apply to any software
which, through the mere aggregation on distribution media, is
co-located or stored with the Program.
2. LIMITATIONS ON LICENSE.
a. RSA owns the Program and its associated documentation and
all copyrights therein. You may only use, copy, modify and
distribute the Program as expressly provided for in this
Agreement. You must reproduce and include this Agreement,
RSA's copyright notices and disclaimer of warranty on any
copy and its associated documentation.
b. The Program and all Application Programs are to be used only
for non-commercial purposes. However, media costs associated
with the distribution of the Program or Application Programs
may be recovered.
c. The Program, if modified, must carry prominent notices
stating that changes have been made, and the dates of any
such changes.
d. Prior permission from RSA is required for
any modifications that access the Program through ways
other than the published Program interface or for
modifications to the Program interface. RSA will grant
all reasonable requests for permission to make such
modifications.
3. NO RSA OBLIGATION. You are solely responsible for all of your
costs and expenses incurred in connection with the distribution
of the Program or any Application Program hereunder, and RSA
shall have no liability, obligation or responsibility therefor.
RSA shall have no obligation to provide maintenance, support,
upgrades or new releases to you or to any distributee of the
Program or any Application Program.
4. NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED
DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR
PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF
THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA)
ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.
5. LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN
SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS
BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE
PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY
DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
6. PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set
forth below, RSA, at its own expense, shall: (i) defend, or at
its option settle, any claim, suit or proceeding against you on
the basis of infringement of any United States patent in the
field of cryptography by the unmodified Program; and (ii) pay
any final judgment or settlement entered against you on such
issue in any such suit or proceeding defended by RSA. The
obligations of RSA under this Section 6 are subject to:
(i) RSA's having sole control of the defense of any such claim,
suit or proceeding; (ii) your notifying RSA promptly in writing
of each such claim, suit or proceeding and giving RSA authority
to proceed as stated in this Section 6; and (iii) your giving
RSA all information known to you relating to such claim,
suit or proceeding and cooperating with RSA to defend any such
claim, suit or proceeding. RSA shall have no obligation under
this Section 6 with respect to any claim to the extent it is
based upon (A) use of the Program as modified by any person
other than RSA or use of any Application Program, where use
of the unmodified Program would not constitute an infringement,
or (B) use of the Program in a manner other than that permitted
by this Agreement. THIS SECTION 6 SETS FORTH RSA'S ENTIRE
OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR
PROPRIETARY RIGHTS INFRINGEMENT.
NOTE: Portions of the Program practice methods described in and
subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829,
and all foreign counterparts and equivalents, issued to Leland
Stanford Jr. University and to Massachusetts Institute of
Technology. Such patents are licensed to RSA by Public Key
Partners of Sunnyvale, California, the holder of exclusive
licensing rights. This Agreement does not grant or convey any
interest whatsoever in such patents.
7. RSAREF is a non-commercial publication of cryptographic
techniques. Portions of RSAREF have been published in the
International Security Handbook and the August 1992 issue of Dr.
Dobb's Journal. Privacy applications developed with RSAREF may be
subject to export controls. If you are located in the United States
and develop such applications, you are advised to consult with the
State Department's Office of Defense Trade Controls.
8. TERM. The license granted hereunder is effective until
terminated. You may terminate it at anytime by destroying
the Program and its associated documentation. The termination
of your license will not result in the termination of the
licenses of any distributees who have received rights to the
Program through you so long as they are in compliance with
the provisions of this license.
9. GENERAL
a. This Agreement shall be governed by the laws of the State of
California.
b. Address all correspondence regarding this license to RSA's
electronic mail address <rsaref-administrator@rsa.com>, or
to
RSA Laboratories
ATTN: RSAREF Administrator
100 Marine Parkway, Suite 500
Redwood City, CA 94065