PGP can also be used to apply a digital signature to a message without encrypting it. This is normally used in public postings where you don't want to hide what you are saying, but rather want to allow others to confirm that the message actually came from you. Once a digital signature is created, it is impossible for anyone to modify either the message or the signature without the modification being detected by PGP.

While PGP is easy to use, it does give you enough rope so that you can hang yourself. You should become thoroughly familiar with the various options in PGP before using it to send serious messages. For example, giving the command "PGP -sat " will only sign a message, it will not encrypt it. Even though the output looks like it is encrypted, it really isn't. Anybody in the world would be able to recover the original text.

Xenon (an48138@anon.penet.fi) puts it like this:

Crime? If you are not a politician, research scientist, investor, CEO, lawyer, celebrity, libertarian in a repressive society, investor, or person having too much fun, and you do not send e-mail about your private sex life, financial/political/legal/scientific plans, or gossip then maybe you don't need PGP, but at least realize that privacy has nothing to do with crime and is in fact what keeps the world from falling apart. Besides, PGP is FUN. You never had a secret decoder ring? Boo!

It should be noted, however, that in the United States, some freeware versions of PGP MAY be a violation of a patent held by Public Key Partners (PKP). The MIT and ViaCrypt versions specifically are not in violation; if you use anything else, it's your risk. See below (question 1.6) for more information on the patent situation.

Also, the free versions of PGP are free only for noncommercial use. If you need to use PGP in a commercial setting (and you live in the United States or Canada), you should buy a copy of ViaCrypt PGP. ViaCrypt PGP has other advantages as well, most notably a limited license to export it to foreign branch offices. See below, under question 1.10, for information on how to contact ViaCrypt.

If you need to use PGP for commercial use outside the United States or Canada, you should contact Ascom Systec AG, the patent holders for IDEA. They have sold individual licenses for using the IDEA encryption in PGP. Contact:

*** NEWS FLASH ***

On April 3, 1995, Boris Yeltsin issued a decree formally banning encryption with methods not approved by the state. This would, presumably, include PGP. Thus, Russia must be added to the short list above.

*** END NEWS FLASH ***

The legal status of encryption in many countries has been placed on the World Wide Web. You can access it from:

First, there is a question as to whether or not PGP falls under ITAR regulations which govern the exporting of cryptographic technology from the United States and Canada. This despite the fact that technical articles on the subject of public key encryption have been available legally worldwide for a number of years. Any competent programmer would have been able to translate those articles into a workable encryption program. A lawsuit has recently been filed by the EFF challenging the ITAR regulations; thus, they may be relaxed to allow encryption technology to be exported.

Second, older versions of PGP (up to 2.3a) were thought to be violating the patent on the RSA encryption algorithm held by Public Key Partners (PKP), a patent that is only valid in the United States. This was never tested in court, however, and recent versions of PGP have been made with various agreements and licenses in force which effectively settle the patent issue. So-called "international" versions and older versions (previous to ViaCrypt PGP 2.4), however, are still considered in violation by PKP; if you're in the USA, use them at your own risk!

At the moment, there are four different "current" versions of PGP. All of these are derived, more or less, from a common source base: PGP 2.3a, the last "guerillaware" version of PGP. Negotiations to make PGP legal and "legitimate" have resulted in the differing versions available; all of them, for the most part, are approximately equivalent in functionality, and they can all work with each other in most respects.

MIT PGP 2.6.2 is the current "official" freeware version. It has been developed both with Phil Zimmermann's approval and active involvement. It contains several bug fixes and enhancements over 2.3a, and it avoids the patent question surrounding other versions of PGP by using the RSAREF library for some of its functions. This library was developed by RSA Data Security, Inc., and is (basically) free for noncommercial use. As part of MIT's agreement with RSADSI, all versions of MIT PGP generate encrypted messages that cannot be decrypted with PGP 2.3a or previous versions.

ViaCrypt PGP 2.7.1 is the current "official" commercial version. It is available from ViaCrypt, a company out of Arizona, and also has Phil's approval and involvement. See below for details on this version.

PGP 2.6.3i ("international") is a version of PGP developed from the source code of MIT PGP, which was exported illegally from the United States at some point. Basically, it is MIT PGP 2.6.2, but it uses the old encryption routines from PGP 2.3a; these routines perform better than RSAREF and in addition do not have the usage restrictions in the RSAREF copyright license. It also contains some fixes for bugs discovered since the release of MIT PGP 2.6.2.

PGP 2.6ui ("unofficial international") is PGP 2.3a with minor modifications made so it can decrypt files encrypted with MIT PGP. It does not contain any of the MIT fixes and improvements; it does, however, have other improvements, most notably in the Macintosh version.

"My memory says that ripem.msu.edu stores a backlog of both alt.security.pgp, and sci.crypt. But that site is ONLY open for ftp for those that are inside US."

ViaCrypt reports:

    If you are a commercial user of PGP in the USA or Canada, contact
    Viacrypt in Phoenix, Arizona, USA.  The commercial version of PGP
    is fully licensed to use the patented RSA and IDEA encryption
    algorithms in commercial applications, and may be used in
    corporate and government environments in the USA and Canada.  It
    is fully compatible with, functionally the same as, and just as
    strong as the freeware version of PGP. Due to limitations on
    ViaCrypt's RSA distribution license, ViaCrypt only distributes
    executable code and documentation for it, but they are working on
    making PGP available for a variety of platforms.  Call or write
    to them for the latest information.  The latest version number
    for Viacrypt PGP is 2.7.  [Note: Since this statement was issued,
    ViaCrypt has updated ViaCrypt PGP to 2.7.1.]

    Here is a brief summary of Viacrypt's currently-available
    products:

    1. ViaCrypt PGP for Windows (3.1).   Prices start at $124.98

    2. ViaCrypt PGP for Macintosh, 680x0 or PowerPC, System 6.04 or   
       later.    Prices start at $124.98

    3. ViaCrypt PGP for MS-DOS.  Prices start at $99.98

    4. ViaCrypt PGP for UNIX.  Includes executables for the following
       platforms:

         SunOS 4.1.x (SPARC)
         Solaris 2.3
         IBM RS/6000 AIX
         HP 9000 Series 700/800 UX
         SCO 386/486 UNIX
         SGI IRIX
         AViiON DG-UX(88/OPEN)

       Prices start at $149.98

         Executables for the following additional platforms are
         available upon request for an additional $30.00 charge.

         BSD 386
         Ultrix MIPS DECstation 4.x
         DEC Alpha OSF/1
         NeXTSTEP

    5. ViaCrypt PGP for WinCIM/CSNav.  A special package for users of 
       CompuServe.  Prices start at $119.98

    If you wish to place an order please call 800-536-2664 during the
    hours of 8:30am to 5:00pm MST, Monday - Friday.  We accept VISA,
    MasterCard, AMEX and Discover credit cards.

    If you have further questions, please feel free to contact me.

    Best Regards,
    Paul E. Uhlhorn
    Director of Marketing, ViaCrypt Products
    Mail:       9033 N. 24th Avenue
                Suite 7
                Phoenix, AZ  85021-2847
    Phone:      (602) 944-0773
    Fax:        (602) 943-2601
    Internet:   viacrypt@acm.org
    Compuserve: 70304,41
          

