508 lines
22 KiB
Plaintext
508 lines
22 KiB
Plaintext
From: mpj@teal.csn.org (Michael Johnson)
|
|
Newsgroups:
|
|
alt.security.pgp,talk.politics.crypto,alt.2600,alt.privacy,alt.secu
|
|
rity
|
|
Subject: PGP Time Bomb FAQ
|
|
Date: Tue, 16 Aug 1994 16:11:42 GMT
|
|
Message-ID: <CuMyBJ.5JM@csn.org>
|
|
Organization: The Web of Trust
|
|
|
|
-----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-----
|
|
|