PGP Time Bomb FAQ

[Michael Johnson <mpj@csn.org>]

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

PGP TIME BOMB FAQ

There has been some confusion about the annoying "Time Bomb" in MIT PGP 2.6,
as well as some other PGP version compatibility issues. This is an attempt to
clear up some of that confusion.


WHY IS THERE A TIME BOMB IN MIT PGP 2.6?

In the process of negotiating for the right to distribute a fully legal
version of PGP that the patent assignees agree doesn't infring upon their
patents, MIT agreed to include an inducement for people to upgrade from the
alledgedly infringing freeware PGP 2.3a to the clearly legal freeware MIT PGP
2.6 or the also clearly legal Viacrypt PGP 2.7.

Folks, you may not realize it, but the RSADSI/PKP concession to allow a
freeware PGP in the USA is BIG TIME GOOD NEWS! To induce a small
incompatibility with a downlevel version of PGP with several bugs in it is a
small annoyance by comparison.


WHAT IS THE NATURE OF THE TIME BOMB?

On 1 September 1994 UT, by your system clock, MIT PGP 2.6 will start
generating encrypted message and signature packets with a version byte
(offset 3) of 2 instead of 3.  It will accept either 2 or 3 as valid.  This
means that messages from PGP 2.3a and old messages from MIT PGP 2.6 can be
read by MIT PGP 2.6, but new messages from MIT PGP 2.6 cannot be read by PGP
2.3a.  See pgformat.doc in the MIT PGP 2.6 distribution for the location and
use of these bytes.  This time bomb is activated by code in pgp.c that looks
like this:

#define VERSION_BYTE_OLD        2       /* PGP2 */
#define VERSION_BYTE_KLUDGE     3
...
boolean legal_kludge;
int version_byte = VERSION_BYTE_OLD;
...
        /* Turn on incompatibility as of 1 September 1994 (GMT) */
        legal_kludge = (get_timestamp(NULL) >= 0x2e651980);
...
        if (legal_kludge)
                version_byte = VERSION_BYTE_KLUDGE;

Although a method for disarming the time bomb is obvious to the casual C
programmer, disabling this feature invalidates the RSA license to use the
program, and really doesn't gain you much for reasons that will become
obvious below.


HOW DOES THIS TIME BOMB AFFECT COMPATIBILITY WITH OTHER VERSIONS?

The bottom line is that PGP 2.3a and before (as well as Viacrypt PGP 2.4)
cannot read all of the latest PGP version formats, starting on 1 September
1994.  Here is a summary of the version bytes generated and understood:

                                Format
                                generated       Formats
                                before/after    understood
Version                         1 Sep 94        (all times)
- ----------------------------    -----   ----    -----------

2.3                             2       2       2
2.3a                            2       2       2
Amiga 2.3a.4                    2       2       2,3
Viacrypt 2.4                    2       2       2
2.6ui                           2       2       2,3
MIT 2.6                         2       3       2,3
Viacrypt 2.7, pkcs_compat=1     2       3       2,3
Viacrypt 2.7, pkcs_compat=2     2       2       2,3
Viacrypt 2.7, pkcs_compat=3     3       3       2,3

(Not mentioned above is MIT PGP 2.5, which was a buggy beta, nor several
other versions that are outside the mainstream PGP project).

If you are using one of the versions above that cannot understand version
byte 3 messages, you should upgrade to one that does.  The upgrade from
Viacrypt PGP 2.4 to Viacrypt PGP 2.7 is only US$10, and also provides several
other enhancements.

As you can see, people with downlevel versions of PGP will not be able to
read all PGP messages directed at them, nor will they be able to verify all
of the signed messages they might wish to verify.

It is also worth noting that none of the new versions have any trouble
reading the old format messages.


WHAT IS THE RSA KEY MODULUS LENGTH LIMIT?

The RSA key modulus length limit for compatibility with all mainstream PGP
versions is 1024 bits (military grade).  I recommend the use of this length,
at least for now.

PGP 2.3a, running on some platforms (but not others), use to be able to
generate and use 1264 bit keys.  In addition, some people have hacked their
own copies of PGP to generate and use longer keys (up to 8192 bits or some
such crazy number).  Distribution of these hacked versions under the "Pretty
Good Privacy" trademarked name is not recommended, since it upsets the trade
mark owner (Philip Zimmermann) and interferes with some of his long term
plans to support longer keys in a more organized fashion.


