368 lines
15 KiB
Plaintext
368 lines
15 KiB
Plaintext
|
|
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 stomputer 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.
|
|
|