If you don't see your favorite platform above, don't despair! It's likely that porting PGP to your platform won't be too terribly difficult, considering all the platforms it has been ported to. Just ask around to see if there might in fact be a port to your system, and if not, try it!

PGP's VMS port, by the way, has its own Web page:

Web/Mosaic/Lynx:

Fran Litterio's Crypto Page (from the Virtual Library)

http://draco.centerline.com:8080/~franl/crypto.html
Using Microsoft Windows with PGP

http://www.lcs.com/winpgp.html
Derek Atkins' Official Bug List for MIT PGP

http://www.mit.edu:8001/people/warlord/pgp-faq.html
The Phil Zimmermann Legal Defense Fund Page

http://www.netresponse.com/zldf
The MCIP/Macintosh Cryptography Page

http://uts.cc.utexas.edu/~grgcombs/htmls/crypto.html
Jeff Licquia's Home Page

http://www.prairienet.org/~jalicqui

As part of the agreement made to settle PGP's patent problems, MIT PGP changed its format slightly to prevent PGP 2.4 and older versions from decrypting its messages. This format change was written into MIT PGP to happen on September 1, 1994. Thus, all messages encrypted with MIT PGP after that date are unreadable by 2.4 (and earlier).

The best route here is for your friend to upgrade to a newer version of PGP. Alternatively, if you are using a non-MIT version, look up the "legal_kludge" option in your documentation; you should be able to configure your copy of PGP to generate old-style messages.

This problem comes up mostly with old key signatures. If your key contains such old signatures, try to get those people who signed your key to resign it.

If an old signature is still vitally important to check, get a non-MIT version of PGP to check it with, such as ViaCrypt's.

A set of scripts was distributed with PGP for doing this. Since these scripts were considered out of date, they have been removed from the MIT distribution.

With regular encryption, it's impossible unless you encrypted to yourself as well. Sorry!

There is an undocumented setting, EncryptToSelf, which you can set in your CONFIG.TXT or on the command line to "on" if you want PGP to always encrypt your messages to yourself. Be warned, though; if your key is compromised, this means that the "cracker" will be able to read all the message you sent as well as the ones you've received.

There are two solutions: set the PGPPASS environment variable to point to the location of your key rings, or run a "mkdir $HOME/.pgp" before generating your key.

The only type of attack that might succeed is one that tries to solve the problem from a mathematical standpoint by analyzing the transformations that take place between plain text blocks, and their cipher text equivalents. IDEA is still a fairly new algorithm, and work still needs to be done on it as it relates to complexity theory, but so far, it appears that there is no algorithm much better suited to solving an IDEA cipher than the brute force attack, which we have already shown is unworkable. The nonlinear transformation that takes place in IDEA puts it in a class of extremely difficult to solve mathmatical problems.

When the inventors of RSA first published the algorithm, they encrypted a sample message with it and made it available along with the public key used to encrypt the message. They offered $100 to the first person to provide the plaintext message. This challenge is often called "RSA-129" because the public key used was 129 digits, which translates to approximately 430 bits.

Recently, an international team coordinated by Paul Leyland, Derek Atkins, Arjen Lenstra, and Michael Graff successfully factored the public key used to encrypt the RSA-129 message and recovered the plaintext. The message read:

This is why picking a strong pass phrase is so important. Many of these cracker programs are very sophisticated and can take advantage of language idioms, popular phrases, and rules of grammar in building their guesses. Single-word "phrases", proper names (especially famous ones), or famous quotes are almost always crackable by a program with any "smarts" in it at all.

A pass phrase which is composed of ordinary words without punctuation or special characters is susceptible to a dictionary attack. Transposing characters or mis-spelling words makes your pass phrase less vulnerable, but a professional dictionary attack will cater for this sort of thing.

A good treatise on the subject is available which discusses the use of "shocking nonsense" in pass phrases. It is written by Grady Ward, and can be found on Fran Litterio's crypto page:

If you already own a trusted version of PGP, it is easy to check the validity of any future version. Newer binary versions of MIT PGP are distributed in popular archive formats; the archive file you receive will contain only another archive file, a file with the same name as the archive file with the extension .ASC, and a "setup.doc" file. The .ASC file is a stand-alone signature file for the inner archive file that was created by the developer in charge of that particular PGP distribution. Since nobody except the developer has access to his/her secret key, nobody can tamper with the archive file without it being detected. Of course, the inner archive file contains the newer PGP distribution. A quick note: If you upgrade to MIT PGP from an older copy (2.3a or before), you may have problems verifying the signature. See question 3.14, below, for a more detailed treatment of this problem.

To check the signature, you must use your old version of PGP to check the archive file containing the new version. If your old version of PGP is in a directory called C:\PGP and your new archive file and signature is in C:\NEW (and you have retrieved MIT PGP 2.6.2), you may execute the following command:

You may, first of all, not verify the signature and follow other methods for making sure you aren't getting a bad copy. This isn't as secure, though; if you're not careful, you could get passed a bad copy of PGP.

If you're intent on checking the signature, you may do an intermediate upgrade to MIT PGP 2.6. This older version was signed before the "time bomb" took effect, so its signature is readable by the older versions of PGP. Once you have validated the signature on the intermediate version, you can then use that version to check the current version.

As another alternative, you may upgrade to PGP 2.6.3i or 2.6ui, checking their signatures with 2.3a, and use them to check the signature on the newer version. People living in the USA who do this may be violating the RSA patent in doing so; then again, you may have been violating it anyway by using 2.3a, so you're not in much worse shape.

Second, all the freeware versions of PGP are released with full source code to both PGP and to the RSAREF library they use (just as every other freeware version before them were). Thus, it is subject to the same peer review mentioned in the question above. If there were an intentional hole, it would probably be spotted. If you're really paranoid, you can read the code yourself and look for holes!

You should be very careful, however. Your pass phrase may be passed over the network in the clear where it could be intercepted by network monitoring equipment, or the operator on a multi-user machine may install "keyboard sniffers" to record your pass phrase as you type it in. Also, while it is being used by PGP on the host system, it could be caught by some Trojan Horse program. Also, even though your secret key ring is encrypted, it would not be good practice to leave it lying around for anyone else to look at.

So why distribute PGP with directions for making it on Unix and VMS machines at all? The simple answer is that not all Unix and VMS machines are network servers or "mainframes." If you use your machine only from the console (or if you use some network encryption package such as Kerberos), you are the only user, you take reasonable system security measures to prevent unauthorized access, and you are aware of the risks above, you can securely use PGP on one of these systems. As an example of this, my own home computer runs Linux, a Unix clone. As I (and my wife) are the only users of the computer, I feel that the risks of crackers invading my system and stealing my pass phrase are minimal.