IS 1024 BITS LONG ENOUGH?

Conservative estimates of increasing computing power, advancing mathematical
knowledge, and the propensity of certain spy organizations to spend lots of
money on these things say that 1024 bit keys are strong enough for at least
20 years or so.  Less paranoid prognosticators say that such keys are good
for hundreds of years.  More paranoid prognosticators think that someone has
already broken RSA and not told us about it, so no RSA key is safe.  My
opinion is that RSA keys with a modulus of about 1024 bits in length is more
than adequate to protect most electronic mail and financial transactions.
What do you think?


HOW DOES THE STRENGTH OF RSA AND IDEA COMPARE?

As implemented in PGP, the IDEA cipher used for bulk encryption appears to be
stronger than the RSA cipher.  In fact, to strengthen the RSA to the same
level as the IDEA cipher (assuming a brute force attack), it would take an
RSA modulus of about 3100 bits.


WHY NOT ALLOW LONGER RSA KEYS, ANYWAY?

OK, so you are more paranoid than me, and want the RSA key to be at least as
strong as the IDEA cipher.  Why isn't there a higher limit to the RSA key
size?

First, there is the minor problem that RSAREF and BSAFE (which are tied to
the RSA patent license for the freeware and some commercial versions of PGP)
have a key length limit of 1024 bits.  Changing this involves negotiations
with RSADSI/PKP, and could take some time.  Second, allowing longer key sizes
could create a Tower of Babel problem of incompatible PGP versions, since not
all versions could handle these long keys.  Third, the implementation of
longer keys needs to be done in an orderly manner such that all mainstream
PGP versions (Viacrypt, MIT freeware, BSAFE-based commercial, and possibly a
non-USA variant) are first upgraded to accept, but not generate, the longer
keys.  After all PGP users can accept the longer keys, then PGP versions can
start generating the longer keys with no interruption in service.

It still makes sense to have a length limit for compatibility reasons.  I
have asked Philip Zimmermann to increase that to at least 4096 bits when he
can, and I think that he will do that in an orderly manner if there isn't too
much in the way of hassles with RSAREF and BSAFE licensing.

If this isn't secure enough for you, shift to conventional encryption and
manual (direct person-to-person) key exchange, making sure that your keys
have at least 128 bits of entropy.  This can be done with pgp -c or another
private key encryption program called dlock that has the virtues of (1) NO
patent problems, and (2) very strong encryption. (DLOCK is not nearly as user
friendly as PGP, but what do you want for free?)


HOW DOES PKCS BYTE ORDERING IN KEYS AFFECT COMPATIBILITY?

PGP versions 2.2 and before generated key and signature block formats with a
different byte order than derived from the PKCS standards.  PGP 2.3 also
generated this old format if you specified +pkcs_compat=0 in config.txt or on
the command line.  This old format is now obsolete.  Unfortunately, the old
format cannot be parsed by RSAREF or BSAFE, so PGP versions based on these
crypto engines (like MIT PGP 2.6) cannot read those packets.  Viacrypt PGP,
however, can still read both formats.

Although this is annoying if you have a really old key that has lots of old
signatures on it, the fact is that the older the key, the more likely someone
has captured both it and the passphrase used to protect it.  Therefore, I
strongly recommend generating a new key and getting at least one other person
to sign it.


ARE MY OLD KEYS COMPATIBLE WITH MIT PGP 2.6?

Unless they were created with the old, non-PKCS standard (i.e., created with
PGP 2.2 or earlier, or created with PGP 2.3a with pkcs_compat set to 0), and
unless they were created with a modulus of more than 1024 bits, then they are
compatible.  If a compatible key has an incompatible signature certificate,
then the incompatible signature certificate will simply be stripped off by
PGP 2.6.  Otherwise, you can keep using your old key.  In fact, if you just
copy your key ring files to your new PGP 2.6 directory, then extract your old
key with ASCII armor, it will be indistinguishable from a PGP 2.6 key, but
have the same value, id, and signatures (assuming they were all in the PKCS
format).


WHY DOESN'T THE MIT KEY SERVER ACCEPT KEYS FROM PGP VERSIONS < 2.4?

They don't want to be accused of contributing to the possibly infringing use
of PGP 2.3a.


WHY IS MY PGP 2.3a KEY ON THE MIT KEY SERVER?

Because the MIT key server synchronizes with several non-USA key servers that
run PGP 2.6ui or MIT PGP 2.6, and which accept keys from PGP 2.3a.  When keys
are extracted from those servers to synchronize with the MIT server, they
appear to be coming from PGP 2.6, so they are accepted.


WHY SHOULD I UPGRADE TO MIT PGP 2.6 FROM PGP 2.3a (BESIDES THE TIME BOMB)?

First of all, if you are in the USA, the patent-legal status of MIT PGP 2.6
is good for your conscience.  Second of all, there are a lot of bug fixes and
features:

Fixed a bug with the -z <passphrase> option.  If no passphrase was given,
PGP used to crash.

When using -c, the IV is generated properly now, and the randseed.bin
postwash is done.  (This bug could have resulted in the same ciphertext
being generated for the same plaintext, if the same passphrase is used.)

Memory allocated with halloc() is now freed with hfree() in ztrees.c and
zdeflate.c.  (MS-DOS only.)

The decompression code now detects end of input reliably, fixing a
bug that used to have it produce infinite amounts of output on come
corrputed input.  Decompression has also been sped up.

PGP -m won't try to write its final output to the current directory.
This makes it less efficent if you want to save the text to a file, but
more secure if you don't.

If the line
        comment=<string>
appears in the config file, the line "Comment: <string>" appears in
ASCII armor output.  Of course, you can also use this from the
command line, e.g. to include a filename in the ASCII armor, do
"pgp -eat +comment=filename filename recipient".

PGP now enables clearsig by default.  If you sign and ascii-armor a
text file, and do not encrypt it, it is clearsigned unless you ask
for this not to be done.

The now enables textmode.  Textmode detects non-text files and
automatically turns itself off, so it's quite safe to leave on all
the time.  If you haven't got these defaults yourself, you might
want to enable them.

All prompts and progress messages are now printed to stderr, to make them
easier to find and ensure they don't get confused with data on standard
output such as pgp -m output.

PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random
data in an attempt to force disk compressors to overwrite as much data as
possible.

On Unix, if the directory /usr/local/lib/pgp exists, it is searched
fror help files, language translations, and the PGP documentation.  On
VMS, the equivalent is PGP$LIBRARY:.  (This is PGP_SYSTEM_DIR, defined
in fileio.h, if you need to change it for your site.)

Also, it is searched for a default global config.txt.  This file may
be overridden by a local config.txt, and it may not set pubring,
secring, randseed or myname (which should be strictly personal)

The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as
fr.hlp.  Now, there is a separate help file for pgp -k, called pgpkey.hlp,
or <language>key.hlp.  No file is provided by default; PGP will use
its one-page internal help by default, but you can create such a file
at your site.

On Unix systems, $PGPPATH defaults to $HOME/.pgp.

PGP used to get confused if you had a keyring containing signatures from
you, but not your public key.  (PGP can't use the signatures in this case.
Only signatures from keys in the keyring are counted.)
PGP still can't use the signatures, but prints better warning messages.
Also, adding a key on your secret key ring to your public keyring
now asks if the key should be considered ultimately-trusted.
Prviously, you had to run pgp -ke to force this check, which was
non-obvious.

On Unix, PGP now figures out the resolution of the system clock at run
time for the purpose of computing the amount of entropy in keystroke
timings.  This means that on many Unix machines, less typing should be
required to generate keys.  (SunOS and Linux especially.)

The small prime table used in generating keys has been enlarged, which
should speed up key generation somewhat.