You can still use PGP on multi-user systems or networks without a secret key for checking signatures and encrypting. As long as you don't process a private key or type a pass phrase on the multiuser system, you can use PGP securely there.

The problem with using PGP on a system that swaps is that the system will often swap PGP out to disk while it is processing your pass phrase. If this happens at the right time, your pass phrase could end up in cleartext in your swap file. How easy it is to swap "at the right time" depends on the operating system; Windows reportedly swaps the pass phrase to disk quite regularly, though it is also one of the most inefficient systems. PGP does make every attempt to not keep the pass phrase in memory by "wiping" memory used to hold the pass phrase before freeing it, but this solution isn't perfect.

If you have reason to be concerned about this, you might consider getting a swapfile wiping utility to securely erase any trace of the pass phrase once you are done with the system. Several such utilities exist for Windows and Linux at least.

In addition, don't forget that private keys are useful for more than decrypting. Someone with your private key can also sign items that could later prove to be difficult to deny. Keeping your private key secure can prevent, at the least, a bit of embarassment, and at most could prevent charges of fraud or breach of contract.

Besides, many of the above procedures are also effective against some common indirect attacks. As an example, the digital signature also serves as an effective integrity check of the file signed; thus, checking the signature on new copies of PGP ensures that your computer will not get a virus through PGP (unless, of course, the PGP version developer contracts a virus and infects PGP before signing).

The following information applies only to citizens of the United States in U.S. Courts. The laws in other countries may vary. Please see the disclaimer at the top of part 1.

If you are using MIT PGP 2.6.2, ViaCrypt PGP 2.7.1, or PGP 2.6.3i, you can specify key sizes greater than 1024 bits; the upper limit for these programs is 2048 bits. Remember that you have to tell PGP how big you want your key if you want it to be bigger than 1024 bits. Generating a key this long will take you quite a while; however, this is, as noted above, a one-time process. Remember that other people running other versions of PGP may not be able to handle your large key!

Gary Edstrom remarked (a long time ago):

"I just recently added the entire 850KB public key ring form one of the key servers to my local public key ring. Even on my 66MHz 486 system, the process took over 10 hours."

Unfortunately, the present version of PGP does not allow you to do this directly. Fortunately, there is an indirect way to do it.

I would like to thank Robert Joop (rj@rainbow.in-berlin.de) for supplying the following method which is simpler than the method that I had previously given.

solution 1:

pgp -sat +clearsig=on

The output file will contain your original unmodified text, along with section headers and an armored PGP signature. In this case, PGP is not required to read the file, only to verify the signature.

gopher://ferret.state.wy.us/00/wgov/lb/1995session/BILLS/1995/

    Type bits/keyID    Date       User ID
    pub  1024/0353E385 1994/06/17 Jeff Licquia 
    sig       0353E385             Jeff Licquia 
          

Some countries require respected professionals such as doctors or engineers to endorse passport photographs as proof of identity for a passport application - you should consider signing someone's key in the same light. Alternatively, when you come to sign someone's key, ask yourself if you would be prepared to swear in a court of law as to that person's identity.

Remember that signing a person's key says nothing about whether you actually like or trust that person or approve of his/her actions. It's just like someone pointing to someone else at a party and saying, "Yeah, that's Joe Blow over there." Joe Blow may be an ax murderer; you don't become tainted with his crime just because you can pick him out of a crowd.

If it is a key from someone you know well and whose voice you recognize then it is sufficient to give them a phone call and have them read their key's fingerprint (obtained with "pgp -kvc ").

If you don't know the person very well then the only recourse is to exchange keys face-to-face and ask for some proof of identity. Don't be tempted to put your public key disk in their machine so they can add their key - they could maliciously replace your key at the same time. If the user ID includes an e-mail address, verify that address by exchanging an agreed encrypted message before signing. Don't sign any user IDs on that key except those you have verified.

Derek Atkins (warlord@mit.edu) has recommended this method:

There are many ways to hold a key-signing session. Many viable suggestions have been given. And, just to add more signal to this newsgroup, I will suggest another one which seems to work very well and also solves the N-squared problem of distributing and signing keys. Here is the process:

1. You announce the keysinging session, and ask everyone who plans to come to send you (or some single person who *will* be there) their public key. The RSVP also allows for a count of the number of people for step 3.

2. You compile the public keys into a single keyring, run "pgp -kvc" on that keyring, and save the output to a file.

3. Print out N copies of the "pgp -kvc" file onto hardcopy, and bring this and the keyring on media to the meeting.