There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!)
when generating primes 2 bits over a multiple of the unit size (16 bits
on PC's, 32 bits on most larger computers), if the processor doesn't deal
with expressions like "1<<32" by producing a result of 1.  In practice,
that corresponds to a key size of 64*x+4 bits.

At the request of Windows programmers, the PSTR() macro used to translate
string has been renamed to LANG().

The random-number code has been *thoroughly* cleaned up.  So has the
IDEA code and the MD5 code.  The MD5 code was developed from scratch and
is available for public use.

Versions prior to 2.6 would not permit a new signature to be added to a key
if there was an already existing signature from the same signer. Starting
with version 2.6 newer signatures will override older ones *as long as the
newer signature verifies*. This change is important because many keys have
signatures on them that were created by PGP version 2.2 or earlier. These
signatures can not be verified by PGP 2.5 or higher. Owners of keys with
these obsolete signatures should attempt to gather new signatures and
add them to their key.


WHY SHOULD I UPGRADE TO MIT PGP 2.6 FROM PGP 2.6ui?

If you are in the USA, PGP 2.6ui suffers from the same alledged patent
infringement problems as PGP 2.3a.  PGP 2.6ui also lacks most of the bug
fixes and enhancements listed above since PGP 2.3a, since PGP 2.6ui is
essentially just PGP 2.3a modified to accept both new and old packet version
bytes (2 and 3).

On the other hand, if you are outside of the USA and Canada, you should be
careful not to offend the U. S. Department of State, Office of Defense Trade
Controls, by exporting MIT PGP 2.6 from the USA or Canada.  I suppose that
you wouldn't break U. S. law if you got a copy of MIT PGP 2.6 that someone
else exported, or you could get a copy of the PGP 2.6ui (that originated in
Great Britain) if you don't care about the enhancements listed above, or if
you want to be able to use 1264-bit keys.  Note that if you use MIT PGP 2.6
in most countries, you are still bound by the RSAREF license because of the
copyright law, and you are still limited in some countries to noncommercial
use of PGP by the IDEA patent (unless you get a license from ETH Zurich).


IS THERE AN EVIL PLOT, BACK DOOR, OR INTENTIONAL WEAKNESS IN MIT PGP 2.6?

Not that I am aware of.  It ships with source code, and I didn't see any way
to hide such a thing in the source code that I looked at.  Besides, if you
really knew Phil Zimmermann, you would know just how repugnant such an idea
is to him.


IS THERE A LEGAL VERSION OF PGP FOR COMMERCIAL USE IN EUROPE?

Not yet.  To do that, you would have to (1) arrange to license the use of
IDEA from ETH Zurich or wait for the coming triple-DES option in PGP, and (2)
use the original (PGP 2.3a or 2.6ui) RSA code linked in with the new PGP (to
avoid restrictions on the copyrighted RSAREF code).  There is also the
possibility of other local laws, such as those in France, restricting use of
strong cryptography.


IS THERE A LEGAL VERSION OF PGP FOR COMMERCIAL USE IN THE USA & CANADA?

Yes.  Use Viacrypt PGP for any commercial or personal use in the USA and
Canada.  I understand that there are some BSAFE-based PGP versions for
commercial use in the USA, too, but you need to check with Philip Zimmermann
on that to make sure that all of the copyright and licensing issues are
handled properly.


WHAT EXACTLY IS COMMERCIAL USE?

I don't have an exact definition.  Use some common sense.  Are you encrypting
sales reports, business plans, contract bidding information, and proprietary
designs?  Are your money making operations aided by the use of PGP?  If so,
and if one is available to you, you should buy the fully licensed commercial
version.


SINCE VIACRYPT PGP SHIPS WITH NO SOURCE, HOW DO I KNOW IT IS OK?

Philip Zimmermann wrote or examined all of the source code.  He says it is
OK, so I trust him.  I guess you have to decide for yourself.


IS IT OK TO BUY VIACRYPT PGP, THEN USE MIT PGP FOR COMMERCIAL USE?

RSADSI/PKP says it is not.  On the other hand, since their only recourse is
to sue you for damages, and since such a plan results in exactly the same
revenue they would have if you did what they wanted, there are no damages to
sue for.  Personally, I use Viacrypt PGP except when beta testing PGP.


IS THERE AN INTERCHANGE PROBLEM WITH THE DIFFERENT RSA ENGINES IN PGP?

Fortunately, there is no problem interchanging RSA encrypted packets between
original PGP, Viacrypt Digi-Sig, RSAREF, and BSAFE versions.  They all do the
same RSA computations.  They are all different implementations of the same
basic algorithm with a different legal status for each of them, which changes
depending on what country you are in.  The only annoyance is that unmodified
copies of RSAREF and BSAFE can't handle more than 1024 bit RSA keys, but that
isn't much of a problem (IMHO).


HOW DO I UPGRADE FROM VIACRYPT PGP 2.4 TO VIACRYPT PGP 2.7

Call 800-536-2664 with your registration number, name, address, and credit
card number handy.  Hey, it is only US$10.  No, I don't work for Viacrypt,
nor do I get a commission on sales -- I just use Viacrypt PGP.


WHERE DO I GET MIT PGP 2.6?

By ftp:
  ftp://net-dist.mit.edu/pub/PGP/mitlicen.txt
  ftp://ftp.csn.net/mpj/README.MPJ
  ftp://ftp.wimsey.bc.ca/pub/crypto/software/README
  ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/pgp/

  Look for the files pgp26.zip, pgp26src.zip, and pgp26src.tar.gz.

BBS:
  Colorado Catacombs BBS 303-772-1062 (free -- log in with your name)
  Hieroglyphics Voodoo Machine 303-443-2457 (log in as VOO DOO, password NEW)

  Download PGP26.ZIP, and for source, PGP26SRC.ZIP.

Compuserve:
  Use IBMFF to look for PGP26.ZIP and PGP26S.ZIP.

For a longer list, see the daily and montly postings on alt.security.pgp, or
get ftp://ftp.csn.net/mpj/getpgp.asc


WHAT KNOWN BUGS ARE IN MIT PGP 2.6?

The function xorbytes doesn't.  Replace the = with ^= to fix it.  The effect
of this bug is that RSA keys aren't quite as random as they should be --
probably not a practical problem, but worth fixing if you are going to
compile the code yourself.

DON'T SET PGPPASS when editing your keys, because if you do, and if you don't
change your pass phrase, the key is lost.  (If this happens, rename your
backup keyring files to the primary files before you do anything else).

These bugs have been fixed in the master source code, and will be corrected
in the next release of MIT PGP.


WHAT IS COMING IN FUTURE VERSIONS OF PGP?

I won't steal the thunder from Philip Zimmermann, Jeff Schiller, Colin Plumb,
and the rest of the team, but there is some neat stuff that they are working
on.  Transition from MIT PGP 2.6 and Viacrypt PGP 2.7 to the newer versions
will be easier than transitions from other versions.

If you have enhancements and suggestions for the PGP team, I suggest you
coordinate with them so that your ideas can be integrated with the main PGP
project.


WHERE DO I REPORT BUGS IN PGP?

Please send bug reports, bug fixes, ports to new platforms, and suggestions
to pgp-bugs@mit.edu.


WHERE DO I SEND OR FIND LANGUAGE KITS?

If you have a language kit to share, you can also send it to me at
mpj@csn.org for me to post on ftp.csn.net/mpj/public/pgp/, as well as sending
it to some of the other PGP sites.


IS PHILIP ZIMMERMANN STILL THE SUBJECT OF AN INVESTIGATION?

Yes.  He is still paying a lawyer lots of money to represent him, too.  If you
like PGP, then I would strongly suggest sending a donation to his defense
fund at:

   Philip Zimmermann defense fund
   c/o Philip Dubois
   2305 Broadway
   Boulder, Colorado 80304
   USA


CAN I REDISTRIBUTE THIS FILE?

Permission is hereby granted to freely redistribute unmodified copies of this
PGP signed file.

                  ___________________________________________________________
                 |                                                           |
 |\  /| |        | Michael Paul Johnson  Colorado Catacombs BBS 303-772-1062 |
 | \/ |o|        | PO Box 1151, Longmont CO 80502-1151 USA   Jesus is alive! |
 |    | | /  _   | mpj@csn.org aka mpj@netcom.com m.p.johnson@ieee.org       |
 |    |||/  /_\  | ftp://ftp.csn.net/mpj/README.MPJ          CIS: 71331,2332 |
 |    |||\  (    | ftp://ftp.netcom.com/pub/mpj/README.MPJ  -. --- ----- ....|
 |    ||| \ \_/  | PGPprint=F2 5E A1 C1 A6 CF EF 71  12 1F 91 92 6A ED AE A9 |
                 |___________________________________________________________|


-----BEGIN PGP SIGNATURE-----
Version: 2.7

iQCVAgUBLlDhNvX0zg8FAL9FAQHoZAP8C+XgqMzs1y0x1SHM45lzPzD8XK9JjjPk
lHUSDlQ6uo5lRnBXxUVPpPlTmLW4E2AHvCM+mke4bsVbvNJnNK513tUELWDkGLf4
6rexV0wiZJ9VdnQW3HyN44Sug8/5W7mxmgbdIOwv4A+OOWwAqm/chOLXsFAVn1mP
TLQSBl8sb3E=
=Wq3r
-----END PGP SIGNATURE-----