4. At the meeting, distribute the printouts, and provide a site to retreive the keyring (an ftp site works, or you can make floppy copies, or whatever -- it doesn't matter).

5. When you are all in the room, each person stands up, and people vouch for this person (e.g., "Yes, this really is Derek Atkins -- I went to school with him for 6 years, and lived with him for 2").

6. Each person securely obtains their own fingerprint, and after being vouched for, they then read out their fingerprint out loud so everyone can verify it on the printout they have.

7. After everyone finishes this protocol, they can go home, obtain the keyring, run "pgp -kvc" on it themselves, and re-verify the bits, and sign the keys at their own leisure.

8. To save load on the keyservers, you can optionally send all signatures to the original person, who can coalate them again into a single keyring and propagate that single keyring to the keyservers and to each individual.

The way to avoid this dilemma is to create a key revocation certificate at the same time that you generate your key pair. Put the revocation certificate away in a safe place and you will have it available should the need arise. You need to be careful how you do this, however, or you will end up revoking the key pair that you just generated, and a revocation can't be reversed.

Very recently, the number of keys reported on the key servers passed 10,000.

Sites accessible via mail:

ADD	Your PGP public key (key to add is body of msg) (-ka)
INDEX	List all PGP keys the server knows about (-kv)
VERBOSE INDEX	List all PGP keys, verbose format (-kvv)
GET	Get the whole public key ring (-kxa *)
GET	Get just that one key (-kxa )
MGET	Get all keys which match
LAST	Get all keys uploaded during last days

Post all of your bug reports concerning non-MIT versions of PGP to alt.security.pgp, and forward a copy to me for possible inclusion in future releases of the FAQ. Please be aware that the authors of PGP might not acknowledge bug reports sent directly to them. Posting them on USENET will give them the widest possible distribution in the shortest amount of time.

The following list of bugs is limited to version 2.4 and later, and is limited to the most commonly seen and serious bugs. For bugs in earlier versions, refer to the documentation included with the program. If you find a bug not on this list, follow the procedure above for reporting it.

MIT PGP 2.6 had a bug in the key generation process which made keys generated by it much less random. Fixed in 2.6.1.

All versions of PGP except MIT PGP 2.6.2 are susceptible to a "buglet" in clearsigned messages, making it possible to add text to the beginning of a clearsigned message. The added text does not appear in the PGP output after the signature is checked. MIT PGP 2.6.2 now does not allow header lines before the text of a clearsigned message and enforces RFC 822 syntax on header lines before the signature. Since this bug appears at checking time, however, you should be aware of this bug even if you use MIT PGP 2.6.2 - the reader may check your signed message with a different version and not read the output.

MIT PGP 2.6.1 was supposed to handle keys between 1024 and 2048 bits in length, but could not. Fixed in 2.6.2.

MIT PGP 2.6.2 was supposed to enable the generation of keys up to 2048 bits after December 25, 1994; a one-off bug puts that upper limit at 2047 bits instead. It has been reported that this problem does not appear when MIT PGP is compiled under certain implementations of Unix. The problem is fixed in versions 2.7.1 and 2.6.3i.

PGP 2.6ui continues to exhibit the bug in 2.3a where conventionally encrypted messages, when encrypted twice with the same pass phrase, produce the same ciphertext.

Many of the versions of MacPGP (especially beta versions of MIT MacPGP) have been reported to not handle text files and ASCII-armored files correctly, causing some signatures not to validate.

ViaCrypt has reported a bug in freeware PGP affecting at least PGP 2.3a and MIT PGP 2.6, 2.6.1, and 2.6.2. This bug affects signatures made with keys between 2034 and 2048 bits in length, causing them to be corrupted. Practically speaking, this bug only affects versions of PGP that support the longer key lengths. ViaCrypt reports that this only seems to be a problem when running PGP on a Sun SPARC-based workstation. ViaCrypt PGP 2.7.1 and PGP 2.6.3i do not suffer from this bug. The following patch will fix the problem in MIT PGP 2.6.2:

<===== begin patch (cut here)

    --- crypto.c.orig Mon Mar 20 22:30:29 1995
    +++ crypto.c	Mon Mar 20 22:55:32 1995
    @@ -685,7 +685,7 @@
        byte class, unitptr e, unitptr d, unitptr p, unitptr q, unitptr u,
        unitptr n)
      {
    - byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION];
    + byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION+2];
      int i, j, certificate_length, blocksize,bytecount;
      word16 ske_length;
      word32 tstamp; byte *timestamp = (byte *) &tstamp;
        

The initial release of PGP 2.6.3i contained a bug related to clearsigned messages; signed messages containing international characters would always fail. For that reason, it was immediately pulled from distribution and re-released later, minus the bug. If you have problems with 2.6.3i, make sure you downloaded your copy after 7 May 1995.

Garfinkel, Simson, "PGP: Pretty Good Privacy",
O'Reilly & Associates, 1994,
ISBN 1-56592-098-8.

Schneier, Bruce, "E-Mail Security with PGP and PEM: How To Keep Your Electronic Messages Private",
John Wiley & Sons, 1995,
ISBN 0-471-05318-X.

The Code Breakers

1. Some BBS sysops may not permit you to place encrypted mail or files on their boards. Just because they have PGP in their file area, that doesn't necessarily mean they tolerate you uploading encrypted mail or files - so do check first.

2. Fido net mail is even more sensitive. You should only send encrypted net mail after checking that:
   1. Your sysop permits it.
   2. Your recipient's sysop permits it.
   3. The mail is routed through nodes whose sysops also permit it.

3. Get your public key signed by as many individuals as possible. It increases the chances of another person finding a path of trust from himself to you.

4. Don't sign someone's key just because someone else that you know has signed it. Confirm the identity of the individual yourself. Remember, you are putting your reputation on the line when you sign a key.

This list is not exhaustive, nor is it even necessarily correct. Much of it is lifted from the old FAQ, and, as a result, some of the links are probably out of date. Hopefully, I will be able to weed out the bad links and update this over time; the task was too great for me to take immediately, however, especially given the pressing need. I present it in the hope that it will be helpful.

Amiga

PGP Mail Integration Project
Author: Peter Simons (simons@peti.rhein.de)
ftp://ftp.uni-kl.de/pub/aminet/comm/mail/PGPMIP.lha
ftp://ftp.uni-kl.de/pub/aminet/comm/mail/PGPMIT.readme

Automatic PGP encryption for mail over UUCP and SMTP.

PGPAmiga-FrontEnd
Author: Peter Simons (simons@peti.rhein.de)

GUI front end for Amiga PGP.

StealthPGP 1.0
ftp://ftp.uni-erlangen.de/pub/aminet/util/crypt/StealthPGP1_0.lha

Tool to remove any header stuff from PGP encrypted messages, to make sure nobody recognizes it as encrypted text. Source included.

PGPMore 2.3
ftp://ftp.uni-erlangen.de/pub/aminet/util/crypt/PGPMore2_3.lha

More-like tool which decrypts PGP encrypted blocks included in the text before displaying them. Useful for decrypting complete mail folders, etc...

Archimedes

PGPwimp
Author: Peter Gaunt
ftp://ftp.demon.co.uk/pub/archimedes/

A multi-tasking WIMP front-end for PGP (requires RISC OS 3). Operates on files - it has no hooks to allow integration with mailers/newsreaders.

RNscripts4PGP
Author: pla@sktb.demon.co.uk (Paul L. Allen)
ftp://ftp.demon.co.uk/pub/archimedes/

A collection of scripts and a small BASIC program which integrate PGP with the ReadNews mailer/newsreader. Provides encryp, decrypt, sign signature- check, add key.

DOS (Windows utilities are in a separate section)

Offline AutoPGP
Author: Stale Schumacher (staalesc@ifi.uio.no)
ftp://oak.oakland.edu/pub/msdos/security/apgp212.zip
http://www.ifi.uio.no/~staalesc/AutoPGP/

Integrates PGP with QWK and SOUP offline mail readers.

PGPSort
Author: Stale Schumacher (staalesc@ifi.uio.no)
ftp://oak.oakland.edu/pub/msdos/security/pgpsort.zip
http://www.ifi.uio.no/~staalesc/PGP/PGPSort.html

Sorts your PGP public keyring.

HPack
ftp://garbo.uwasa.fi/pc/arcers/hpack79.zip
ftp://garbo.uwasa.fi/pc/doc-soft/hpack79d.zip
ftp://garbo.uwasa.fi/pc/source/hpack79s.zip
ftp://garbo.uwasa.fi/unix/arcers/hpack79src.tar.Z

Archiver program (like ZIP) which integrates PGP.

Menu
ftp://ghost.dsi.unimi.it/pub/crypt/menu.zip

Menu shell for PGP which uses 4DOS.

OzPKE
CompuServe: EFFSIG lib 15, OZCIS lib 7, EURFORUM lib 1

Integrates PGP into OzCIS, an automated access program for CompuServe.

PGP-Front
Author: Walter H. van Holst (121233@student.frg.eur.nl)
ftp://ftp.dsi.unimi.it:/pub/security/crypt/PGP/pgpfront.zip

Interactive shell for PGP; has most functions.

PGPShell
Author: James Still (still@kailua.colorado.edu)
ftp://oak.oakland.edu/pub/msdos/security/pgpshe33.zip
Send mail to still@rintintin.colorado.edu (subject "send shell")

Another PGP shell for DOS.

PGS
ftp://oak.oakland.edu/pub/msdos/security/

Pretty Good PGP Shell or PGS is a complete shell for Philip Zimmermann's Pretty Good Privacy (PGP). PGS enables you to do anything that PGP can do from the commandline from a, easy to use, front-end shell.

PGPUtils
ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgputils.zip

Batch files and PIF files for PGP.

PC Yarn
Author: Chin Huang (cthuang@io.org)
ftp://oak.oakland.edu/SimTel/msdos/offline/yarn_0xx.zip (xx is version number)

MS-DOS offline mail and news software (using the SOUP packet format) that can clearsign or encrypt outgoing messages, and decrypt incoming messages to the CRT, a text file, or a mail folder.

NeXT

CryptorBundle
ftp://ftp.informatik.uni-hamburg.de/pub/comp/platforms/next/Mail/apps/CryptorBundle-1.0.NI.b.tar.gz

Integrates PGP into Mail.app.

OS/2

EPM Macro for PGP
Author: John C. Frickson (frickson@gibbon.com)
ftp://ftp.gibbon.com/pub/gcp/gcppgp10.zip

Macro for EPM which places a PGP menu in the menu bar.

Unix

PGPsendmail
ftp://ftp.atnf.csiro.au/pub/people/rgooch/
ftp://ftp.dhp.com/pub/crypto/pgp/PGPsendmail/
ftp://ftp.ox.ac.uk/pub/crypto/pgp/utils/

Automatically encrypts by acting as a wrapper for sendmail.

PGPTalk
ftp://ftp.ox.ac.uk/src/security/pgptalk.zip

Integrates PGP into ytalk for secure private chatting.

Emacs Auto-PGP
Author: Ian Jackson (ijackson@nyx.cs.du.edu)

This is a package for integrating PGP into GNU Emacs.

Mailcrypt
Author: jsc@mit.edu (Jin S Choi), patl@lcs.mit.edu (Patrick J. LoPresti)
ftp://cag.lcs.mit.edu/pub/patl/mailcrypt/

This is an elisp package for encrypting and decrypting mail. I wrote this to provide a single interface to the two most common mail encryption programs, PGP and RIPEM. You can use either or both in any combination.

mail-secure.el
Author: Travis J. I. Corcoran (tjic@icd.teradyne.com)
Send mail to tjic@icd.teradyne.com

Complement to Mailcrypt which adds some new features. Requires Mailcrypt.

PGPPAGER
Author: abottone@minerva1.bull.it (Alessandro Bottonelli)

This program acts as a smart pager for mail, and can automatically decrypt the body portion of a message if necessary.

mkpgp
Send mail to slutsky@lipschitz.sfasu.edu
(auto-replies the mkpgp program; use Subject: mkpgp)

Script for integrating pine and PGP.

PGP Elm
Author: Kenneth H. Cox (kenc@x-men.viewlogic.com)
ftp://ftp.viewlogic.com/pub/elm-2.4pl24pgp3.tar.gz

Patched version of elm which is PGP-aware.

PGP Augmented Messaging (was PGP Enhanced Messaging)
Author: Rick Busdiecker (rfb@cmu.edu)
ftp://h.gp.cs.cmu.edu/usr/rfb/pem/

Another set of GNU Emacs PGP utilities.

VAX/VMS

ENCRYPT.COM
Author: joleary@esterh.wm.estec.esa.nl (John O'Leary)

ENCRYPT.COM is a VMS mail script that works fine for joleary@esterh.wm.estec.esa.nl (John O'Leary)

Windows (v3, '95, NT)

PGP Help for the Windows Help engine
Author: Jeff Sheets (xanthur@aol.com)
http://netaccess.on.ca/~rbarclay/pgp.html

PGP documentation and help in WinHelp format.

PGPWinFront (PWF)
Author: Ross Barclay (RBARCLAY@TrentU.ca)
http://netaccess.on.ca/~rbarclay/index.html
Send mail to rbarclay@trentu.ca (put GET PWF in subject)

Windows front end for PGP. Includes most functions.

J's Windows PGP Shell (JWPS)
ftp://oak.oakland.edu/pub/msdos/security/

Another Windows front end for PGP. Supports drag-n-drop, clipboard, etc.

PGP Windows
ftp://oak.oakland.edu/pub/msdos/security/pgpwin.zip

Still another Windows PGP front end.

WinPGP(tm)
ftp://ftp.firstnet.net/pub/windows/winpgp/pgpw40.zip
http://www.firstnet.net/~cwgeib/welcome.html

Another PGP Windows shell; this one is shareware.

ZMail Scripts for PGP
Author: Guy Berliner (berliner@netcom.com)
ftp://ftp.netcom.com/pub/be/berliner/readme.html
ftp://kaiwan.com/user/mckinnon/pgp4zm.zip

Scripts for integrating PGP with ZMail, a popular graphical mailer.

Private Idaho
ftp://ftp.eskimo.com/joelm/pidaho21.zip
http://www.eskimo.com/~joelm/

A PGP integration tool for various Windows mailers. Supports anonymous remailers.

-Tools
Author: Andy Brown (asb@nexor.co.uk)
ftp://mirage.nexor.co.uk/pub/security/steganography/s-tools3.zip

A set of Windows steganography tools.

This is the next step up from the Known Plain Text Attack. In this version, the cryptanalyst can choose what plain text message he wishes to encrypt and view the results, as opposed to simply taking any old plain text that he might happen to lay his hands on. If he can recover the key, he can use it to decode all data encrypted under this key. This is a much stronger form of attack than known plain text. The better encryption systems will resist this form of attack.

Clipper

A chip developed by the United States Government that was to be used as the standard chip in all encrypted communications. Aside from the fact that all details of how the Clipper chip work remain classified, the biggest concern was the fact that it has an acknowledged trap door in it to allow the government to eavesdrop on anyone using Clipper provided they first obtained a wiretap warrant. This fact, along with the fact that it can't be exported from the United States, has led a number of large corporations to oppose the idea. Clipper uses an 80 bit key to perform a series of nonlinear transformation on a 64 bit data block.

DES (Data Encryption Standard)

A data encryption standard developed by IBM under the auspices of the United States Government. It was criticized because the research that went into the development of the standard remained classified. Concerns were raised that there might be hidden trap doors in the logic that would allow the government to break anyone's code if they wanted to listen in. DES uses a 56 bit key to perform a series of nonlinear transformation on a 64 bit data block. Even when it was first introduced a number of years ago, it was criticized for not having a long enough key. 56 bits just didn't put it far enough out of reach of a brute force attack. Today, with the increasing speed of hardware and its falling cost, it would be feasible to build a machine that could crack a 56 bit key in under a day's time. It is not known if such a machine has really been built, but the fact that it is feasible tends to weaken the security of DES substantially.

I would like to thank Paul Leyland (pcl@ox.ac.uk) for the following information relating to the cost of building such a DES cracking machine:

_Efficient DES Key Search_

At Crypto 93, Michael Wiener gave a paper with the above title. He showed how a DES key search engine could be built for $1 million which can do exhaustive search in 7 hours. Expected time to find a key from a matching pair of 64-bit plaintext and 64-bit ciphertext is 3.5 hours.

So far as I can tell, the machine is scalable, which implies that a $100M machine could find keys every couple of minutes or so.

The machine is fairly reliable: an error analysis implies that the mean time between failure is about 270 keys.

The final sentence in the abstract is telling: In the light of this work, it would be prudent in many applications to use DES in triple- encryption mode.

I only have portions of a virtually illegible FAX copy, so please don't ask me for much more detail. A complete copy of the paper is being snailed to me.

Paul C. Leyland (pcl@ox.ac.uk)

Laszlo Baranyi (laszlo@instrlab.kth.se) says that the full paper is available in PostScript from:

Eric Hughes (hughes@toad.com) runs the "cypherpunk" mailing list dedicated to "discussion about technological defenses for privacy in the digital domain." Frequent topics include voice and data encryption, anonymous remailers, and the Clipper chip. Send e-mail to majordomo@toad.com with "subscribe cypherpunks" in the body to be added or subtracted from the list. The mailing list itself is cypherpunks@toad.com. You don't need to be a member of the list in order to send messages to it, thus allowing the use of anonymous remailers to post your more sensitive messages that you just as soon would not be credited to you. (Traffic is sometimes up to 30-40 messages per day.)

What is the purpose of the Cypherpunk remailers?

The purpose of these remailers is to take privacy one level further. While a third party who is snooping on the net may not be able to read the encrypted mail that you are sending, he is still able to know who you are sending mail to. This could possibly give him some useful information. This is called traffic flow analysis. To counter this type of attack, you can use a third party whose function is simply to remail your message with his return address on it instead of yours.

Two types of remailers exist. The first type only accepts plain text remailing headers. This type would only be used if your goal was only to prevent the person to whom your are sending mail from learning your identity. It would do nothing for the problem of net eavesdroppers from learning to whom you are sending mail.

The second type of remailer accepts encrypted remailing headers. With this type of remailer, you encrypt your message twice. First, you encrypt it to the person ultimately receiving the message. You then add the remailing header and encrypt it again using the key for the remailer that you are using. When the remailer receives your message, the system will recognize that the header is encrypted and will use its secret decryption key to decrypt the message. He can now read the forwarding information, but because the body of the message is still encrypted in the key of another party, he is unable to read your mail. He simply remails the message to the proper destination. At its ultimate destination, the recipient uses his secret to decrypt this nested encryption and reads the message.

Since this process of multiple encryptions and remailing headers can get quite involved, there are several programs available to simplify the process. FTP to soda.berkeley.edu and examine the directory /pub/cypherpunks/remailers for the programs that are available.

Where are the currently active Cypherpunk remailers?

Raph Levien maintains a list of currently active remailers. The list, unfortunately, seems to change often as remailers are shut down for whatever reasons; therefore, I am not printing a list here. You can get the list by fingering remailer-list@kiwi.cs.berkeley.edu.

Are there other anonymous remailers besides the cypherpunk remailers?

Yes, the most commonly used remailer on the Internet is in Finland. It is known as anon.penet.fi. The syntax for sending mail through this remailer is different from the cypherpunk remailers. For example, if you wanted to send mail to me (gbe@netcom.com) through anon.penet.fi, you would send the mail to "gbe%netcom.com@anon.penet.fi". Notice that the "@" sign in my Internet address is changed to a "%". Unlike the cypherpunk remailers, anon.penet.fi directly supports anonymous return addresses. Anybody using the remailer is assigned an anonymous id of the form "an?????" where "?????" is filled in with a number representing that user. To send mail to someone when you only know their anonymous address, address your mail to "an?????@anon.penet.fi" replacing the question marks with the user id you are interested in. For additional information on anon.penet.fi, send a blank message to "help@anon.penet.fi". You will receive complete instructions on how to use the remailer, including how to obtain a pass phrase on the system.

What is the remailer command syntax?

The first non blank line in the message must start with two colons (::). The next line must contain the user defined header "Request-Remailing-To: ". This line must be followed by a blank line. Finally, your message can occupy the rest of the space. As an example, if you wanted to send a message to me via a remailer, you would compose the following message:

::
Request-Remailing-To: gbe@netcom.com

[body of message]

You would then send the above message to the desired remailer. Note the section labeled "body of message" may be either a plain text message, or an encrypted and armored PGP message addressed to the desired recipient. To send the above message with an encrypted header, use PGP to encrypt the entire message shown above to the desired remailer. Be sure to take the output in armored text form. In front of the BEGIN PGP MESSAGE portion of the file, insert two colons (::) as the first non-blank line of the file. The next line should say "Encrypted: PGP". Finally the third line should be blank. The message now looks as follows:

::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version 2.3a

[body of pgp message]
-----END PGP MESSAGE-----

You would then send the above message to the desired remailer just as you did in the case of the non-encrypted header. Note that it is possible to chain remailers together so that the message passes through several levels of anonymity before it reaches its ultimate destination.

Where can I learn more about Cypherpunks?

ftp://ftp.csua.berkeley.edu/pub/cypherpunks

    From netcom.com!netcomsv!decwrl!sdd.hp.com!col.hp.com!csn!yuma!ld231782 Sun
    Oct 10 07:55:51 1993
    Xref: netcom.com talk.politics.crypto:650 comp.org.eff.talk:20832
    alt.politics.org.nsa:89
    ~Newsgroups: talk.politics.crypto,comp.org.eff.talk,alt.politics.org.nsa
    Path: netcom.com!netcomsv!decwrl!sdd.hp.com!col.hp.com!csn!yuma!ld231782
    ~From: ld231782@LANCE.ColoState.Edu (L. Detweiler)
    ~Subject: ZIMMERMANN SPEAKS TO HOUSE SUBCOMMITTEE
    ~Sender: news@yuma.ACNS.ColoState.EDU (News Account)
    Message-ID: 
    ~Date: Sun, 10 Oct 1993 04:42:12 GMT
    Nntp-Posting-Host: turner.lance.colostate.edu
    Organization: Colorado State University, Fort Collins, CO  80523
    ~Lines: 281


    ~Date: Sat, 9 Oct 93 11:57:54 MDT
    ~From: Philip Zimmermann 
    ~Subject: Zimmerman testimony to House subcommittee


                Testimony of Philip Zimmermann to
         Subcommittee for Economic Policy, Trade, and the Environment
                   US House of Representatives
                        12 Oct 1993

    Mr. Chairman and members of the committee, my name is Philip
    Zimmermann, and I am a software engineer who specializes in
    cryptography and data security.  I'm here to talk to you today about
    the need to change US export control policy for cryptographic
    software.  I want to thank you for the opportunity to be here and
    commend you for your attention to this important issue.

    I am the author of PGP (Pretty Good Privacy), a public-key encryption
    software package for the protection of electronic mail.  Since PGP was
    published domestically as freeware in June of 1991, it has spread
    organically all over the world and has since become the de facto
    worldwide standard for encryption of E-mail.  The US Customs Service
    is investigating how PGP spread outside the US.  Because I am a target
    of this ongoing criminal investigation, my lawyer has advised me not
    to answer any questions related to the investigation.

    I.  The information age is here.

    Computers were developed in secret back in World War II mainly to
    break codes.  Ordinary people did not have access to computers,
    because they were few in number and too expensive.  Some people
    postulated that there would never be a need for more than half a
    dozen computers in the country.  Governments formed their attitudes
    toward cryptographic technology during this period.  And these
    attitudes persist today.  Why would ordinary people need to have
    access to good cryptography?

    Another problem with cryptography in those days was that cryptographic
    keys had to be distributed over secure channels so that both parties
    could send encrypted traffic over insecure channels. Governments
    solved that problem by dispatching key couriers with satchels
    handcuffed to their wrists.  Governments could afford to send guys
    like these to their embassies overseas.  But the great masses of
    ordinary people would never have access to practical cryptography if
    keys had to be distributed this way.  No matter how cheap and powerful
    personal computers might someday become, you just can't send the keys
    electronically without the risk of interception. This widened the
    feasibility gap between Government and personal access to cryptography.

    Today, we live in a new world that has had two major breakthroughs
    that have an impact on this state of affairs.  The first is the
    coming of the personal computer and the information age.  The second
    breakthrough is public-key cryptography.

    With the first breakthrough comes cheap ubiquitous personal
    computers, modems, FAX machines, the Internet, E-mail, digital
    cellular phones, personal digital assistants (PDAs), wireless digital
    networks, ISDN, cable TV, and the data superhighway.  This
    information revolution is catalyzing the emergence of a global
    economy.

    But this renaissance in electronic digital communication brings with
    it a disturbing erosion of our privacy.  In the past, if the
    Government wanted to violate the privacy of ordinary citizens, it had
    to expend a certain amount of effort to intercept and steam open and
    read paper mail, and listen to and possibly transcribe spoken
    telephone conversation.  This is analogous to catching fish with a
    hook and a line, one fish at a time.  Fortunately for freedom and
    democracy, this kind of labor-intensive monitoring is not practical
    on a large scale.

    Today, electronic mail is gradually replacing conventional paper
    mail, and is soon to be the norm for everyone, not the novelty is is
    today.  Unlike paper mail, E-mail messages are just too easy to
    intercept and scan for interesting keywords.  This can be done
    easily, routinely, automatically, and undetectably on a grand scale.
    This is analogous to driftnet fishing-- making a quantitative and
    qualitative Orwellian difference to the health of democracy.

    The second breakthrough came in the late 1970s, with the mathematics
    of public key cryptography.  This allows people to communicate
    securely and conveniently with people they've never met, with no
    prior exchange of keys over secure channels.  No more special key
    couriers with black bags.  This, coupled with the trappings of the
    information age, means the great masses of people can at last use
    cryptography.  This new technology also provides digital signatures
    to authenticate transactions and messages, and allows for digital
    money, with all the implications that has for an electronic digital
    economy.  (See appendix)

    This convergence of technology-- cheap ubiquitous PCs, modems, FAX,
    digital phones, information superhighways, et cetera-- is all part of
    the information revolution.  Encryption is just simple arithmetic to
    all this digital hardware.  All these devices will be using
    encryption.  The rest of the world uses it, and they laugh at the US
    because we are railing against nature, trying to stop it.  Trying to
    stop this is like trying to legislate the tides and the weather. It's
    like the buggy whip manufacturers trying to stop the cars-- even with
    the NSA on their side, it's still impossible.  The information
    revolution is good for democracy-- good for a free market and trade.
    It contributed to the fall of the Soviet empire.  They couldn't stop
    it either.

    Soon, every off-the-shelf multimedia PC will become a secure voice
    telephone, through the use of freely available software.  What does
    this mean for the Government's Clipper chip and key escrow systems?

    Like every new technology, this comes at some cost.  Cars pollute the
    air.  Cryptography can help criminals hide their activities.  People
    in the law enforcement and intelligence communities are going to look
    at this only in their own terms.  But even with these costs, we still
    can't stop this from happening in a free market global economy.  Most
    people I talk to outside of Government feel that the net result of
    providing privacy will be positive.

    President Clinton is fond of saying that we should "make change our
    friend".  These sweeping technological changes have big implications,
    but are unstoppable.  Are we going to make change our friend?  Or are
    we going to criminalize cryptography?  Are we going to incarcerate
    our honest, well-intentioned software engineers?

    Law enforcement and intelligence interests in the Government have
    attempted many times to suppress the availability of strong domestic
    encryption technology.  The most recent examples are Senate Bill 266
    which mandated back doors in crypto systems, the FBI Digital
    Telephony bill, and the Clipper chip key escrow initiative.  All of
    these have met with strong opposition from industry and civil liberties
    groups.  It is impossible to obtain real privacy in the information
    age without good cryptography.

    The Clinton Administration has made it a major policy priority to
    help build the National Information Infrastructure (NII).  Yet, some
    elements of the Government seems intent on deploying and entrenching
    a communications infrastructure that would deny the citizenry the
    ability to protect its privacy.  This is unsettling because in a
    democracy, it is possible for bad people to occasionally get
    elected-- sometimes very bad people.  Normally, a well-functioning
    democracy has ways to remove these people from power.  But the wrong
    technology infrastructure could allow such a future government to
    watch every move anyone makes to oppose it.  It could very well be
    the last government we ever elect.

    When making public policy decisions about new technologies for the
    Government, I think one should ask oneself which technologies would
    best strengthen the hand of a police state.  Then, do not allow the
    Government to deploy those technologies.  This is simply a matter of
    good civic hygiene.

    II.  Export controls are outdated and are a threat to privacy and
    economic competitivness.

    The current export control regime makes no sense anymore, given
    advances in technology.

    There has been considerable debate about allowing the export of
    implementations of the full 56-bit Data Encryption Standard (DES).
    At a recent academic cryptography conference, Michael Wiener of Bell
    Northern Research in Ottawa presented a paper on how to crack the DES
    with a special machine.  He has fully designed and tested a chip that
    guesses DES keys at high speed until it finds the right one.
    Although he has refrained from building the real chips so far, he can
    get these chips manufactured for $10.50 each, and can build 57000 of
    them into a special machine for $1 million that can try every DES key
    in 7 hours, averaging a solution in 3.5 hours.  $1 million can be
    hidden in the budget of many companies.  For $10 million, it takes 21
    minutes to crack, and for $100 million, just two minutes.  That's
    full 56-bit DES, cracked in just two minutes.  I'm sure the NSA can
    do it in seconds, with their budget.  This means that DES is now
    effectively dead for purposes of serious data security applications.
    If Congress acts now to enable the export of full DES products, it
    will be a day late and a dollar short.

    If a Boeing executive who carries his notebook computer to the Paris
    airshow wants to use PGP to send email to his home office in Seattle,
    are we helping American competitivness by arguing that he has even
    potentially committed a federal crime?

    Knowledge of cryptography is becoming so widespread, that export
    controls are no longer effective at controlling the spread of this
    technology.  People everywhere can and do write good cryptographic
    software, and we import it here but cannot export it, to the detriment
    of our indigenous software industry.

    I wrote PGP from information in the open literature, putting it into
    a convenient package that everyone can use in a desktop or palmtop
    computer.  Then I gave it away for free, for the good of our
    democracy.  This could have popped up anywhere, and spread.  Other
    people could have and would have done it.  And are doing it.  Again
    and again.  All over the planet.  This technology belongs to
    everybody.

    III.  People want their privacy very badly.

    PGP has spread like a prairie fire, fanned by countless people who
    fervently want their privacy restored in the information age.

    Today, human rights organizations are using PGP to protect their
    people overseas.  Amnesty International uses it.  The human rights
    group in the American Association for the Advancement of Science uses
    it.

    Some Americans don't understand why I should be this concerned about
    the power of Government.  But talking to people in Eastern Europe, you
    don't have to explain it to them.  They already get it-- and they
    don't understand why we don't.

    I want to read you a quote from some E-mail I got last week from
    someone in Latvia, on the day that Boris Yeltsin was going to war
    with his Parliament:

       "Phil I wish you to know: let it never be, but if dictatorship
       takes over Russia your PGP is widespread from Baltic to Far East
       now and will help democratic people if necessary.  Thanks."

    Appendix -- How Public-Key Cryptography Works
    ---------------------------------------------

    In conventional cryptosystems, such as the US Federal Data Encryption
    Standard (DES), a single key is used for both encryption and
    decryption.  This means that a key must be initially transmitted via
    secure channels so that both parties have it before encrypted
    messages can be sent over insecure channels.  This may be
    inconvenient.  If you have a secure channel for exchanging keys, then
    why do you need cryptography in the first place?

    In public key cryptosystems, everyone has two related complementary
    keys, a publicly revealed key and a secret key.  Each key unlocks the
    code that the other key makes.  Knowing the public key does not help
    you deduce the corresponding secret key.  The public key can be
    published and widely disseminated across a communications network.
    This protocol provides privacy without the need for the same kind of
    secure channels that a conventional cryptosystem requires.

    Anyone can use a recipient's public key to encrypt a message to that
    person, and that recipient uses her own corresponding secret key to
    decrypt that message.  No one but the recipient can decrypt it,
    because no one else has access to that secret key.  Not even the
    person who encrypted the message can decrypt it.

    Message authentication is also provided.  The sender's own secret key
    can be used to encrypt a message, thereby "signing" it.  This creates
    a digital signature of a message, which the recipient (or anyone
    else) can check by using the sender's public key to decrypt it.  This
    proves that the sender was the true originator of the message, and
    that the message has not been subsequently altered by anyone else,
    because the sender alone possesses the secret key that made that
    signature.  Forgery of a signed message is infeasible, and the sender
    cannot later disavow his signature.

    These two processes can be combined to provide both privacy and
    authentication by first signing a message with your own secret key,
    then encrypting the signed message with the recipient's public key.
    The recipient reverses these steps by first decrypting the message
    with her own secret key, then checking the enclosed signature with
    your public key.  These steps are done automatically by the
    recipient's software.



    --
      Philip Zimmermann
      3021 11th Street
      Boulder, Colorado 80304
      303 541-0140
      E-mail: prz@acm.org
    --

    ld231782@longs.LANCE.ColoState.EDU
          

The government is investigating Phil Zimmermann, the original author of PGP, for alleged violations of the ITAR export regulations prohibiting the unlicensed export of cryptographic equipment. They do not seem to believe that Phil himself actually exported PGP; rather, they claim that making the program available in a way that it could be exported is itself export (such as giving it away without restriction).

As of this writing, the investigation is just that. In January, Phil's lawyers met with the government lawyers to discuss the case. The outcome of the meeting is unclear at this point, though the meeting was described as "cordial" by Phillip Dubois, Phil Zimmermann's lawyer.

Even though it's "just an investigation", it's been an expensive one. Phil immediately had to go out and get legal representation to try to combat this "investigation" and prepare for its possible result. He's got a really good legal team, and they have done a lot of their work pro bono in support of the cause. Unfortunately, there are still costs associated with legal fights like this one. Phil's got quite a bill so far.

To help offset his costs, Phil and his legal team have set up a legal defense fund for contributions. It's currently way in the red, but it's better than paying the whole bill outright. If charges actually get filed, the total bill could soar up into the millions; not a fun thing to have happen to you after providing such a nice (if controversial) public service. And spending all these millions doesn't guarantee that he won't be convicted and spend some time in jail; that's something not even a legal defense fund can pay for.

Several companies who benefit from the use of PGP have indicated that they will donate a portion of their profits from certain activities to the legal defense fund. Here is a partial list:

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

    The ITAR (International Traffic in Arms Regulations) includes
    a regulation that requires a manufacturer of cryptographic
    products to register with the U.S. State Department even if the
    manufacturer has no intentions of exporting products.  It appears
    that this particular regulation is either not widely known, or
    is widely ignored.

    While no pressure was placed upon ViaCrypt to register, it is the
    Company's position to comply with all applicable laws and regulations.
    In keeping with this philosophy, ViaCrypt has registered with the
    U.S. Department of State as a munitions manufacturer.

    -----BEGIN PGP SIGNATURE-----
    Version: 2.4

    iQCVAgUBLQ+DfmhHpCDLdoUBAQGa+AP/YzLpHBGOgsU4b7DjLYj8KFC4FFACryRJ
    CKaBzeDI30p6y6PZitsMRBv7y2dzDILjYogIP0L3FTRyN36OebgVCXPiUAc3Vaee
    aIdLJ6emnDjt+tVS/dbgx0F+gB/KooMoY3SJiGPE+hUH8p3pNkYmhzeR3xXi9OEu
    GAZdK+E+RRA=
    =o13M
    -----END PGP SIGNATURE-----