Object 1 2

Why do you need PGP?

by Phil Zimmermann It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having an illicit affair. Or you may be doing something that you feel shouldn't be illegal, but is. Whatever it is, you don't want your private electronic mail (E-mail) or confidential documents read by anyone else. There's nothing wrong with asserting your privacy. Privacy is as apple-pie as the Constitution. Perhaps you think your E-mail is legitimate enough that encryption is unwarranted. If you really are a law-abiding citizen with nothing to hide, then why don't you always send your paper mail on postcards? Why not submit to drug testing on demand? Why require a warrant for police searches of your house? Are you trying to hide something? You must be a subversive or a drug dealer if you hide your mail inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens have any need to encrypt their E-mail? What if everyone believed that law-abiding citizens should use postcards for their mail? If some brave soul tried to assert his privacy by using an envelope for his mail, it would draw suspicion. Perhaps the authorities would open his mail to see what he's hiding. Fortunately, we don't live in that kind of world, because everyone protects most of their mail with envelopes. So no one draws suspicion by asserting their privacy with an envelope. There's safety in numbers. Analogously, it would be nice if everyone routinely used encryption for all their E-mail, innocent or not, so that no one drew suspicion by asserting their E-mail privacy with encryption. Think of it as a form of solidarity. Today, if the Government wants to violate the privacy of ordinary citizens, it has to expend a certain amount of expense and labor to intercept and steam open and read paper mail, and listen to and possibly transcribe spoken telephone conversation. This kind of laborintensive monitoring is not practical on a large scale. This is only done in important cases when it seems worthwhile. More and more of our private communications are being routed through electronic channels. Electronic mail is gradually replacing conventional 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. International cablegrams are already scanned this way on a large scale by the NSA. We are moving toward a future when the nation will be crisscrossed with high capacity fiber optic data networks linking together all our increasingly ubiquitous personal computers. E-mail will be the norm

for everyone, not the novelty it is today. The Government will protect our E-mail with Government-designed encryption protocols. Probably most people will acquiesce to that. But perhaps some people will prefer their own protective measures. Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling measure buried in it. If this non-binding resolution had become real law, it would have forced manufacturers of secure communications equipment to insert special trap doors in their products, so that the Government can read anyone's encrypted messages. It reads: "It is the sense of Congress that providers of electronic communications services and manufacturers of electronic communications service equipment shall insure that communications systems permit the Government to obtain the plain text contents of voice, data, and other communications when appropriately authorized by law." This measure was defeated after rigorous protest from civil libertarians and industry groups. In 1992, the FBI Digital Telephony wiretap proposal was introduced to Congress. It would require all manufacturers of communications equipment to build in special remote wiretap ports that would enable the FBI to remotely wiretap all forms of electronic communication from FBI offices. Although it never attracted any sponsors in Congress in 1992 because of citizen opposition, it was reintroduced in 1994. Most alarming of all is the White House's bold new encryption policy initiative, under development at NSA since the start of the Bush administration, and unveiled April 16th, 1993. The centerpiece of this initiative is a Government-built encryption device, called the Clipper chip, containing a new classified NSA encryption algorithm. The Government is encouraging private industry to design it into all their secure communication products, like secure phones, secure FAX, etc. AT&T is now putting the Clipper into their secure voice products. The catch: At the time of manufacture, each Clipper chip will be loaded with its own unique key, and the Government gets to keep a copy, placed in escrow. Not to worry, though -- the Government promises that they will use these keys to read your traffic only when duly authorized by law. Of course, to make Clipper completely effective, the next logical step would be to outlaw other forms of cryptography. If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable military grade public-key cryptographic technology. Until now. PGP empowers people to take their privacy into their own hands. There's a growing social need for it. That's why I wrote it.

The comp.security.pgp FAQ Wouter Slegers Copyright 1996, 1997, 1998, 1999, 2000, 2001 by Arnoud Engelfriet Copyright 2002 by Wouter Slegers This FAQ is copyright 2001 by Wouter Slegers. It may be distributed freely in online electronic form, provided the copyright notice is left intact. Since this FAQ is always available from USENET and the PGP network, there should be no problems getting access to it. However mirrors with outdated versions can confuse the users, so I request you not to mirror this FAQ elsewhere. If you want to distribute this FAQ on a CD-ROM or similar medium, please contact me for permission first (at <faq-admin@mail.pgp.net>). The same applies for offline distribution as well as use in printed matter. -------------------------------------------------------------------------------Table of Contents Preface 1. About this FAQ 2. Finding the FAQ 3. Revision history 1. General questions and introduction 2. Common Problems in using PGP 3. Security Questions 4. Keys 5. Message Signatures 6. Key Signatures 7. Revoking a key 8. Public Key Servers 9. Bugs Glossary of cryptographic terms Colophon -------------------------------------------------------------------------------Preface 1. About this FAQ This comp.security.pgp FAQ is based on Arnoud "Galactus" Engelfriet's FAQ which in turn was based on Jeff Licquia's original alt.security.pgp FAQ. This FAQ is since 2002 maintained by Wouter Slegers, Your Creative Solutions. I welcome any comments, suggestions or additions for this FAQ. As always, you can send them to <faqadmin@mail.pgp.net>.

-------------------------------------------------------------------------------2. Finding the FAQ This FAQ is posted monthly to all comp.security.pgp newsgroups, and the latest version will always be available from pgp.net. -------------------------------------------------------------------------------3. Revision history Revision History Revision 1.6 30 Jan 2002 The FAQ's maintainer changed from Arnoud "Galactus" Engelfriet to Wouter Slegers. As part of the new maintainership I'm starting a major overhoal of the whole FAQ. Including: Converted sourcefile of FAQ from the HTML+Orb construct it was to DocBook. This allows easier conversion to popular output formats. Removed many obsolete entries. Added information on GNU Privacy Guard, PGP 5.x and higher, OpenPGP and other news since the last version. Checked and updated the references. Reordered the remaining questions. Removed all email adresses of contributers from the FAQ (thanks to spammers, such a tribute is now a curse). Should you wish to contact one of these people, email me. The upgrading and restructuring is still far from complete, but the FAQ should be usable in this state. In particular what needs to be done at least: The questions need to be reordered. The keyserver chapter needs extensive updates. The outputformats need some cosmetic changes. Expect an updated version soon. Feedback to <faq-admin@mail.pgp.net> is very welcome.

-------------------------------------------------------------------------------Chapter 1. General questions and introduction

Q: What is PGP? Q: Why should I encrypt my mail? I'm not doing anything illegal! Q: What's the current version of PGP? Q: How much does PGP cost? Q: Is encryption legal? Q: Is PGP legal? Q: What's with the patent on IDEA? Q: What's with the patent on RSA? Q: Is there an archive site for the comp.security.pgp groups? Q: Is PGP available as a programming library, so I can write programs that use it? Q: What platforms has PGP been ported to? Q: Where can I obtain PGP? Q: I want to find out more! Q: What is PGP? A: PGP is a program that gives your electronic mail something that it otherwise doesn't have: Privacy. It does this by encrypting your mail so that nobody but the intended person can read it. When encrypted, the message looks like a meaningless jumble of random characters. PGP has proven itself quite capable of resisting even the most sophisticated forms of analysis aimed at reading the encrypted text. 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 verify 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 seems (and according to many of its users 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 <filename> will only sign and ASCII armor a message, it will not encrypt it. Even though the output looks like it is encrypted, it really isn't (it is the ASCII armor that looks so though). Anybody in the world would be able to recover the original text with a simple pgp <encryptedfilename>. The graphical userinterface of PGP 5.x and higher also has its pittfalls, as Alma Whitten describes in Why Johnny Can't Encrypt - A Usability Evaluation of PGP 5.0: even with manuals and an introduction, three of the twelve participants accidently sent "secret" information unencrypted. WarningMake sure you thoroughly understand how to operate PGP prior to using it for confidential information.

Q: Why should I encrypt my mail? I'm not doing anything illegal! A: You should encrypt your e-mail for the same reason that you don't write all of your correspondence on the back of a post card. E-mail is actually far less secure than the postal system. With the post office, your mail is handled by postal workers. Take a look at the header area of any e-mail message that you

receive and you will see that it has passed through a number of nodes on its way to you. Every one of these nodes presents the opportunity for snooping, as do all systems that can listen in on the communication between these nodes. Encryption in no way implies illegal activity. It is simply intended to keep personal thoughts personal. Xenon 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! --Xenon <an48138@anon.penet.fi>(Copyright 1993, Xenon)

Q: What's the current version of PGP? A: There are three different "product-lines" for PGP: PGP 2.x, PGP 5.x and higher, and GNU Privacy Guard. A: All the 2.x versions 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. All versions of PGP after 2.3 produce messages that cannot be read by 2.3 or earlier (for patent-legal purposes, see Why can't a person using version 2.3 read my version 2.6 message?>), although the "international" versions have a switch to enable the creation of messages in a compatible format. This is the legal_kludge=on option in the configuration file. 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, as well as several small enhancements. For more information, see the International PGP homepage 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. The 2.6.3(i)n version was developed to fullfill the policy of the Individual Network e.V. Certification Hierarchy. A: The PGP 5.x and higher series include OpenPGP compatibility. Most versions include both a command line version (for all platforms) and one with a graphical user interface (for the Microsoft Windowses and Mac OS 8.x and 9.x). The most recent version is 7.1.2 .

A: GNU Privacy Guard is an OpenPGP compatible program, written from scratch and not based on the 2.x sources. For normal uses it is compatible with both the PGP 2.x and the PGP 5.x and higher versions. It mostly targets UNIX-like systems. The most recent version is 1.0.4. Q: How much does PGP cost? A: The PGP 2.x series are freely available as open source software under the GNU General Public License, with no real limits on its use, at no cost (except the IDEA patent should you opt to include support for it, see What's with the patent on IDEA?). A: GNU Privacy Guard is freely available as open source software, with no real limits on its use, at no cost (except the IDEA patent should you opt to include support for it, see What's with the patent on IDEA?). The website of the GNU Privacy Guard Project is the primary distribution point. A: PGP 5.x and higher are commercial products. Network Associates bought PGP Inc., a company founded by Phil Zimmerman, and sells a whole range of products under the brand "PGP". The "original" email and file encryption PGP are called PGPmail and PGPfile respectively. See NAI for pricing and availability. There is a version available at no cost for strictly non-commercial use on http://www.pgp.com/products/freeware/. Note that the free versions of PGP are free only for noncommercial use. If you need to use PGP in a commercial setting you should buy a copy of PGP from NAI. This version of PGP has other advantages as well, most notably its integration with common MS Windows and Mac OS applications, a limited license to export it to foreign branch offices and a license for IDEA. See below, under question Where can I obtain PGP?>, for information on how to contact them. Q: Is encryption legal? A: In much of the civilized world, the use of encryption is either legal or at least tolerated. However, there are a some countries where such activities could put you in front of a firing squad! Check with the laws in your own country before using PGP or any other encryption product. A couple of the countries where the use of encryption is illegal are France, Iran, Russia and Iraq. Export, import or sale of products that contain strong encryption is usually also subject to restrictions. These laws are usual implementations of the Wassenaar Arrangement, for example the International Traffic in Arms Regulation (ITAR). Check the laws of the relevant countries for more details. The legal status of encryption in many countries has been gathered by Bert-Jaap Koops in the Crypto Law Survey. Q: Is PGP legal? A: In addition to the comments about encryption listed above (Is encryption legal?>) and the licence on the PGP software package you are using, the major point of importance is the status of the patents on technologies used in PGP. The patent on IDEA is still valid, see What's with the patent on IDEA?>. The patent on RSA has expired, but had a significant impact on the development and distribution of PGP, see What's with the patent on RSA?.

Q: What's with the patent on IDEA? A: IDEA is patented in the USA (US 5,214,703), Europe (EP-B-0482154)and Japan (JP 3225440) by Ascom Systec AG. This patent expires 25 May 2010 (USA) or 16 May 2011 (Europe and Japan). For strictly non-commercial use, the licence fee is waved by MediaCrypt AG. If you need to use PGP 2.x or GPG with IDEA (i.e. for compatibility with the 2.x versions) for commercial use, you should contact MediaCrypt AG who are the distributor for the IDEA algorithm license for Ascom Systec AG, the patent holders for IDEA. They sell individual and site licenses for using IDEA in PGP. Contact: MediaCrypt AG Technoparkstrasse 1 8005 Zurich Switzerland <IDEA@mediacrypt.com> Tel ++41 1 445 3070 Fax ++41 1 445 3071

Q: What's with the patent on RSA? A: 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 was only valid in the United States. This was never tested in court, however, and later 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, were still considered in violation by PKP. If you were in the USA, you used them at your own risk! However, the patent has since expired, so there are no known patent issues with RSA now. Q: Is there an archive site for the comp.security.pgp groups? A: Not really. Of course, you can try using Google Groups if you are looking for articles about specific topics. Q: Is PGP available as a programming library, so I can write programs that use it? A: The GNU Privacy Guard project has a C-library for integrating GnuPG in applications called GPGME (GnuPG Made Easy). This is mostly targetted at UNIX-like platforms. The CTC program includes a freeware PGP-interoperable C-library called CTClib and a Java crypto component called CTCjava. There is an older PGP 2.x-compatible C-library that can be used in programs called PGPlib.

NAI has a PGPsdk. available, but this not a software developer kit! The license explicitly restricts the use of the sourcecode to peer review only, development of programs with this source is not allowed. As a side note, also note that the license forbids you to make public bugs, errors, architecture issues and/or other problems with the source or compiled program without prior written permission of NAI. Alternatively, you could write your programs to call the PGP program when necessary. In C, for example, you would use the system() or spawn...() functions to do this. This is fairly complex to do securely, so make sure you know what you are doing. Q: What platforms has PGP been ported to? A: PGP 2.x in its many versions has been ported successfully to many different platforms, including the various Microsoft Windows versions, DOS, Mac OS, OS/2, Unix (just about all flavors), VMS, Atari ST, Acorn RISC OS (Archimedes), Commodore Amiga, EPOC and Palm OS. Most are listed on the International PGP product page. For Mac OS 8.x and 9.x there is a freeware PGP-interoperable program called MacCTC. For the EPOC operating system (as run by the Psion 5/5mx/Revo/S7/netBook and Nokia 9210) there is a port of PGP 2.6.3ia for EPOC. If you don't see your favorite platform above, don't despair! It's likely that porting PGP 2.x to your platform won't be 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 to port it yourself! A: PGP 5.x and later is available for the various Microsoft Windows versions and the Mac OS 8.x/9.x. It is commercially available from NAI. Note that PGP 7.x does not support Microsoft Windows XP (yet). A: GNU Privacy Guard mostly targets UNIX-like systems and is known to work on GNU/Linux, GNU/Hurd, FreeBSD, OpenBSD, NetBSD and various commercial UNIX-like systems. There is also a commandline version for the various Microsoft Windows versions. Q: Where can I obtain PGP? A: PGP is very widely available, so much so that a separate FAQ has been written by Micheal Paul Johnson for answering this question. It is called, Where to get the Pretty Good privacy program (PGP); it is posted in alt.security.pgp regularly, is in the various FAQ archive sites, and is also available online. In short however: The PGP 2.x versions can be found at Wiretapped.net and PGPi.net. The PGP 5.x and later versions are available for download and purchase via NAI. The GNU Privacy Guard can be found from the GNU Privacy Guard project page. Many of the previously mentioned versions, as well as older versions, are widely mirrored, for example

at Zedz.net.

Q: I want to find out more! A: If this FAQ doesn't answer your question, there are several places for finding out information about PGP. Above all, the accompanying documentation of PGP and GPG should not be missed. World Wide Web NAI, the company currently selling PGP 5.x through 7.x for commercial use http://www.stack.nl/~galactus/remailers/bg2pgp.txt Although the documentation that comes with PGP is very complete, you might also want to read this guide. It covers all the basic steps needed to install and use PGP, and also gives you tips on how to use it more effectively. http://www.stack.nl/~galactus/remailers/passphrase-faq.html Your pass phrase is used to protect your PGP secret key. Here's how to generate and manage strong pass phrases. This may also be useful for creating passwords for other purposes. PGP-related resources A large collection of PGP-related Web sites, links to front-ends, and more. http://www.stack.nl/~galactus/remailers/attack-faq.html A very detailed analysis on the security of PGP and possible attacks.

-------------------------------------------------------------------------------Chapter 2. Common Problems in using PGP Q: Are PGP 2.6.x, PGP 5.x and higher, and GNU Privacy Guard interoperable? Q: Why does it take so long to encrypt/decrypt messages? Q: How do I create a secondary key file? Q: Where can I obtain scripts and programs to integrate pgp with my email or news reading system? Q: How can I decrypt messages I've encrypted to others? Q: Why can't I generate a key with PGP for Unix? Q: When I clearsign a document in PGP, it adds a "dash-space" to several of my lines. Why? Q: How do I encrypt more than one file at a time with the commandline version? Q: How can I give my passphrase to the commandline PGP automatically?

Q: How come randseed.bin got "infected" by a virus? Q: How do I determine if the PGP commandline worked? Q: Why does PGP no longer ask for random keystrokes? Q: Why can't a person using version 2.3 read my version 2.6 message? Q: Why does PGP 2.x complain about checking signatures every so often? Q: Are PGP 2.6.x, PGP 5.x and higher, and GNU Privacy Guard interoperable? A: By and large, all PGP 2.x, 5.x and GPGs kan interoperate if: Only RSA keys are used, of at most 2048 bits length, MD5 is used as hash algorithm IDEA is used for the symmetrical algorithm. For GNU Privacy Guard, this usually means that you need to add the IDEA module as detailed in the GPG FAQ. RSA support is included by default as of version 1.0.3. Newer GPG versions include a --pgp2 option to restrict the output to things that PGP 2.x understands. A: GNU Privacy Guard and PGP 5.x and higher are by and large OpenPGP compliant and interoperable. Q: Why does it take so long to encrypt/decrypt messages? A: This problem can arise when you have placed the entire public key ring from one of the servers into your local pubring.pgp file. PGP may have to search through several thousand keys to find the one that it is after. If you need to have these large keyrings (e.g. because you cannot count on being able to contact the keyservers to look up new keys), the solution to this dilemma is to maintain 2 public key rings (See How do I create a secondary key file?). The first ring, the normal pubring.pgp file, should contain only those individuals that you send messages to quite often. The second key ring can contain all of the keys for those occasions when the key you need isn't in your short ring. You will, of course, need to specify the key file name whenever encrypting messages using keys in your secondary key ring. Now, when encrypting or decrypting messages to individuals in your short key ring, the process will be a lot faster. A: Encryption and decryption time also increases with the key size. A 2048 bits key will take much longer to work with than, for example, a 512 bits key. A: It is also possible, although fairly unprobable, that the random pool has run empty and PGP is waiting for enough randomness to amass. Remember that PGP needs randomness to create cryptographic keys, if these are not sufficiently random they could be guessed by an attacker. So to be sure, PGP (or the OS supplying it via /dev/random) waits until enough randomness is available. As this random pool is filled by events from among others keyboard and mouse, wriggling the mouse or tapping keys helps (use the control, alt and shift keys if you are worried that the keystrokes might trigger something). As usually enough randomness is gathered during normal operation and only a little is used each time, this is occurs mostly when large amounts of encryptions are done. Q: How do I create a secondary key file?

A: First, let's assume that you have all of the mammoth public key ring in your default pubring.pgp file. First, you will need to extract all of your commonly used keys into separate key files using the -kx option. Next, rename pubring.pgp to some other name. For this example, I will use the name pubring.big. Next, add each of the individual key files that you previously created to a new pubring.pgp using the -ka option. To encrypt a message to someone in the short default file, use the command pgp -e <file> <userid>. To encrypt a message to someone in the long ring, use the command pgp -e +pubring=c:\pgp\pubring.big <file> <userid>. Note that you need to specify the complete path and file name for the secondary key ring. It will not be found if you only specify the file name. Q: Where can I obtain scripts and programs to integrate pgp with my email or news reading system? A: There are many scripts and programs available for making PGP 2.x easier to use. There is an index to all of these at http://www.hauert.net/pgpmain.html and at PGPi.org. A: Plugins and configurations to use GNU Privacy Guard can be found on the GNU Privacy Guard Project website, under Frontends. A: PGP 5.x and higher already includes a number of plugins for other programs. More are listed on at PGPi.org. Q: How can I decrypt messages I've encrypted to others? A: With conventional encryption, you can read the message by running PGP on the encrypted file and giving the pass phrase you used to encrypt. A: With PGP's public key encryption, it's only possible if you encrypted to yourself as well. With the PGP 5.x and higher versions, it is the default setting to also encrypt to the default key. You can change this under PGP options / General / Always encrypt to default key. For PGP 2.x 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 secret key is compromised, this means that the attacker will be able to decode all the messages you sent as well as the ones you've received. Similarly if you are forced to reveal decrypt your data (see Can I be forced to reveal my pass phrase in any legal proceedings?>), you can now also decrypt the messages you sent, instead of only those you received! On the other hand, it allows you to read back the messages you sent in the past. Q: Why can't I generate a key with PGP for Unix? A: Most likely this is caused because PGP can't create the public and private key ring files. If the environment variable PGPPATH isn't defined, PGP will try to put those files in the subdirectory .pgp off your home directory. It will not create the directory if needed, so if the directory's not there already, PGP will abort after generating the key. This also happens if PGPPATH points to a directory for which you don't have write permission. There are two solutions: set the PGPPATH environment variable to point to the location of your key

rings, or run mkdir $HOME/.pgp; chmod 700 $HOME/.pgp before generating your key. Q: When I clearsign a document in PGP, it adds a "dash-space" to several of my lines. Why? A: PGP does this because of the "-----BEGIN PGP MESSAGE-----" (and related) headers it uses to mark the beginning of PGP messages. To keep it from getting confused, it tacks a "- " to the beginning of every line in the regular text which has a dash at the start. It strips the extra dash and space when you check the message's signature, and writes the original text to the output. This also happens with several lines that start with "special" phrases, such as "From", because those lines are otherwise escaped by mail programs, as required by the mail standard. This would change the body of the mail and thereby invalidate the signature. If you use PGP/MIME type signatures, the signature is presented as an attachement to receivers that do not have PGP. For signing files, the accepted method is to use a seperate signature file. Q: How do I encrypt more than one file at a time with the commandline version? A: PGP will normally only accept one file to encrypt on the command line. Many platforms allow you to call a program in a "batch" sequence. You can use this to call PGP on multiple files automatically. Under MS-DOS and OS/2, this works as follows: for %a in (*.*) do pgp -ea %a userid

You can also do conventional encryption this way, using the undocumented -z option to specify the passphrase to encrypt all these files with: for %a in (*.*) do pgp -c %a -z"the passphrase"

Under UNIX, this would be done like this: for a in * do pgp -ea "$a" userid done

Several shells and front-ends will also let you encrypt multiple files at once, usually.

Q: How can I give my passphrase to the commandline PGP automatically? A: WarningStoring your passphrase like this is very dangerous! Remember that your passphrase is all that protects your secret keys from an attacker snooping around in your system.

There are three ways to do this. The easiest way is probably to set the environment variable PGPPASS to contain your pass phrase. Under DOS and UNIX, you can just type set PGPPASS=My secret pass phrase to do this. WarningThis is very insecure, as anyone who has access to your environment can see what your passphrase is. This includes people who come along during your lunch break and type set at a prompt on your computer. Under several variations of UNIX, it is possible to examine someone else's environment as well.

Another option, especially useful for shells, is to use the -z option. You just add the option -z"My secret passphrase" to the PGP command line. Include the passphrase in quotes if there are any spaces or "special" characters in it, such as a "<" or ">" character which may confuse the command shell. WarningThis is even more insecure on a multi-user system as most allow other users to see the command options of programs run by another user. Everyone else can see what programs you are running, including all the options passed to it. The best, but also the most complicated way is using the PGPPASSFD environment variable. This variable should contain a "file descriptor number" pointing to a file which contains the passphrase. This will protect the passphrase from anyone but the superuser, if you properly set the file's permissions. You can find something on this in the appnotes file in the pgp262 distribution. If you set PGPPASSFD to 0, pgp will read the passphrase from stdin as soon it starts. PGPPASSFD=0; export PGPPASSFD echo "PassPhraseHere" | pgp -east file recipient1 recipient2..

--Thanks to Jack Gostl for the following.

You could also use funky shell redirection to make PGP get the passphrase from an arbitrary file. The exact command to define a variable depends on the shell; ksh and the likes use export PGPPASSFD=3, and csh and derivates use setenv PGPPASSFD 3. setenv PGPPASSFD 3; pgp -eat file recipient 3 < /my/passphrase/file

--Patrick J. LoPresti: This last example has the added advantage that standard input is still available to the user, for example to answer Yes or No to certain questions. Q: How come randseed.bin got "infected" by a virus? A: The file randseed.bin is used by PGP to store and generate randomness, which is used to create new random session keys every time you encrypt something. Afterwards, it is filled with new random data. A virus or integrity checker will then of course detect that the file has changed. Since the file has a .bin extension, some checkers think that it is an executable, and so will inform you they have detected a possible virus. However, this file is only used by PGP to read some random data and will never be executed. It is therefore safe to put it in the "exclusion" list of your virus scanner, so it will be skipped in future. An alternative is to instruct PGP to use a file with another extension, e.g. random.rnd. For the 2.6 versions this is done by puttting Randseed=C:\PGP\RANDOM.RND in your config.txt file. The PGP 5.x and higher GUI has a similar setting for Random Seed File. Deleting the random seed file will not do any harm; PGP will just ask you for some random keystrokes and generate the file again next time you encrypt something. Q: How do I determine if the PGP commandline worked? A: Normally, PGP runs in "interactive" mode, and so you can always read on the screen what went wrong, where and hopefully why. But if you want to use PGP in a batch file, or in the background, you need to find out if the operation was successful in another way. The usual approach for this is to use the "exit code" returned by PGP. To be able to detect if PGP could do what you asked, you need to add the +batchmode option to the command line. (To avoid getting "stuck" at prompts asking you to choose "yes" or "no", add the +force option). PGP will then return 0 if everything went ok, and non-zero if something went wrong. The PGP source contains a list of exit codes that are supposed to be returned when the associated events occur. It seems that this does not always work as expected. For example, PGP should return exit code 31 when no passphrase was specified to decrypt the file, but if you try to check a signature, exit code 1 is used to indicate any error, including "No key to check signature" and "Bad signature".

Q: Why does PGP no longer ask for random keystrokes? A: The random keystrokes were necessary to generate random events, but newer PGPs acquire these events automatically. PGP 5.x and up for the Microsoft Windowses and Mac OS uses (the timing of) system events that go on all the time to constantly update the random seed file randseed.bin file. These events include disk access, keystrokes, mouse movements and other things that are reasonably random. If you check, you will see that the randseed.bin's last modified date often changes, even if you are not using PGP. Under UNIX-like systems, PGP 5.x and GNU Privacy Guard use the output of the random device /dev/random when available, which gathers randomness in a similar way. Q: Why can't a person using version 2.3 read my version 2.6 message? A: You are probably using MIT PGP, or possibly some other version of PGP with the legal_kludge option turned off. 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 idea was that people using 2.4 and earlier would be forced to upgrade, and so the patent violating version would no longer be used (see What's with the patent on RSA?). 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. In 2.6.2i and 2.6.3i, this is done by putting Legal_Kludge=off in your config.txt file for PGP. Note that the "old" output can be read perfectly well by newer versions, so if you are corresponding with MIT and 2.3 users, you will be best off with the Legal_Kludge=off statement in your config.txt. Q: Why does PGP 2.x complain about checking signatures every so often? A: Version 2.3a introduced the "pkcs_compat" option, allowing the format of signatures to change slightly to make them more compatible with industry standards. MIT PGP, because it uses the RSAREF library, is unable to understand the old signature format, so it therefore ignores the signature and warns you that it is doing so. 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 with a newer version of PGP. 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. --------------------------------------------------------------------------------

Chapter 3. Security Questions Q: How secure is PGP? Q: Can't you break PGP by trying all of the possible keys? Q: How secure is the conventional cryptography option? Q: Can the NSA crack PGP (or RSA, DSS, IDEA, 3DES,...)? Q: Has RSA ever been cracked publicly? Q: What is the best way to crack PGP? Q: What if I forget my pass phrase? Q: Why do you use the term "pass phrase" instead of "password"? Q: If my secret key ring is stolen, can my messages be read? Q: How do I choose a pass phrase? Q: How do I remember my pass phrase? Q: How do I verify that my copy of PGP has not been tampered with? Q: How do I know that there is no trap door in the program? Q: I heard that the NSA put a back door in MIT PGP, and that they only allowed it to be legal with the back door. Q: Is there a back door in the international version? Q: Can I put PGP on a multi-user system like a UNIX machine or a mainframe? Q: Can I use PGP under a "swapping" operating system like Windows, OS/2 or UNIX? Q: Aren't all of these security procedures a little paranoid? Q: Can I be forced to reveal my pass phrase in any legal proceedings? Q: How secure is the "for your eyes only" option? Q: How secure is PGP? A: Very secure against eavesdroppers. The cryptographic algorithms used for encryption and signing in PGP are very well researched and have shown no practical weaknesses (see Can't you break PGP by trying all of the possible keys?>). The big unknown in any encryption scheme based on RSA is whether or not there is an efficient way to factor huge numbers, or if there is some backdoor algorithm that can break the code without solving the factoring problem. Even if no such algorithm exists, it is still believed that RSA is the weakest link in the PGP chain. A: PGP does not protect you if you use your secret key on a compromised system, i.e. you type your passphrase and sign or decrypt something, or if you stored the passphrase in plaintext on the compromised system (as described in How can I give my passphrase to the commandline PGP automatically?). If you use PGP on a compromised system, the attacker can capture your passphrase as you type it. In combination with you secret keyring, this is sufficient to decode all messages that where encrypted with your public key and signing documents in your name thus impersonating you. Make sure you keep your system secure from such compromises! A: These are the most important attacks you should be aware of. It would be beyond the goal of this FAQ to discuss all possible attacks against or possible flaws in PGP. If you want to know more than what is available in here, see infiNity's PGP Attack FAQ.

Q: Can't you break PGP by trying all of the possible keys? A: This is one of the first questions that people ask when they are first introduced to cryptography. They do not understand the size of the problem. For the IDEA encryption scheme, a 128 bit key is required. Any one of the 2128 possible combinations would be legal as a key, and only that one key would successfully decrypt the message. Let's say that you had developed a special purpose chip that could try a billion keys per second. This is far beyond anything that could really be developed today. Let's also say that you could afford to throw a billion such chips at the problem at the same time. It would still require over 10,000,000,000,000 years to try all of the possible 128 bit keys. That is something like a thousand times the age of the known universe! While the speed of computers continues to increase and their cost decrease at a very rapid pace, it will probably never get to the point that IDEA could be broken by the brute force attack. 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 a well researched algorithm, and although work still needs to be done on it as it relates to complexity theory, 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 to be unworkable. Similarly all of the symmetrical algorithms additionally available in the 5.x and GNU Privacy Guard are not known to have significant flaws: 3DES is probably the most studied cryptographic algorithm ever. It offers the strength equivalent to a 112-bit block cipher. The best attacks published require massive amounts of storage and still take more than 2108 operations. CAST is a well studied 128-bit algorithm. There is no known way of breaking it faster then brute force. AES or Rijndael is a newcomer in crypto-algorithms, chosen to replace DES/3DES with larger keys (128, 192 or 256 bit) and higher performance. Although there is a lot of attention to all the AEScontestants and finalists in general and Rijndael in particular, it hasn't had nearly as much scrutiny as the previously mentioned algorithms. Blowfish and its newer cousin (and AES-finalist) Twofish have gotten much (media) attention but are both still relatively new. Because of they do not seem encumbered by patents and there are no serious, publicly known attacks, these algorithms are popular with many open source projects.

Q: How secure is the conventional cryptography option? A: Assuming that you are using a good strong random pass phrase, it is actually much stronger than the normal mode of encryption because you have removed RSA which is believed to be the weakest link in the chain. Of course, in this mode, you will need to exchange secret keys ahead of time with each of the recipients using some other secure method of communication, such as an inperson meeting or trusted courier. This option is especially useful if you want to back up sensitive files, or want to take an encrypted file

to another system where you will decrypt it. Now you don't have to take your secret key with you. It will also be useful when you lose your secret key. And you can even pick a different passphrase for each file you encrypt, so that an attacker who manages to get one file decrypted can't decrypt all the other files as well. Q: Can the NSA crack PGP (or RSA, DSS, IDEA, 3DES,...)? A: This question has been asked many times. If the NSA were able to crack RSA or any of the other well known cryptographic algorithms, you would probably never hear about it from them. Now that RSA and the other algorithms are very widely used, it would be a very closely guarded secret. The best defense against this is the fact the algorithms are known worldwide. There are many competent mathematicians and cryptographers outside the NSA and there is much research being done in the field right now. If any of them were to discover a hole in one of the algorithms, I'm sure that we would hear about it from them via a paper in one of the cryptography conferences. For this reason, when you read messages saying that "someone told them" that the NSA is able to break PGP, take it with a grain of salt and ask for some documentation on exactly where the information is coming from. In particular, the story called NSA Can Break PGP Encryption is a joke. Q: Has RSA ever been cracked publicly? A: Several messages RSA-encrypted with small (< 513 bits) keys have been cracked publicly. Further effort is still ongoing, RSA Security offers prizes for their RSA factoring challenges. First was the RSA-129 key. The inventors of RSA published a message encrypted with a 129-digits (430 bits) RSA public key, and offered $100 to the first person who could decrypt the message. In 1994, an international team coordinated by Paul Leyland, Derek Atkins, Arjen Lenstra, and Michael Graff successfully factored this public key and recovered the plaintext. The message read: "THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE" They headed a huge volunteer effort in which work was distributed via E-mail, fax, and regular mail to workers on the Internet, who processed their portion and sent the results back. About 1600 machines took part, with computing power ranging from a fax machine to Cray supercomputers. They used the best known factoring algorithm of the time; better methods have been discovered since then, but the results are still instructive in the amount of work required to crack a RSA-encrypted message. The coordinators have estimated that the project took about eight months of real time and used approximately 5000 MIPS-years of computing time. What does all this have to do with PGP? The RSA-129 key is approximately equal in security to a 426bit PGP key. This has been shown to be easily crackable by this project. PGP used to recommend 384bit keys as "casual grade" security; recent versions offer 768 bits as a recommended minimum security level. Note that this effort cracked only a single RSA key. If this had been a PGP key, it would have allowed them to decrypt all messages encrypted to that key. Nothing was discovered during the course of the experiment to cause any other keys to become less secure than they had been, i.e. it would not make it any easier to read messages encrypted to other keys.

A year later, the first real PGP key was cracked. It was the infamous Blacknet key, a 384-bits key for the anonymous entity known as "Blacknet". A team consisting of Alec Muffett, Paul Leyland, Arjen Lenstra and Jim Gillogly managed to use enough computation power (approximately 1300 MIPS) to factor the key in three months. It was then used to decrypt a publicly-available message encrypted with that key. The most important thing in this attack is that it was done in almost complete secrecy. Unlike with the RSA-129 attack, there was no publicity on the crack until it was complete. Most of the computers only worked on it in spare time, and the total power is well within reach of a large, perhaps even a medium sized organization. Q: What is the best way to crack PGP? A: Currently, the best attack possible on PGP itself is a dictionary attack on the pass phrase. This is an attack where a program picks words out of a dictionary and strings them together in different ways in an attempt to guess your pass phrase. 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. There is a program available which can "crack" conventionally encrypted files by guessing the passphrase. It does not do any cryptanalysis and works on the 2.x-format only, so if you pick a strong passphrase your files will still be safe. Unfortunately the original website has vanished. The program is still widely available, e.g. at zedz.net. There are also other methods to get at the contents of an encrypted message, such as bribery, tapping your keyboard, installing trojan horses, snooping of electronic emanation from the computers processing the message (often called a TEMPEST attack), blackmail, or rubber-hose cryptoanalysis (beating you with a rubber hose until you give the passphrase or similar, see Can I be forced to reveal my pass phrase in any legal proceedings?). Q: What if I forget my pass phrase? A: In a word: don't. If you forget your pass phrase, there is absolutely no way to recover any encrypted files. If you're concerned about forgetting your passphrase, you could make a copy of your secret keyring, change its passphrase to something else you are sure not to forget, and then store the secret keyring with the changed passphrase in a safe location. Q: Why do you use the term "pass phrase" instead of "password"? A: This is because most people, when asked to choose a password, select some simple common word. This can be cracked by a program that uses a dictionary to try out passwords on a system. Since most people really don't want to select a truly random password, where the letters and digits are mixed in a nonsense pattern, the term pass phrase is used to urge people to at least use several unrelated words in sequence as the pass phrase.

Q: If my secret key ring is stolen, can my messages be read? A: No, not unless they have also stolen your secret pass phrase or you foolishly put it in plaintext on the same disk (see How can I give my passphrase to the commandline PGP automatically?), or if your pass phrase is susceptible to a brute-force attack. Neither part is useful without the other. You should, however, revoke that key and generate a fresh key pair using a different pass phrase just to be sure. Before revoking your old key, you might want to add another user ID that states what your new key id is so that others can know of your new address. Q: How do I choose a pass phrase? A: All of the security that is available in PGP can be made absolutely useless if you don't choose a good pass phrase to encrypt your secret key ring. Too many people use their birthday, their telephone number, the name of a loved one, or some easy to guess common word. While there are a number of suggestions for generating good pass phrases, the ultimate in security is obtained when the characters of the pass phrase are chosen completely at random. It may be a little harder to remember, but the added security is worth it. As an absolute minimum pass phrase, I would suggest a random combination of at least 8 letters and digits, with 12 being a better choice. With a 12 character pass phrase made up of the lower case letters a-z plus the digits 0-9, you have about 62 bits of key, which is 6 bits better than the 56 bit DES keys. If you wish, you can mix upper and lower case letters in your pass phrase to cut down the number of characters that are required to achieve the same level of security. 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. See Randall T. Williams' Passphrase FAQ for a more detailed analysis. Q: How do I remember my pass phrase? A: This can be quite a problem especially if you are like me and have about a dozen different pass phrases that are required in your everyday life. Writing them down someplace so that you can remember them would defeat the whole purpose of pass phrases in the first place. There is really no good way around this. Either remember it, or write it down someplace and risk having it compromised. It may be a good idea to periodically try out all the passphrases, or to iterate them in your mind. Repeating them often enough will help keep them from being completely blanked out when the time comes that you need them. If you use long passphrases, it may be possible to write down the initial portion without risking compromising it, so that you can read the "hint" and remember the rest of the passphrase. If you chose to write down these (partial) passphrases, consider putting them in an tamper evident, non-transparent enveloppe and storing them in a secure place. For a simple way to pick provably strong passphrases that are easy to remember, please see Arnold Reinhold's Diceware website. Q: How do I verify that my copy of PGP has not been tampered with?

A: If you do not presently own any copy of PGP, use great care on where you obtain your first copy. What I would suggest is that you get two or more copies from different sources that you feel that you can trust. Compare the copies to see if they are absolutely identical. This won't eliminate the possibility of having a bad copy, but it will greatly reduce the chances. If you already own a trusted version of PGP, it is easy to check the validity of any future version. Newer versions of 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. Q: How do I know that there is no trap door in the program? A: The fact that the entire source code for the free versions of PGP is available makes it just about impossible for there to be some hidden trap door. The source code has been examined by countless individuals and no such trap door has been found. To make sure that your executable file actually represents the given source code, all you need to do is to compile the program yourself and use the resulting executable. For the PGP 5.x and higher versions based on the PGPsdk so its sourcecode can be verified, but the use of "home-compiled" binaries seems to be forbidden by the license, even when you bought a commercial license for the same product. Only comparison between a "home-compiled" binary and the binaries as provided in the commercial package seems to be allowed, but this very hard and has not been succesfully done as far as I know (even if exactly the same compiler with exactly the same options would be used, the resulting binary would differ in non-trivial ways). Bottom line: if you do not trust NAI to have sold you the untampered version, you should be using one of the open source versions whose license does allow compilation from source and use of the subsequent binary. Q: I heard that the NSA put a back door in MIT PGP, and that they only allowed it to be legal with the back door. A: First of all, the NSA had nothing to do with PGP becoming "legal". The legality problems solved by MIT PGP had to do with the alleged patent on the RSA algorithm used in PGP. 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 was). 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! Q: Is there a back door in the international version? A: No. The international version of PGP is based on an illegally exported version of PGP, and uses an RSA encryption/decryption library (MPILIB) which may have violated the RSA patent which is only valid in the USA (see What's with the patent on RSA?). There are no intentional backdoors of any kind in the international version, nor is the encryption strength reduced in any way.

Q: Can I put PGP on a multi-user system like a UNIX machine or a mainframe? A: Yes. PGP will compile and run on several high-end operating systems such as Unix and VMS. Other versions may easily be used on machines connected to a network. 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. Also do not leave the passphrase around (see How can I give my passphrase to the commandline PGP automatically?). 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, IPSec or SSH), 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. 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. Of course, it all comes down to how important you consider your secret key. If it's only used to sign posts to Usenet, and not for important private correspondence, you don't have to be as paranoid about guarding it. If you trust your system administrators, then you can protect yourself against malicious users by making the directory in which the keyrings are only accessible by you. Q: Can I use PGP under a "swapping" operating system like Windows, OS/2 or UNIX? A: Yes. PGP 2.x runs OK in most "DOS windows" for these systems, and PGP can be built natively for many of them as well. 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. Because swapfiles shrink, and many applications (e.g. Microsoft Word and Microsoft compilers) grab disk space (and unused memory) and don't always fill it all out, you will regularly get fragments of other work embedded in files unrelated to it. Disabling swapping (after getting more memory) will help, but you should also be cautious about sending binary attachments (like Word DOCs). If you wish to keep your hard-drive more secure, you should consider a sector-level encryptor (such as Scramdisk, SFS or PGPdisk).

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. Many of them perform not nearly as well as claimed in the documentation though. Under OpenBSD you can configure the OS to encrypt the swap, preventing this altogether. Q: Aren't all of these security procedures a little paranoid? A: That all depends on how much your privacy means to you! Even apart from the government, there are many people out there who would just love to read your private mail. And many of these individuals would be willing to go to great lengths to compromise your mail. Look at the amount of work that has been put into some of the virus programs that have found their way into various computer systems, including the old "Caligula"-virus that sends the PGP secret keyring to the codebreakers.org site. Even when it doesn't involve money, some people are obsessed with breaking into systems. Once a system is compromised, use of PGP on that system will expose both your pass phrase and secret keyring, giving the attacker everything to he needs to read your secret mail. 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). Q: Can I be forced to reveal my pass phrase in any legal proceedings? A: Bert-Jaap Koops has a Crypto and Self-Incrimination FAQ adressing this issue. The ultra-short version is that no country is known to have a law requiring suspects to decrypt under legal warrant, with the exception of the UK and the Regulation of Investigatory Powers Act 2000. Note that the GNU Privacy Guard has a --show-session-key option specifically for those under the obligation to provide the decryption key. It allows one to disclose the individual session keys of encrypted messages instead of the longlived secret keys. Without disclosure of your secret keys, newly encrypted messages are still safe from all prying eyes. Note that law enforcement agencies have been known to install means to capture your passphrase and/or plaintext, such as keyboard sniffers and trojans, making the self-incrimination question irrelevant. Q: How secure is the "for your eyes only" option? A: It is not secure at all. There are many ways to defeat it. Probably the easiest way is to simply redirect your screen output to a file as follows: pgp [filename] > [diskfile] The "for your eyes" option was not intended as a fail-safe option to prevent plain text files from being

generated, but to serve simply as a warning to the person decrypting the file that he probably shouldn't keep a copy of the plain text on his system. -------------------------------------------------------------------------------Chapter 4. Keys Q: Which key size should I use? Q: Can a public key be forged? Q: How do I detect a forged key? Q: Why does PGP take so long to add new keys to my key ring? Q: How can I extract multiple keys into a single armored file with the command line PGP? Q: I tried encrypting the same message to the same address two times and got completely different outputs. Why is this? Q: What does the message "Unknown signator, can't be checked" mean? Q: How do I get PGP to display the trust parameters on a key? Q: Should I include my key in every message (e.g. by putting it in my .signature)? Q: How can I make my key available via finger? Q: How do I specify which key to use when an individual has 2 public keys and the very same user ID on each, or when 2 different users have the same name? Q: Which key size should I use? A: PGP gives you choices for RSA and DSA key size ranging from 512 to 2048 or even 4096 bits. The larger the key, the more secure the RSA/DSA portion of the encryption is. The only place where the key size makes a large change in the running time of the program is during key generation. A 1024 bit key can take 8 times longer to generate than a 384 bit key. Fortunately, this is a one time process that doesn't need to be repeated unless you wish to generate another key pair. During encryption, only the RSA portion of the encryption process is affected by key size. The RSA portion is only used for encrypting the session key used by the the symmetrical algorithm (IDEA, 3DES, CAST etcetera). The main body of the message is totally unaffected by the choice of RSA key size. Dr Lenstra and Dr Verheul offer their recommendations for keylengths. In their calculation, a 2048 bit key should keep your secrets safe at least until 2020 against very highly funded and knowledgable adversaries (i.e. you have the NSA working against you). Against lesser adversaries such as mere multinationals your secret should be safe against bruteforce cryptoanalysis much longer, even with 1024 bit keys. So unless you have a very good reason for doing otherwise, select the 1024 or 2048 bit key size. Using currently available algorithms for factoring and available computing power, the 384 and 512 bit keys are known to be within reach of adversaries and 768 is questionable (see also Can't you break PGP by trying all of the possible keys?>). Q: Can a public key be forged? A: In short: not completely, but parts may be. There are four components in a public key, each of which has its own weaknesses. The four

components are user IDs, key IDs, signatures and the key fingerprint. It is quite easy to create a fake user ID. If a user ID on a key is changed, and the key is then added to another keyring, the changed user ID will be seen as a new user ID and so it gets added to the ones already present. This implies that an unsigned user ID should never be trusted. Question Should I sign my own key?> discusses this in more detail. It is possible to create a key with a chosen key ID. A PGP key ID is just the bottom 64 bits of the public modulus (but only the bottom 32 bits are displayed with pgp -kv). It is easy to select two primes which when multiplied together have a specific set of low-order bits. --Paul Leyland explains: This makes it possible to create a fake key with the same key ID as an existing one. The fingerprint will still be different, though. By the way, this attack is sometimes referred to as a DEADBEEF attack. This term originates from an example key with key ID 0xDEADBEEF which was created to demonstrate that this was possible. There are currently no methods to create a fake signature for a user ID on someone's key. To create a signature for a user ID, you need the signatory's secret key. A signature actually signs a hash of the user ID it applies to, so you can't copy a signature from one user ID to another or modify a signed user ID without invalidating the signature. Yes, it is possible to create a public key with the same fingerprint as an existing one, thanks to a design misfeature in PGP 2.x when signing RSA keys. The fake key will not be of the same length, so it should be easy to detect. Usually such keys have odd key lengths. Inside a PGP key, the public modulus and encryption exponent are each represented as the size of the quantity in bits, followed by the bits of the quantity itself. The key fingerprint, displayed by pgp -kvc, is the MD5 hash of the bits, but NOT of the lengths. By transferring low-order bits from the modulus to the high-order portion of the exponent and altering the two lengths accordingly, it is possible to create a new key with exactly the same fingerprint. --Paul Leyland provided the following technical explanation:

Q: How do I detect a forged key? A: As explained in question Can a public key be forged?>, each component of the public key can be faked. It is, however, not possible to create a fake key for which all the components match. For this reason, you should always verify that key ID, fingerprint, and key size correspond when you are about to use someone's key. And when you sign a user ID, make sure it is signed by the key's owner!

Similarly, if you want to provide information about your key, include key ID, fingerprint and key size. Q: Why does PGP take so long to add new keys to my key ring? A: The time required to check signatures and add keys to your public key ring tends to grow as the square of the size of your existing public key ring. This can reach extreme proportions, especially if you are trying to add the entire public keyring you retrieved from a keyserver (see What are the Public Key Servers?>) to your own keyring. In this case, it might be faster to rename your public keyring to something else, then name the keyserver's keyring pubring.pgp and add your own keyring to the big one. There is a danger to this, though; the trust parameters to your old keys will be lost, and you will be using the trust parameters from this big keyring. See also How do I create a secondary key file?>. A: If your keyring has been damaged, PGP can also take a while to process it. Q: How can I extract multiple keys into a single armored file with the command line PGP? A: A number of people have more than one public key that they would like to make available. One way of doing this is executing the -kxa command for each key you wish to extract from the key ring into separate armored files, then appending all the individual files into a single long file with multiple armored blocks. This is not as convenient as having all of your keys in a single armored block. Unfortunately, the present version of PGP does not allow you to do this directly. Fortunately, there is an indirect way to do it. pgp -kx uid1 extract pgp -kx uid2 extract pgp -kx uid3 extract

This puts all three keys into extract.pgp. To get an ascii amored file, call: pgp -a extract.pgp You get an extract.asc. Someone who does a pgp extract and has either file processes all three keys simultaneously. A Unix script to perform the extraction with a single command would be as follows: #!/bin/sh for name in name1 name2 name3 ... ; do pgp -kx "$name" /tmp/keys.pgp <keyring> end An equivalent DOS command would be:

for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <keyring> Q: I tried encrypting the same message to the same address two times and got completely different outputs. Why is this? A: Every time you run PGP, a different session key is generated. This session key is used as the key for the symmetrical encryption algorithm (IDEA, 3DES etcetera). As a result, the entire header and body of the message changes. You will never see the same output twice, no matter how many times you encrypt the same message to the same address. This adds to the overall security of PGP. To generate this random session key, PGP will try to use information from a file called randseed.bin. If this file does not exist, or for some reason isn't random enough, you are asked to type in some random keystrokes which will then be used as a "seed" for the random number generator. Q: What does the message "Unknown signator, can't be checked" mean? A: It means that the key used to create that signature does not exist in your public keyring, therefor PGP complains that it cannot check the signature. If at sometime in the future, you happen to add that key to your public keyring, then the signature line will read normally. It is completely harmless to leave these non-checkable signatures in your public keyring. They neither add to nor take away from the validity of the key in question. Q: How do I get PGP to display the trust parameters on a key? A: You can only do this when you run the -kc option by itself on the entire database. The parameters will not be shown if you give a specific ID on the command line. The correct command is: pgp -kc. The command pgp -kc smith will not show the trust parameters for "smith". Q: Should I include my key in every message (e.g. by putting it in my .signature)? A: No. Although it is important to spread your key as far as possible, it is a lot better to send it to a keyserver (see What are the Public Key Servers?>) or to make it available via finger (see How can I make my key available via finger?>>), or perhaps as a link off your WWW homepage. This way, people who need your key will be able to get it, and you don't send it out to a lot of uninterested people every time you email or post something. Additionally, keep in mind a snooper reading your outgoing mail can easily switch the public key in there with his own fake key. If this substituted key is used, the snooper can still read the messages sent to you. If the other party gets your key from a different location with a different method, it is a lot harder for that snooper to change the keys. Note that signing the message containing the key will not help; the snooper can easily re-sign the message with his key, see Can a public key be forged?>. So always check the fingerprint as described in How do I detect a forged key?>. Q: How can I make my key available via finger? A: The first step is always to extract the key to an ASCII-armored text file with pgp -kxa. After that, it depends on what type of computer you want your key to be available on. Check the documentation for that computer and/or its networking software.

Many computers running a Unix flavor will read information to be displayed via finger from a file in your home directory called .plan. If your computer supports this, you can put your public key in this file. Make sure the file is world-readable, use chmod 644 $HOME/.plan if other people can't get at your plan. The home directory also has to be accessible. Use chmod +x $HOME in your home directory to do this. Contact your system administrator if you have further problems with this. Q: How do I specify which key to use when an individual has 2 public keys and the very same user ID on each, or when 2 different users have the same name? A: Instead of specifying the user's name in the ID field of the PGP command, you can use the key ID number. The format is 0xNNNNNNNN where NNNNNNNN is the user's 8 character key ID number. It should be noted that you don't need to enter the entire ID number, a few consecutive digits from anywhere in the ID should do the trick. The key ID shows up directly after the key size when you do pgp -kv userid. Be careful: If you enter 0x123, you will be matching key IDs 0x12393764, 0x64931237, or 0x96412373. Any key ID that contains 123 anywhere in it will produce a match. They don't need to be the starting characters of the key ID. You will recognize that this is the format for entering hex numbers in the C programming language. For example, any of the following commands could be used to encrypt a file to my public key: pgp -e <filename> "Wouter Slegers" pgp -e <filename> wouter@yourcreativesolutions.nl pgp -e <filename> 0x5217C2AF This same method of key identification can be used in the config.txt file in the MyName variable to specify exactly which of the keys in the secret key ring should be used for encrypting a message.

-------------------------------------------------------------------------------Chapter 5. Message Signatures Q: What is message signing? Q: How do I sign a message and keep it readable? Q: Can't you just forge a signature by copying the signature block to another message? Q: Are PGP signatures legally binding? Q: Is the date on a PGP signature reliable? Q: What is message signing? A: Let's imagine that you received a letter in the mail from someone you know named John Smith. How do you know that it was really John who sent you the letter and not someone else who simply forged his name? With PGP, it is possible to apply a digital signature to a message that is impossible to forge. If you already have a trusted copy of John's public encryption key, you can use it to check the signature on the message. It would be impossible for anybody but John to have created the signature, since he is the only person with access to the secret key necessary to create the signature. In addition, if anybody has tampered with an otherwise valid message, the digital signature will detect the fact. It protects the entire message against undetectable change.

Q: How do I sign a message and keep it readable? A: Sometimes you are not interested in keeping the contents of a message secret, you only want to make sure that nobody tampers with it, and to allow others to verify that the message is really from you. For this, you can use clear signing. Clear signing only works on text files, it will not work on binary files. The command format is: pgp -sat +clearsig=on <filename> 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. You should be careful when you "clearsign" a text file like this. Some mail programs might alter your message when it is being sent, for example because there are very long lines in the message. This will invalidate the signature on the message. Also, using 8-bit characters in your message can cause problems; some versions of PGP will think the file is actually a binary file, and refuse to clearsign it. For this reason, PGP 2.6.3i will automatically ASCII armor messages with very long lines in it. When using PGP/MIME, the signature is sent as an attachment to the message. This keeps the signed text readable like usual, even to MIME-compatible email programs that do not support PGP. Q: Can't you just forge a signature by copying the signature block to another message? A: No. The reason for this is that the signature contains information (called a message digest or a oneway hash) about the whole message it's signing. When the signature check is made, the message digest from the message is calculated and compared with the one stored in the encrypted signature block. If they don't match, PGP reports that the signature is bad. Q: Are PGP signatures legally binding? A: Simone van der Hof maintains the Digital Signature Law Survey adressing these issues. In short: digital signatures (such as provided by PGP) are only legally binding on their own under very specific situations in a few countries, if at all. In many countries this is rapidly changing though. Even if the digital signature is not binding in itself, in many jurisdictions one can arrange to accept valid digital signatures as binding via a prior agreement in writing. If you are going to be swapping many digitally-signed agreements with another party, this approach may be useful. You might want to check with a lawyer in your country if the digital signatures will be used for important or valuable contracts. Q: Is the date on a PGP signature reliable? A: No. The date and time you see when you verify a PGP signature on a file (often called a timestamp) is the time and date the computer was set to when the signature was created. On most computers, it is extremely easy to reset the date and time to any time you want, so you can generate documents with a forged timestamp. For this reason, you can use a so-called "digital notary" or time-stamping service. This is a system that

does nothing but sign documents you send to it, after inserting a date and time somewhere in the text. The service uses a numbering scheme which makes it impossible to insert timestamps at a later time. One such service is run by Matthew Richardson. For more information about it, please see the PGP Digital Timestamping Service website. -------------------------------------------------------------------------------Chapter 6. Key Signatures Q: What is key signing? Q: How do I sign a key? Q: Should I sign my own key? Q: Should I sign X's key? Q: How do I verify someone's identity? Q: How do I know someone hasn't sent me a bogus key to sign? Q: What's a key signing party? Q: How do I organize a key signing party? Q: What is key signing? A: OK, you just got a copy of John Smith's public encryption key. How do you know that the key really belongs to John Smith and not to some impostor? The answer to this is key signatures. They are similar to message signatures in that they can't be forged. Let's say that you don't know that you have John Smith's real key. But let's say that you do have a trusted key from Joe Blow. Let's say that you trust Joe Blow and that he has added his signature to John Smith's key. If you trust Joe to identify John, you can now trust that you have a valid copy of John Smith's key. That is what key signing is all about. This chain of trust can be carried to several levels, such as A trusts B who trusts C who trusts D, therefore A can trust D. You have control in the PGP configuration over exactly how many levels this chain of trust is allowed to proceed. The options in PGP's configuration to control this are: Cert_Dept = n This indicates the maximum depth of your "web of trust". A key which is n keys "away" from your own key will not be used to introduce other keys. Completes_Needed = n This indicates the number of completely trusted keys required to make a key valid. A key is completely trusted if it is valid, and you choose option 4. Yes, always when PGP asked you if you trust this person to introduce others. Marginals_Needed = n This indicates the number of marginally trusted keys required to make a key valid. A key is marginally trusted if you answered 3. Sometimes to the question above. In all other cases, the key is not trusted at all.

You can display the trust parameters for a key with pgp -kc. See also question How do I get PGP to display the trust parameters on a key?>. Be careful about keys that are several levels removed from your immediate trust. The PGP trust model is discussed in more detail by Alfarez Abdul-Rahman. Q: How do I sign a key? A: Execute the following command from the command prompt: PGP -ks [-u yourid] <keyid> This adds your signature (signed with the private key for yourid, if you specify it) to the key identified with keyid. If keyid is a user ID, you will sign that particular user ID; otherwise, you will sign the default user ID on that key (the first one you see when you list the key with pgp -kv <keyid>). Next, you should extract a copy of this updated key along with its signatures using the -kxa option. An armored text file will be created. Give this file to the owner of the key so that he may propagate the new signature to whomever he chooses. Be very careful with your secret keyring. Never be tempted to put a copy in somebody else's machine so you can sign their public key: they could have modified PGP to copy your secret key and grab your pass phrase. Q: Should I sign my own key? A: Yes, you should sign each personal ID on your key, which is why in PGP 5.x+ and GNU Privacy Guard newly generated keys are signed by default. This will help to prevent anyone from placing a phony address in the ID field of the key and possibly having your mail diverted to them. Of course they can't read the encrypted mail, but you won't see it at all. And even worse, adding a fake user ID reading "Please use key 0x416A1A35 from now on" can mean someone else will use the imposter's key with your name on it, rather than your own. It is very easy to add user IDs to someone else's key. All it takes is a binary editor or some knowledge of the PGP public key format. But since you are the only person who can sign your own user IDs, the fake ones will not be signed, and so anyone who gets the key can immediately spot the fake ones. For example, my entry in the public key ring now appears as follows if you use the -kvv command: Type Bits/KeyID Date User ID pub 1024/416A1A35 1994/10/01 Arnoud Engelfriet <galactus@stack.nl> sig 416A1A35 Arnoud Engelfriet <galactus@stack.nl> *** <galactus@stack.urc.tue.nl> now INVALID! sig 416A1A35 Arnoud Engelfriet <galactus@stack.nl> Galactus <galactus@stack.urc.tue.nl> sig 3602A619 Stephen Hopkins <shopkins@coventry.ac.uk> sig DD63EF3D Frank Castle <Frank_Castle@panther.pphost.nl> sig 416A1A35 Arnoud Engelfriet <galactus@stack.nl>

sig sig sig

Arnoud Engelfriet <galactus@stack.urc.tue.nl> 390E3FB1 Martijn Heemels <M.A.L.Heemels@stud.tue.nl> DA87C0C7 Edgar W. Swank <EdgarSwank@Juno.com> 416A1A35 Arnoud Engelfriet <galactus@stack.nl>

For a more detailed discussion of why you should sign your own key, see "Why you should sign your own key" by Walther Soldierer. Note that PGP 2.6.3[i], PGP 5.x and GNU Privacy Guard automatically sign each user ID you add to your own key. Q: Should I sign X's key? A: Signing someone's key is your indication to the world that you believe that key to rightfully belong to that person, and that person is who he purports to be. Other people may rely on your signature to decide whether or not a key is valid, so you should not sign capriciously. 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 Mallet over there." Mallet may be an ax murderer; you don't become tainted with his crime just because you can pick him out of a crowd. Q: How do I verify someone's identity? A: It all depends on how well you know them. Relatives, friends and colleagues are easy. People you meet at conventions or key-signing sessions require some proof like a driver's license or passport. Do make sure to observe the standard keysigning security steps described in How do I know someone hasn't sent me a bogus key to sign?>. Q: How do I know someone hasn't sent me a bogus key to sign? A: It is very easy for someone to generate a key with a false ID and send e-mail with fraudulent headers, or for a node which routes the e-mail to you to substitute a different key. Finger or keyservers are bit harder to tamper with, but not impossible. 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 <userid>). To be sure, also ask them for the key size and its key ID. There are ways to create a forged key with an identical fingerprint (see question Can a public key be forged?> for details). You can of course also check these details in another way, for example if he has printed it on his business card.

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 email 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. Q: What's a key signing party? A: A key signing party is a get-together with various other users of PGP for the purpose of meeting and signing keys. This helps to extend the web of trust to a great degree, making it easier for you to find one or more trusted paths to someone whose public key you didn't have. Kevin Herron has an example of a keysigning party announcement page. Q: How do I organize a key signing party? A: Though the idea is simple, actually doing it is a bit complex, because you don't want to compromise other people's private keys or spread viruses (which is a risk whenever floppies are swapped willynilly). Usually, these parties involve meeting everyone at the party, verifying their identity and getting key fingerprints from them, and signing their key at home. Derek Atkins 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: You announce the keysigning 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. You compile the public keys into a single keyring, run pgp -kvc on that keyring, and save the output to a file. Print out N copies of the pgp -kvc file onto hardcopy, and bring this and the keyring on media to the meeting. 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). 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"). 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. 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.

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.

-------------------------------------------------------------------------------Chapter 7. Revoking a key Q: My secret key ring has been stolen or lost, what do I do? Q: I forgot my pass phrase. Can I create a key revocation certificate? Q: How do I create a key revocation certificate? Q: How do I indicate that my key is invalid when I don't have the secret key anymore? Q: My secret key ring has been stolen or lost, what do I do? A: Assuming that you selected a good solid random pass phrase to encrypt your secret key ring, you are probably still safe. It takes two parts to decrypt a message, the secret key ring, and its pass phrase. The secret key is encrypted with the passphrase before it is stored in the secret keyring. Assuming you have a key revocation certificate previously made (or a backup copy of your secret key ring with which you can generate one now), upload the revocation to one of the public key servers. Prior to uploading the revocation certificate, you might add a new ID to the old key that tells what your new key ID will be. If you don't have a backup copy of your secret key ring, then it will be impossible to create a revocation certificate under the present version of PGP. This is another good reason for keeping a backup copy of your secret key ring (or at the very least generate a revocation certificate). Q: I forgot my pass phrase. Can I create a key revocation certificate? A: As Phil Zimmermann put it: "I'm sorry, you're hosed." You can't, since the pass phrase unlocks the secret key which is required to create the certificate (for signing it). 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. Q: How do I create a key revocation certificate? A: The easiest way to do this is: Make a backup of your public and secret keyrings. Revoke your key with pgp -kd youruserid. Extract the revoked key to a file with pgp -kxa youruserid. This file is what the manual calls the "revocation certificate."

Store the certificate in a safe location, for example on a floppy which you keep someplace else. Restore the backed-up keyrings.

Q: How do I indicate that my key is invalid when I don't have the secret key anymore? A: This is a very tricky situation, and should be avoided at all costs. The easiest way is to prepare a key revocation certificate (See How do I create a key revocation certificate?> for details on how to do this) before you need it, so you can always revoke the key, even without the secret key. A: First of all, generate a new key with one of the user IDs stating that Old key 0x12345678 no longer valid: lost secret key. Get this key signed by (preferbly the same) friends and collegues. Add this key to the keyservers so people can start using your new key as soon as possible. To discourage use of your old key, you can use a binary editor to change one of the user IDs on your public key to read "Key invalid; use key 0x12345678" or something to that effect. Keep in mind that the new user ID can't be longer than the old one, unless you know what you are doing. Then extract the key, and send it to the keyserver. It will think this is actually a new user ID, and add it to your key there. However, since anyone can do the above, many people will not trust unsigned user IDs with such statements. As explained in question Should I sign my own key?>, all user IDs on your key should be self-signed. So again, make a key revocation certificate in advance and use that when necessary. -------------------------------------------------------------------------------Chapter 8. Public Key Servers Q: What are the Public Key Servers? Q: What public key servers are available? Q: What is the syntax for the key server commands? Q: What are the Public Key Servers? A: Public Key Servers exist for the purpose of making your public key available in a common database where everybody can have access to it for the purpose of encrypting messages to you. Anyone who wants to write you a message, or to check a signature on a message from you, can get your key from the keyserver, so he doesn't have to bother you with it. While a number of key servers exist, it is only necessary to send your key to one of them. The key server will take care of the job of sending your key to all other known servers. Q: What public key servers are available? A: There is now a clean interface to key servers. The pgp.net domain was founded for this purpose, and offers an easy and fast way to obtain people's public keys.

You can access the keyserver in e-mail, by sending mail to <pgp-public-keys@keys.pgp.net> with the command (see What is the syntax for the key server commands?> below) in the Subject line of your message. This message will be sent to one of the keyservers at random, which ensures that an individual server will not be overloaded. If you have WWW access, you can also use the WWW interface. Q: What is the syntax for the key server commands? A: The key server expects to see one of the following commands placed in the subject field. Note that only the ADD command uses the body of the message. 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 *), in multiple messages GET <userid> Get just that one key (-kxa <userid>) LAST <n> Get all keys uploaded during last <n> days

Note that instead of a user ID, you can also use a key ID. In this case, you should put "0x" in front of it. By using a key ID rather than a user ID, name or e-mail address, you ensure that you get exactly the key you want. Please see question How do I specify which key to use when an individual has 2 public keys and and the very same user ID on each?> for more information on how to use key IDs. If you wish to get the entire key ring and have access to FTP, it would be a lot more efficient to use FTP rather than e-mail. Download an entire keyring from PGP.net. -------------------------------------------------------------------------------Chapter 9. Bugs Q: Where do I send bug reports? Q: What bugs have been found in PGP? Q: Where do I send bug reports? A: Bugs related to MIT PGP should be sent to pgp-bugs@mit.edu. You will want to check the MIT PGP FAQ with the complete bug list for MIT PGP before reporting a bug to make sure that the bug hasn't been reported already. If it is a serious bug, you should also post it to comp.security.pgp.announce or .tech. Serious bugs are bugs that affect the security of the program, not compile errors or small logic errors. Post all of your bug reports concerning non-MIT versions of PGP to comp.security.pgp.tech, 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.

Q: What bugs have been found in PGP? A: 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.2i, as well as the Mac versions. 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. The initial release of PGP 2.6.2i 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.2i, make sure you downloaded your copy after 7 May 1995. As reported by Steven Markowitz, the following bugs exist in PGP 4.0 Business Edition (the commercial version): Signature retirement does not work. When I retire a key signature, PGP still treats the key as signed. If I remove the signature from pubring.pgp, but leave the retirement certificate in the keyring, PGP still treats the key as signed. Although encrypt-only keys cannot be used to sign documents, PGP allows them to be used to make key signatures.

The international version of PGP has the undocumented +makerandom command, which can generate a file full of random data. Unfortunately, it does not work as intended, because the random number

generator is not initialized properly. This does not affect normal PGP operation; the bug is only present when +makerandom is used.

Glossary of cryptographic terms Advanced Encryption Standard (AES) The Advanced Encryption Standard will be the new standard cryptographic algorithm for use by U.S. government organizations to protect sensitive (unclassified) information. The algorithm Rijndael was chosen out of a group of contending algorithms. It is intended as the successor for DES. Newer versions of PGP and GPG feature support for AES. Chosen Plain Text Attack 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. Data Encryption Standard (DES) 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 is feasible to build a machine that could crack a 56 bit key in under a day's time as demonstrated by EFF's DES Cracker Project. For this reason, triple-DES or 3DES is introduced. It uses single-DES to encrypt the data, then to "decrypt" it with another key and encrypt the result again with another key. The resulting encryption is as strong as a hypothetical 112-bit DES. Electronic Frontier Foundation (EFF) The Electronic Frontier Foundation (EFF) was founded in July 1990, to assure freedom of expression

in digital media, with a particular emphasis on applying the principles embodied in the Constitution and the Bill of Rights to computer-based communication. For further information, contact: Electronic Frontier Foundation 1001 G St., NW Suite 950 East Washington DC 20001 United States of America <eff@eff.org> +1 202 347 5400 +1 202 393 5509

International Data Encryption Algorithm (IDEA) Developed in Switzerland and used in PGP 2.x as the symmetrical encryption algorithm. For noncommercial use in PGP licensing fees are waved, for commercial use licenses must be purchased (see What's with the patent on IDEA?>). IDEA uses a 128 bit user supplied key to perform a series of nonlinear mathematical transformations on a 64 bit data block. International Traffic in Arms Regulations (ITAR) ITAR are the regulations covering the export of weapons and weapons related technology from the United States. Key Escrow In general, key escrow means that a copy of the secret key needed to decrypt something is stored with a third party. This can be a notary or a bank, who will keep it safely for you, in case you lose your key, or when you die, in which case your relatives might need access to your encrypted material. It is also common in business. When an employee has encrypted material on his company computer, and he leaves, gets fired, or dies unexpectedly, the company might not be able to decrypt the material. This can cost them a lot of money, especially when the employee was working on something very important. For this reason, a copy of the secret key is usually kept by one or more supervisors, who can then decrypt the material if necessary. To ensure that a supervisor does not abuse this power, the key can be split amongst several persons, who have to work together to restore the key. Thanks to the US Clipper initiative, this term is now more or less synonymous with government key escrow, where the government keeps a copy of all the secret keys in the country. This allows them to read all encrypted messages being sent, usually for reasons of national security. Many people object to this type of key escrow, as it can be used to invade people's privacy very easily. Known Plain Text Attack A method of attack on a crypto system where the cryptanalyst has matching copies of plain text, and its encrypted version. With weaker encryption systems, this can improve the chances of cracking the code and getting at the plain text of other messages where the plain text is not known. Message Digest Algorithm #5

(MD5) The message digest algorithm used in PGP is the MD5 Message Digest Algorithm, placed in the public domain by RSA Data Security, Inc. It is conjectured that the difficulty of coming up with two messages having the same message digest is on the order of 264 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2128 operations. The MD5 algorithm has been carefully scrutinized for weaknesses. It is, however, a relatively new algorithm and further security analysis is of course justified, as is the case with any new proposal of this sort. The level of security provided by MD5 should be sufficient for implementing very high security hybrid digital signature schemes based on MD5 and the RSA public-key cryptosystem. --MD5's designer, Ronald Rivest, writes this about MD5:

Million Instructions Per Second (MIPS) MIPS stands for Million Instructions Per Second. Usually, this is an indicator of the computer's brute force power. A MIPS-year is approximately the amount of computing done by a 1 MIPS computer in one year. Multiple Precision Integer Library (MPILIB) This is the common name for the set of RSA routines used in PGP 2.3a and previous, as well as the international versions of PGP. It is alleged to violate PKP's RSA patent in the USA, but is not otherwise restricted in usage. It retains its popularity abroad because it outperforms RSAREF and has fewer legal restrictions as well. National Security Agency (NSA) The NSA is the official communications security body of the U.S. government. It was given its charter by President Truman in the early 50's, and has continued research in cryptology till the present. The NSA is known to be the largest employer of mathematicians in the world, and is also the largest purchaser of computer hardware in the world. Governments in general have always been prime employers of cryptologists. The NSA probably possesses cryptographic expertise many years ahead of the public state of the art, and can undoubtedly break many of the systems used in practice; but for reasons of national security almost all information about the NSA is classified. --The following information is from the sci.crypt FAQ:

One Time Pad (OTP) The one time pad is the only encryption scheme that can be proven to be absolutely unbreakable! It is used extensively by spies because it doesn't require any hardware to implement and because of its absolute security. This algorithm requires the generation of many sets of matching encryption keys

pads. Each pad consists of a number of random key characters. These key characters are chosen completely at random using some truly random process. They are not generated by any kind of cryptographic key generator. Each party involved receives matching sets of pads. Each key character in the pad is used to encrypt one and only one plain text character, then the key character is never used again. Any violation of these conditions negates the perfect security available in the one time pad. So why don't we use the one time pad all the time? The answer is that the number of random key pads that need to be generated must be at least equal to the volume of plain text messages to be encrypted, and the fact that these key pads must somehow be exchanged ahead of time. This becomes totally impractical in modern high speed communications systems. Among the more famous of the communications links using a one time pad scheme is the Washington to Moscow hot line. Pretty Good Privacy (PGP) The program we're discussing. See question What is PGP?>. Rivest-Shamir-Adleman (RSA) RSA is the public key encryption method used in PGP. RSA are the initials of the developers of the algorithm. The basic security in RSA comes from the fact that, while it is relatively easy to multiply two huge prime numbers together to obtain their product, it is computationally difficult to go the reverse direction: to find the two prime factors of a given composite number. It is this one-way nature of RSA that allows an encryption key to be generated and disclosed to the world, and yet not allow a message to be decrypted. RSAREF This is the free library RSA Data Security, Inc., made available for the purpose of implementing freeware PEM applications. It implements several encryption algorithms, including (among others) RSA. MIT PGP uses RSAREF's RSA routines to avoid the alleged patent problems associated with other versions of PGP. Rubber-hose cryptoanalysis A term coined by Marcus J. Ranum to describe the method of breaking a cryptographic key by beating the owner with a rubber hose until he reveals his key, a method practiced in many repressive regimes. It is also used for describing other, less brutal, situations where the owner is forced to give up his keys (see Can I be forced to reveal my pass phrase in any legal proceedings?>). Skipjack TEMPEST TEMPEST is a standard for electromagnetic shielding for computer equipment. It was created in response to the fact that information can be read from computer radiation (e.g., from a CRT) at quite a distance and with little effort. Needless to say, encryption doesn't do much good if the cleartext is available this way. The typical home computer would fail all of the TEMPEST standards by a long shot. So, if you are doing anything illegal, don't expect PGP or any other encryption program to save you. The government could just set up a monitoring van outside your home and read everything that you are doing on your computer.

PGP/MIME To be done. Blowfish To be done. Twofish To be done. CAST To be done. -------------------------------------------------------------------------------Colophon This FAQ is compiled from a DocBook source file, because managing such a large amount of information over longer periods of time is impossible without a stable and proven file format. The DocBook source is converted to its output formats with proven, open-source tools such as N. Walsh's DocBook stylesheets, OpenJade, tidy, w3m and LaTeX, together a custom Makefile and FreeBSD's doc.docbook.mk Makefiles. This allows me to easily maintain a consistent look throughout this FAQ, and to make sure that internal references stay correct.

TheProtectionofYour SecretKey
Version 2.1 - October 2003 Ralf Senderek

PREFACE Thisdocumentwasfirstpublishedin1998toencouragepeopletousePGPnotin blindfaithbutwithacertaindegreeofunderstandingofitsbasicprinciplesand securitymechanisms,andofcoursetoincreasetheirconsciousnessofpossiblerisks which arise during the daily use of PGP. Ihopedtocontributetotheeffordsofotherstomaketheuseofcryptographymore transparentandmorereliable.ButsincetheolddaysofclassicPGPthefurther developmentseemstometoleadintoadifferentdirectionwhichhasmadetheuse ofcryptomorecomplexandmoreintransparentleavingtheuserinadangerous dependenceoncryptocodewhichalmostnobodyfullyunderstandsnoranalysesfor security,asituation,mostusersseemtohaveacceptedwillfuly. SomethinghadtobedonetotackletheinscrutabilityproblemandIbegantowork outaconceptofapurecryptoprogram(PCP)thatusesonlyonesinglebasiccrypto function and will comprise of only the smallest amount of secure and highly readablecodethatwillbeunderstandablenotonlybysecurityexperts. AsmostofthecontentoftheoriginaldocumentisalsorelevantforthePureCrypto Projectyoucanaccessasimilardocumentthatwillexplainthebasicprinciplesof thenewprojectandthatwillmakethesecuritymechanismsclearwithreferencesto theopensourcecodeofPCP.

HowsecureisPGP? Canadigitalsignaturebeforged or canaconfidentialmessagebereadbyunauthorizedindividuals? CanyoucountonPGP'ssecureperformanceatanytime? Theseareseriousquestionswhichcannotbeansweredinasimpleway.FirstofallI wouldliketobrieflysummarizetheessentialresultsofmyjudgementofPGP'ssecurity beforeItrytogivereasonsforthisjudgementindetail. Summary

Explanation

TheSecurityoftheCryptographicMethodsUsedbyPGP TheCipherIDEA ThePublicKeyCryptosystemRSA TheHashfunctionMD5 WhereDoestheSessionKeyComeFrom? ThePrivatePartsofPGP

AttacksontheUseofPGP SecurityrelevantActions HowtoDealwithYourPassphrase AttacksonYourPassphrase WhatIsaGoodPassphrase?

LongLivetheSigningKey!

WorkinginaReliableSecurityEnvironment

TheNewertheBetter?VersionsofPGP

SecurityRelatedProblemsoftheNewSignatureFormat

KeepAnEyeontheThreat

ReferencestoOtherSourcesofInformation

AFinalRequest

Summary WhenusingPGPyougenerallypersuethefollowingobjectives: youintendtoestablishconfidentialityofcommunicationwithotherpeople,in awaythatpreventsotherpeoplereadingthemessageinplaintextexceptofthe intendedaddressee, youintendtoguaranteethereliabilityofthesourceofinformation (authenticity),inawaythatpreventssomeonemasqueradingastheauthorofa messageactuallyhavingbeencreatedbysomebodyelse(protectionofintellectual property), youintendtoguaranteetheintegrityofamessage,inawaythatacomposed messagecannotbechangedaccidentiallyordeliberately. IthasbeenalmosttwoyearssinceIfirstpublishedthisanalysisinAugust1998andmore andmorepeopleareusingthenewestversionofPGPnow.ButIamconvincedthat thereisnobetterrecommendationthantousetheclassicPGPversion2.6.xbased onRSAkeyswithaminimumlengthof1024bittoreachthoseobjectivesreliably.. Securityproblemshavebeendiscoveredrecentlywhichrelatetothecomplexsignature formatbeingusedbynewversionsofPGP.Onecansuspectthatmoresecurityrelated problemswillemanatefromthecomplexityofnewerversionswhichmakestheuseof classicPGPevenmorevaluableinfuture. TherearetwopossiblestrategiestoattackthesecurityofPGP: theoreticalattacks

whichtrytomakeuseofthepossibleweaknessofcryptographicmethods usedbyPGPcompromisingthereliabilityandsecurityofPGP fundamentally,and practicalattacks whichtrytoexploitweaknessesofthepracticaluseofPGP.These attacksintendtocompromisethepassphrasetogainaccesstotheuser's secretkeyortrytodeceiveotherpeoplebydistributingfakedpublickeys. AthirdstrategymightbetolaunchanattackontheimplementationofPGP.This couldbedonebychangingthesourcecodeofPGPbyalteringthefunctionalityofthe cryptographicmethodsbeingusedorbyinsertingnewmaliciouscodewhichmakes securityrelatedinformationaccessibletosomebodyelse.Thecompiledversionofthe manipulatedsourcecoderesultsinabinarywhichmakesithardfortheaverageuserto tellitapartfromthesecureversionofPGP.Asthisisanattempttounderminethe practicaluseofPGP,IwilldealwiththisinsectionIIbelow. TheoreticalattacksonPGPwillbeunsuccessful,asIwillprovesubsequently, becausetheuseofRSAkeysofsufficientlengthmakesitpracticallyimpossible togaintheuser'ssecretkey.Thesecurityofcryptographicmethodsisnotmerely basedonreligousfaithbutcanbejustifiedbythehistoryoffailedattemptstobreak them.Astheoreticalsecurityisbasedontheresultsofrecentresearchinthefieldof computerscienceithastobeconstantlyreviewedinthelightofnewknowledge. Withthepointlessnessofattacksonthecryptographicmethodstheattentionofpotential datafiendsisshiftingtowardstheweaknessesduetothedailyuseofthesecretkey.You havetoconsiderahugenumberofpracticalproblemsifyoudonotwanttoputthe securityofPGPatriskunintentionally.Mostimportantismaintainingthesecrecyof yourpassphrasewhichprotectsyoursecretkeybecausemaintainigthissecrecyis aproblemmostpeopledounderestimatedramatically.

Explanation AsallthecryptographicmethodsusedbyPGP2.6.x(towhichIwillreferas"classicPGP" subsequently)doadifferentjobIwouldliketogiveashortdescriptionoftheirpurpose, beforeIwillvaluetheirreliability.TheasymmetriccipherRSAisusedtoenableaperson toestablishthemselvesastheonlylegitimateauthorortoensurethatonlytheintended personcanreadamessage.AlthoughRSAcoulddoalloftheencryptionanddecryptionof relevantinformation,itisabitslow,whenlongkeysareused,soencryptionand decryptionoflongtextsactuallyisdonebythesymmetriccipherIDEAwhichhasfar betterperformance.StillRSAisusedtolinktoasinglepersontheabilitytoindividually

decryptamessageortosignadocument.Sothereisacombinationofamethodusinga pairofkeysassignedtoasingleperson(RSA)andamethodusinganarbitrarysession keyforencryptionanddecryption(IDEA).AthirdmethodwhichisputtousebyPGPis thehashfunctionMD5.Itsonlypurposeistoconvertaverylongtextintoasinglenumber of39decimaldigitswhichisusedasafingerprinttoreplacethelongtextinadigital signature.

TheSecurityoftheCryptographicMethodsUsedbyPGP TheCipherIDEA Canyoureallybesurethatonlythelegitimaterecipientofyourmessageisable toreaditinplaintext? ForencryptionofthetextclassicPGPusesIDEA,whichissymmetricandworkswitha keyof128bitsoflength,forinstance 1010100101010010010010101010111101010101101100111101010000101110 1000011010110001001011110111001101111011010111111101011011000100 toencryptamessage.Thesamekeyhastobeappliedtothecryptedtexttoconvertitinto theoriginalmessage,andanyotherkeywouldleavemeaninglessgibberish.Themessage issplitintoblocksof8byteswhichareconvertedintoanother64bitstring.Theresultof theconversion,inwhichseveralsequencesoflogicaladdition,multiplicationandXOR operationsareappliedusingthebitsofthekey,dependsoneverysinglebitofthe encryptionkey,sodecryptionwillbeimpossiblewithoutusingexactlythiskey.Bythe lengthoftheIDEAkeyitisguaranteedthatthereisareallyhugeamountofdifferent keys(exactly2128thatis340282366920938463463374607431768211456), makingitpracticallyimpossibleto"guessthekey"bysystematicallytesting everypossiblekey,amethodwhichisknownasthe"bruteforceattack".

EXCURSUS
Why should it remain unfeasible for a computer to test all possible IDEA-keys in the near future rather quickly ?

It remains unfeasible because as a matter of principle a computer will not have the necessary efficiency. According to today's state of physical research which in future could change the spreading of information in every imaginable computer system is limited by the speed

of light. Not even the results of current "experiments measuring velocities higher than the speed of light" do contradict this fact. If you assume the size of a high-performance computer system performing keytests is 0.3 mm for electronic or optical transfer of information, it can only perform 1 000 000 000 000 operations (1012) per second, otherwise it has to be smaller. Over a period of 317 years or 10 003 759 200 seconds that will sum up to 10 003 759 200 000 000 000 000 operations. This ability to perform no more than 1022 operations within 317 years is truly not sufficient for testing 1022 different IDEA-keys because every keytest requires more than a single operation cycle. But even if it was possible to do a keytest that fast, the large number of 1038 IDEA-keys would have been searched for no more than 0.000 000 000 000 000 029 percent. Thus a specific IDEA-key will not be found even if "lots" of those high-performance computers will work parallel to test the keys. This argument is based on empirical assumptions and therefore it can be refuted by experience. But without doubt any it is definitely wrong to suppose "efficiency of any size" for future computer systems. It is interesting to compare the ability of our proposed supercomputer to a real machine, "Deep Crack", which was invented in 1998 by EFF to show that a brute force attack on DES, the standard symmetric cipher used by banks and other commercial institutions for many years, was indeed possible. Deep Crack is a parallel computer using special hardware of 1500 Deep Crack chips and managed to test 90 billion DESkeys per second, so that any 56-bit DES-key can be found in about 5 days. This single maching today provides 9 percent of the ability we assigned to our proposed 0.3 mm supercomputer.

ThePublicKeyCryptosystemRSA Toensureareliablelinkbetweenasinglepersonandtheabilitytodecryptorsigna messagethepublickeycryptosystem(RSA)isofutmostimportanceforPGP. Thesecureperformanceofthepublickeycryptosystemguarantees: theconfidentialityofthemessage,becausetheIDEAkey,alargearbitrary randomnumberusedforencryptionshouldbeappliedbytheintendedrecipientof themessageonly,and theauthenticityofthemessage,itenablesapersontosignadocumentreliably. Soamessagecanbescrutinizedwhetherithasbeencreatedbyaparticularperson ornot. IfamessagehasbeenencryptedwithanIDEAkey(randomsessionkey),thiskeyhasto besenttotherecipienttogetherwiththeencryptedmessageinawaythatonlythis personisabletorecovertheIDEAkeytodecryptthemessage.Toensurethis,theIDEA keyitselfwillbeencryptedwiththeaddressee'spublicRSAkey.Togaintheoriginal

message,firstlytherecipienthastoapplyhissecretkey,thecounterparttohispublic key,whichmustbeinthepossessionoftherecipientonlytodecryptthesessionkey whichisneededtofinallydecrypttheoriginalmessage.Theauthenticityofthemessage thereforeisonlyguaranteedifthepairofkeys(publickey,secretkey)isassignedtoa certainperson,evenifyoudonotknowtheauthorpersonally.Butthevalidityofadigital signaturedependsonthefact,thatonlythepersonitselfwasabletocreatethedocument byapplyinghisorhersecretkeywhichalsomadehimorherresponsibleforthecontents ofthedocument.Aperson'sintellectualpropertycanonlybeprotectedbyprovingthe copyrightinadocumentifnobodyelseisabletocreateaninformationthatmatcheswith thisperson'spublickey. TheRSAcryptosystembasicallyusesthreedifferentandverylongnumbers(e,d,n),even ifoneofthosenumbersactuallyischosenverysmallduetothetechnicalimplementation ofthecipher,thesecurityofthecipherwillnotbereduced.Twoofthem,thepublickeye andthemodulusnareusedtoencryptamessage.Themessagetobeencryptedin principleisunderstoodasaverylongnumberitselfwhichwillberaisedtothepowerofe, therecipient'spublickey,andthemodulusnwillthenbesubtractedfromtheresultuntil itgetssmallerthann.Thisremainder(modn)isthecryptogramortheencrypted messagereadytobesenttotherecipient.Therecipienthimselfappliesthesame proceduretothecryptogramtodecryptit.Againtheencryptedmessageisunderstoodas averylongnumberbeingraisedtothepowerofd,thesecretkey,whichmiraculously yieldstheoriginalmessageaftertheremainderhasbeencomputedusingthemodulusn. Justonesinglenumberdstrictlyhastobekeptsecretwhereasthemethodof computationandbothpubliclyknownnumberseandnaswellasthecryptogramneed nottobemadesecretandcansafelybeanalyzedbyeverybody. ButtheRSAcryptosystemonlyworkswell,ifthethreenumbersfittogether"inan appropriateway".Matchingthisconditionisensuredbytheprocessofgeneratingapair ofkeyswhichalsogivesafinerecipeforcrackingthewholecryptosystem. Togenerateapairofkeysyouhavetofindtwoverylargeprimes,pandq,whichmakeup themodulusasaproduct(n=p*q).Youcanderivebothinterestingnumbers,eandd, whichformtheactualpairofkeys,veryquicklyfromthesetwoprimeswhicharethrown awayfinally. Anattackerwhoknowsthemodulusn,sayp*q,onlyneedstofindoutwhichprimesthe modulusiscomposedof,inotherwordsheorshejusthastofactorthemodulus,after thatcomputingthesecretkeyisamatterofseconds.Fortunatelytheproblemof factoringisajobcausinganawfullotofworkifnumbersareconcernedwhichconsistof severalhundreddecimaldigits,sothisisapracticallyinsolubleproblem. ThesecurityoftheRSAcryptosystemthereforedependsonthefact,thatitispractically impossibletofactorthelargeknownmodulusn.Sonobodycaninferthetwoprimes pandqfromhisorherknowledgeofthepubliclyknownmodulustogainthesecretkey. Itmaybeworthnoting,thatthesecurityofRSAalsodependsontheabsenceofany "shortcut",sothatthereisnowaytodecryptorsignamessagewithoutusingthesecret

key.Becauseofthefactthatthecryptogramwascreatedbytakingthemessagetothee thpower(modulon)onemightthinkthatcomputingtheethrootofthecryptogram (modulon)willproducethemessage.Ononehandnobodyhasfoundawaytoperform thiscalculationyet,giventhatreallylargenumbersareinvolvedbutontheotherhandit hasnotbeenprovedthatcalculationsofethrootsmodulonisofthesamecomplexityand requiresasmucheffortasfactoringthemodulus.Sotheremightbeashortcutnotyet knowntothecryptographiccommunitythatcanrendertheuseofRSAuselessinfuture anditwouldbewisenotonlytohaveacloseeyeontheadvancesinfactoringbutalsoon thepossibilityofshortcutslikecalculationsofrootsorevensomecompletelydifferent approach.

The Previous History of Factoring

70-digit numbers have been factored in 1998 on a workstation within 10 hours. 100-digit numbers will be factored on a single workstation within 1 year. 129-digit numbers : In August 1977 Martin Gardner asked the readers of Scientific American to factor 114 381 625 757 888 867 669 235 779 967 146 612 010 218 296 721 242 362 562 561 842 935 706 935 245 733 897 830 597 123 563 958 705 058 989 075 147 599 290 026 879 543 541 . Some 16 years later, in April 1994, the factors were presented by Paul Leyland (University of Oxford), Michael Graff (University of Iowa) and Derek Atkins (MIT). They had been supported by over 600 volunteers running a computer program written by K. Lenstra (Bell Labs, Morristown, New Jersey) on their workstations at night sharing the work of factoring over the internet. Later the amount of work was estimated to approximately 5000 Mips years. One Mips year is equivalent to 3.15 * 1013 operations. This experience gave rise to the "RSA Factoring Challenge" a contest which aimed at encouraging the research into number theory and the exploration of the difficulty of factoring in practice. A 155-digit number had been factored on August 22, 1999 by a group of researchers using the general number field sieve method. The work started on March 17, 1999 and kept a total of 292 computers busy for little more than 5 months. The process of sieving required some preparations in which CRAY supercomputers

were involved and it took nearly 4 months time and was worth approximately 8000 Mips years of effort. This complies excellently with the prediction made in 1996. 160-digit numbers: In 1996 experts expected factoring to be possible within about 5 years using a new method of factoring known as number field sieve. Factoring of RSA-155 in 1999 was important, since it made RSAkeys insecure which had a length of 512 bit, a key length which was considered as "Low commercial grade, fast but less secure" since PGP has first been introduced in 1991. 200-digit numbers: The time for factoring was estimated at 52 000 000 years in 1998.

Conclusion

Using a minimal key length of 1024 bit corresponding to a RSA-modulus of at least 309 decimal digits, it is guaranteed that RSA can be considered safe for the near future as long as there will be no fundamental advance in the factoring of large numbers. Today lots of PGP-keys are certified with key lenghts of even 2048 bit corresponding to 617 decimal digits.

AttacksontheRSACryptosystem Asfactoringofthemodulusisdoomedtofailure,ifasufficientlargekeyisused,attacks whichcurrentlyhavebecomeknownweredirectedtowardstheimplementationofthe algorithm(timingattack)ortheypresupposetheattackerbeingabletosubmitachosen messagetothevictimforsigning(chosenciphertextattack).Bothtypesofattackshave beendiscussedindetailbyW.Unruh,soIwillnotdigintothatmatteranyfurther. Toprotectyourselfagainsttheseattacksyoushouldavoidsigning(adocumentwhich couldcontainarbitraryhiddendata,forinstanceanunknownwordprocessordocument containinginformation(onformatting)whichisnottobeseenintheplaintext.Asthe chosenciphertextattackisbasedonthefact,thatanattackerisabletosmugglesome skilfulchosendataintothemessage,sothatanencryptionwiththesecretkeyturnsout tobeactuallyadecryptionofthemessageoratleastpartofit.Buteveniftheattacker wassuccessfulhewouldnotgetthesecretkeyitself.Theexistenceofthechosen ciphertextattackisonereasonwhyyoudonotsignthewholedocument,butafingerprint ofitcreatedbytheonewayhashfunktionMD5toavoidsuchattacks.Thesignaturemade onthisrepresentationofthedocumentissmallernowbutalsothesecurityofdigital

signaturesnowdoesnotdependonRSAonlybutonthehashfunctionaswell. Withoutanydoubtmathematicshasmadeconsiderableprogresswithinrecentyearsin factoringverylargenumberswhichhasbeendiscussedindetailbyJ.Buchmanninthe JuneissueofScientificAmerican1996.Usingadvancedcomputertechnologymassively, completelydifferentmethodsoffactoringhavebeendevelopedwhichessentiallydiffer fromconventionalmethods. In1985W.Lenstradevelopedamethodbasedonellipticcurves,whichmadeitpossible tofindfactorsof30decimaldigitssizewithinthreeweeksusingcurrentworkstation technology.Thismethodissuccessfulevenifthenumberwhichhastobefactoredconsists ofseveralthousanddecimaldigits.IftheRSAmodulusiscomposedofasmallandalarge factor,thesmallonecouldbefoundwithinanacceptableperiodoftime.Soitisessential thattwosufficientlylargeprimesofalmostthesamesizeareusedforRSAkey generationtopreventfastfactoringofthemodulus. Adifferentmethodknownasquadraticsieverequiresthesolutionofasystemoflinear equationsconsistingofahugenumberoflinearequationsandunknownquantities.Using thismethoda120digitRSAnumberwassucessfullyfactoredin1993,although252222 equationswithatotalof245810unknownquantitieshadtobesolved.Thisworkwhich wouldhavetakenalmost50yearsusingasingleworkstationcouldbeparallelized,sothat itcouldbedonewithinamuchshorterperiodoftime.Themethodofnumberfield sieveswhichisbasedonasimilarprinciplebutworksmuchfasterthanthequadratic sievewassuccessfullyusedin1996forthefactoringofa130digitRSAnumber. Consideringtheprogressoffactoringoverthelasttenyearsonecouldexpect150digit numberstobefactoredinthenearfutureeveniftodaynoknownalgorithmisableto performthisjobwithinareasonableamountoftime.Butitisstillpossiblethata completelynewalgorithmwillbefoundwhichwouldmaketodayssecureRSAkeys absolutelyworthless.Soitwillbeessentialtoobservenewdevelopmentsinthefieldof factoringandtoconsiderthemcarefullywhenevaluatingthelengthofRSAkeys. RSAhaslongbeensubjecttoapatent(No.4,405,829)underthelawoftheUnitedStates ofAmericawhichturnedouttobeanimpedimenttothefuturedevelopmentofPGPand itseemstobethereasonwhynewerversionsprocededtointroducenewDiffie Hellman/ElGamalkeys.ButthispatenthasexpiredinSeptember2000andRSAnowis inthepublicdomainevenintheUS. TheHashfunctionMD5 Theintegrityofamessageorthesecuritythatthemessagehasnotbeenchanged duringtransportationovernetworksdependsonthehashfunctionMD5whichis usedtogenerateadigitalfingerprintofthedocument. WhatIsaFingerprint? Afingerprintisalargenumber(MD5uses39decimaldigits)whichfitstoamessage

unambiguously.Thefingerprintiscomputedbyaonewayfunctionfromthecharacters ofthemessage,ensuringthatchangingasinglebitwithinthemessagewouldproducea completelydifferentresult.Inthiswayevenaminimalchangeofthemessagecouldbe detectedreliably.Becauseofthefactthatthehashfunctionisirreversiblethereisnoway ofreconstructingthemessagefromthefingerprint.Itispracticallyimpossibleaswellto designanewmessage(asaforgery)inaway,thatitcomputesthesamefingerprintas theoriginalmessage,becausethereare1038differenthashvalues(orfingerprints)and theonewhichisgeneratedwiththenewmessageisunpredictable. Ofcourseitispossiblethatsomeothertextwillaccidentallyproducethesamehashvalue becauseevenifthenumberofdifferenthashvaluesisverylarge,itisalsolimited.But suchacollisioncouldnotbeconstructedintentionallybecauseyouhavetotryabout1038 variationstofindone.Theonewayfunctiondoesnotgiveanyclueforanappropriate choiceoftheforgeryandthepossibilitytogetthesamehashvaluefromanytwodifferent textsisonly: 0.000000000000000000000000000000000000029percent(1/2128).

The Birthday-Attack on MD5

How many people are required to make the possibility for two of them having their birthday on the same day reach 50 percent ? The wrong answer is: 365/2 = 182 people. Actually you only need 23 people which is far less than expected, and related to forging a digital signature, the forger can benefit from this situation considerably. If she does not intend to forge a certain existing document but rather confines herself to submit a document to the potential victim for signing and she has already found a forged document which hashes to the same MD5-fingerprint, forging someone's digital signature is possible, using such a "suitable pair of documents" (benign and malicious document). The number of pairs of documents she has to check until she will probably find one working pair is no longer 2127 (170 141 183 460 469 231 731 687 303 715 884 105 728), "but merely" 264 (18 446 744 073 709 551 616) that is 1019 pairs of documents. Finding a working pair of documents still is "bloody lotta work", but can not be considered as impossible (see my argumentation concerning the brute-force-attack on IDEA-keys).

Proof
With N different documents (benign and malicious all in all) there are N(N-1)/2 pairs.

Given that there are K = 2128 different hashvalues the probability of two different documents sharing the same hashvalue is 1/K. To be on the safe side one must try at least half of N2 pairs of documents, for if the probability for a collision should be 50 percent, 264 pairs of documents will be sufficient. (N2 * 1/K) / 2 = 0,5 N = sqrt(K) = 264. Among those 18 446 744 073 709 551 616 different pairs one will probably be suitable for forging a digital signature. It might be necessary to check slightly more than 264 documents, because of the fact that there are half malicious and half benign documents a matching pair can be within one of the groups which does not help to make a forgery. But since there are twice as many "cross-community" pairs than "single-community" pairs, 265 documents will provide a fair chance for a forgery.

AttacksontheHashfunctionMD5 SomehaveneverusedPGPbecauseoftheUSpatentrestrictions,othershavethrown classicPGPintothedustbinbecauseof"minorweaknessesintheMD5hashalgorithm"as quotedbyRFC2440summarizingtheadvantagesofanewkeyformat.AndindeedMD5 istheweakestcomponentusedinPGP.ButthatdoesnotmeanthatclassicPGPis obsolete. Firstofallthebirthdayattackisathreattoeveryhashfunction.Althoughplentyofwork isneededtosuccessfullylaunchsuchanattackitwouldbecomemoreunlikelywithmore bitsinthehashvalue(asSHA1isproviding).Ontheotherhandneversigningany documentpresentedbyathirdpartywithoutmakinglittlechangeswillpreventbirthday attacks,regardlessoftheadditonal32bits. ButthereisadifferentproblemrelatedtoMD5.Anidealhashfunctionwouldspreadits hashvaluesoverallpossiblevaluessothatanyspecificvalueisaslikelytoappearasany other.Ifahashfunctionclusteredatcertainhashvalues,itwouldbealoteasiertomakea forgeryofsignatures,becausenotallhashvalueshavetobeconsideredandtheamountof worktofindamaliciousdocumentthathashestooneoftheclusterhashvalueswould shrinkaccordinglyThereisstillnoindicationthatMD5doesnotspreaditshashvalues evenly. Anotherweakerpropertyofahashfunctionwhichisofutmostimportanceisits"collision resistance",itmustbepracticallyimpossibletocreateadifferentdocumentdeliberately thathashestothesamevalue,otherwisethehashfunctioniscompromisedandcanno longerbeusedfordigitalsignatures.Pleasekeepinmindthatalwaystherewillbe collisionsforeveryhashfunctionbecausethenumberofpossibledocumentswhichcanbe aninputofahashfunctionaredigestedintoafixednumberofhashvalues,butthose collisionswhichareinevitablecannotbecreatedatwillandthereforeitisextremely unlikelybutneverthelesspossiblethatcollisionscanbefoundaccidentially.Producing

collisionsisnotaproblemaslongasitisanextremelyunlikelyeventanditis unpredictable.Butanychancetocreateacollisionusingacertainmethodwouldcertainly bethedeathofthehashfunction. InlightofthisitisimportanttoconsiderthefindingsofHansDobbertinonthecollision resistanceofMD5whichhavebeenpublishedin1996andwhichgaverisetoconcerns abouttheusefulnessofMD5fordigitalsignatures.Beforewecanthinkaboutthe conclusionsofDobbertin'sworkforPGPwehavetospendapieceofbraingreaseto understandthebasicfunctionalityofhashfunctionslikeMD5. Thehashvalueisnotcomputedfromallthemessagebitsinonestepbutthereareseveral sequencesofcompressioninwhichblocksofplaintextareusedtocreatethefinal outcome.Firstofalltomakethehashfunctiononewaytherehastobeareductionof informationduringthecompression.Ifnoinformationwasthrownaway,theinput messagewouldberecoverableusingtheoutputhashvalue,whichhastobeimpossible. Thereforethemessagebitsareexpandedtoacertainlengthsothattheycouldbesplitup intoblocksof512bits.Thosemessageblocksareusedtofeedacompressionfunction whichusesthose512bitstochangeaninitialvalue(IV)of128bitsintoadifferentoneof thesamelength.Theresultofthecompressionisanother128bitnumberwhichcanbe usedasinputforthenextcompressionusingthenextmessageblock.Thenumberwhich istransformedduringcompressionispassedontothenextcompressionuntilitdropsout oftheprocessasahashvalue.Itiscalleda"chainingvariable"becauseitrepresentsthe linkbetweensuccessivecompressions.Afterhavingperformedasmanycompressionsas messageblocksareavailable,theveryfirstinitialvaluehasbeentransformedintothe finalhashvalueandeverybitofthemessagehascontributedtothistransformation. Everycomputationofhashvaluesstartswiththesameinitalvalue,whichhastobe01 23456789abcdeffedcba9876543210accordingtothespecificationinRFC1321 andthemessagebitswhichfeedthecompressionfunctionwillchangethisinitialvalueto thefinalhashvaluethatrepresentsthemessageinadigitalsignature. Wearenowheadingforthetrickypartofthewholeprocessdirectly.Toachievethe desiredeffectofinformationreductionthecompressionfunctionitselfappliesanumberof 64complexoperations(4roundsof16operationseach)inwhichallbitsofthecurrent chainingvariablearemixedwithasuccessiveselectionof16bitsofthemessageusing NOT,AND,ORandXORbinaryoperations.Intheendall512messagebitshadtheir effectonallthebitsofthechainingvariablebutonly128bitsaretransferedtothenext compressiontobechewedfurtherusingthenextmessageblock. Thereason,whyconcernsaboutthesecurityofMD5cameup,wasthatDobbertin discoveredthatcollisionsofthecompressionfunctionscanbefoundonapentiumPC within10hours.Dobbertinreportedin1996thatiftheinitialvaluecanbesetto12ac23 753b3410426f62b97c4ba763edtwoslightlydifferentmessagesof512bitwill producethesameoutputinthecompressionfunction.Thesecondmessagewasalmost identicalexceptbit14ineverytwobytesofthemessage.Toassesstheimplicationsof Dobbertin'sdemonstrationsproperlyisnotaneasythingtodo.Findingamethodto producecollisonsonthecompressionfunctionisasevereproblemforeveryhashfunction

butalthoughRSALaboratoriesnotedintheirBulletinofNovember1996" OnRecent ResultsforMD2,MD4andMD5 " thatgiven"thesurprisingspeedwithwhichtechniquesonMD4wereextended toMD5wefeelthatitisonlyprudenttodrawacautiousconclusionandto expectthatcollisionsfortheentirehashfunctionmightsoonbefound", nocollisionshavebeendemonstratedtobefeasibleuntiltoday. ThismightbeduetothefactthattocreatecollisionsforthefullMD5wouldcertainly requirethesubstitutionofthechainingvariablewithsomesuitablevaluethatcanbe usedinawaysimilartoDobbertin'sdemonstration.Sinceanattackercannotrelyonthe factthatanymessagewillproducehisspecialvaluereadytosubstitutethechaining variable,theattackwouldaffectPGPonlyifitwerepossibletoaltertheinitialvaluein PGP'ssourcecode.ThiscanbepreventedwhenPGPisobtainedfromreliablesources. ThereisasecondfacttobeconsideredtoestimatehowmuchtheusefulnessofMD5may belimitedbyDobbertin'sfindings.Signatureswhichhavealreadybeencreatedwill remainsafefromcompromiseeveniftherewasamethodoffindingcollisionsbecauseif thecollisonresistanceofahashfunctiongetslost,crackingexistentsignatureswill requirefindinga"secondpreimage",thatisasecondmessagewhichhashestoafixed hashvalueandthereforeisprotectedbyonewaynessevenifcollisionresistanceisgone. AsRSALaboratoriesstate"itseemsthatcurrenttechniquesusedtocryptanalyseMD5do notofferanyadvantageinfindingasecondpreimage". Intheendtrustisimportant.TheassessmentthatMD5hasalmostbeenbrokenis nonsense,butputtingtoomuchfaithintothefactthatasnobodycandemonstrate collisionstoday,MD5willsurvivethoseattemptstocrackforalongtimemaybe imprudent.ThereisnoneedtoturnawayfromMD5butthereisalsononeedtostickto MD5unlessseriousdoubtsaboutthereliabilityofthealternativesarejustified.Sointhis situationitdependsuponhowmuchtrustyouputintothealternativestoreplaceclassic PGPbecauseoftheproblemsconcernedwithMD5.Beingcautiousandclaiminghigh demandsoncryptographicmethodscanbewise,butregardingclassicPGPasdeprecated andusingSHAfueledPGPoninsecureWindowsboxesinsteadiscertainlyplainfolly. WhereDoestheSessionKeyComeFrom? ThePrivatePartsofPGP ThereisanotherpieceofsoftwareinPGPthathasaneffectonthesecurityand reliabilityofthewholesystemandwhichusuallydoesnotcauseasensationbecauseof allpartsofPGPitisthemostunsexyone,butitisthesourceofallthesecrecyinPGP andthereforeitsmostprivatepart,thePseudoRandomNumberGenerator,orPRNGfor short.Aswesawamessageisencryptedwithasessionkeyof128bitlengthusingIDEA. Toenabletherecipienttounscramblethecryptogramthesessionkeyissenttogether withthecryptogrambutencryptedwiththerecipient'spublickey.Theprivacyofthe messagereliesonthefactthataneavesdropperisunabletocalculatetherecipient's

secretkeyfromhispublickeyandthatguessingthesessionkeyisequivalenttoabrute

forceattack,thatistestingaverylargeportionofthe1039possiblesessionkeys.Imagine, thatthePRNGisnotsufficientlyrandomandmayproduceonlyatinyfractionofall those128bitstrings,saysomefewhundredbillion,thenbruteforceisnotneccessaryto getthesessionkeyandreadthemessageincleartext.Worse,ifsuchawouldbePRNGis usedtocreateRSAkeysfactoringcanbemucheasierthanyouexpect. Whyisitsodifficulttopickatrulyrandomnumber?Acomputerisaverydeterministic thing,evenifsometimeswedonothavereasontobeliefthisbecausesometimesittends tobehavelikeaqueerfellow.Anyway,PseudoRandomNumberGeneratorsarecalled pseudobecausetheydonotpicknumbersrandomly,butfollowingsomeprocedurethat reliesonrandomdataasinputandthencreatesasequenceofoutputsthatlookpretty randomtoahumanalthoughthesequencewouldrepeatitselfafteralongtimeand thereforeisnottrulyrandom.TheoutputofaPRNGcanbeanalysedstatisticallyand givesprettygoodresultsinthisrespectbutthesequenceofsuccessivenumbersis completelydependentontheinitialstateofthegenerator.Soitisimportanttohidethe informationaboutthestateofthegeneratorandtosetupthegeneratorwithrealrandom datawhensecuritycriticalprocessesareinitiatedthatuserandomnumbers.Notethat theremustbeasourceofrandomnesswhichisfedintothegeneratorfromoutsidethat cannotbecreatedbythesoftwareitself. Themostimportantsourceofrandomnessistheuser'sinputwhenhefirstcreatesafile called"randseed.bin"usuallyinhishomedirectory.Alatencytimerisusedtomeasure thetimebetweentwosuccessivekeystrokesontheuser'skeyboard,whichestablishesthe firstcontentofthisfile.Themorerandomthekeystrokesthebettertheoriginalpool data,itisassimpleasthat.Everytimeasessionkeyisneededforencryptionsome24 bytesofdatafromthepoolfeedanothergenerator,theANSIX9.17,whichspitsouta randomnumberafterhavingbeen"prewashed"withahashoftheplaintexttobe encrypted.Toensurethattherandomdatapoolgetsmoreandmorerandom,thepoolis "washed"twice,beforeandafteruse.Washingessentiallycanbeconsideredasaprocess ofencryptionwithIDEAinwhichthehashoftheplaintextisusedasakey,somoreuser inputisfedintothepool.DetailsofthisprocedurecanbefoundinW.Unruhsanalysisof PGP'ssecurity. Dowereallyneedallthislaundry,youmayask.In1998foursecurityexperts,J.Kelsey, B.Schneier,D.WagnerandC.HallexaminedthestrengthoffourPRNGswhichareused inrealsystemsandpublishedtheirresultsinapaper"CryptanalyticAttackson PseudorandomNumberGenerators".OneofthoserealworldPRNGswastheX9.17 generatorandtheauthorsshowthatthemainweaknessofthisgeneratormaybecaused byastatecompromisefromwhichthegeneratorwouldneverrecoverfully.Theauthorsdo notseeanyweaknessconcerningadirectattackonthegeneratorwithoutbeingableto controltheinputofthegeneratorwhichinfactistakenfromPGP'srandompool.Aslong asthisrandomdatacannotbefrozenthereisnowayforinputbasedattacks.Butonce theinternalIDEAkeyiscompromisedandtheattackerlearnstheinternalstateofthe generatoritwillneverrecoverfromthiscompromiseeveniftherearelotsofrealrandom

numbersfedintotheX9.17subsequently.Theobviousrecommendationgivenbythe authorstominimizetheeffectofapossiblestatecompromiseis: "ForsystemsthatuseX9.17,themostobviouswaytoresistthisclassofattackis tooccasionallyusethecurrentX9.17statetogenerateawholenewX9.17state, includinganewK[theIDEAkey,R.S.]andanewstartingseed[i]."[PGP's randompooldata] PGPactuallytranslates"occasionally"to"always".Sincethegeneratoriswashedwiththe hashoftheplaintext,itsstatewilldependonthemessagetheuserintendstoencrypt. WhilecreatingtheIDEAencryptionkey(orsessionkey),morebytesarereadintothe generatorfromthepoolwhichwillbeencrypted(washed)beforetheyareusedinthe generatortoproducepseudorandomnumbers.Afractionofthesecreatethesessionkey andtherestisfedbackintothepoolafterhavingbeenwashedagain,sothepoolitself willbedifferentnexttimeasessionkeyneedstobecreated. YoumayhavenoticedthatPGPasksforalotofrandomkeystrokeswhenaRSAkeypair istobecreatedbecausepublic/secretkeygenerationrequiresselectingtwoverylarge primespandq.Sincelargeprimenumberscannotbegeneratedtheyaremadeupwith randombitsandaretestedwhethertheyarecomposedorprimesubsequentlyapplying thefermattest.PGPconsiderssuchaguessednumberprimeifitpassesthefermattest withfourdiffenentbases.Tocreatesecurelargeprimesitisimportanttohaveenough trulyrandomdatainthepool. ItisworthnotingthatinMay2000GermanoCaronnifoundoutthatacertainversionof PGP5.0iforLINUXandOpenBSDusedasourceofrandomness(thespecialfile /dev/random)whichproducedtoofewrandomnesswhilekeysaregeneratedwithoutuser interaction.Thiskeygenerationproblemwasreportedandstressedthefactthatintense randomuserinteractionisneededduringkeygenerationtopreventweakkeys.Wecan seethatnosecurityisobtainedwithouteffortandaconsciousnessoftheunderlying processes.

RESULT

Using sufficient long keys an attack on cryptographic methods used by PGP is practically pointless. This "theoretical security" has to be evaluated with respect to current results of cryptographic research.

PracticalAttacksonPGP BecauseofthefactthatattacksonthecryptographicmethodsusedbyPGPare practicallyimpossibletheattentionofpotentialattackersisshiftedtowardsthepractical useofPGP.

SecurityrelevantActions PracticaluseofPGPsometimesrequirestheuseofthesecretkeytosignadocumentorto decryptaconfidentialmessage.Therearedangerslyinginwaitwhenusingthesecretkey (securityrelevantaction)thatcouldmakethecryptographicmethodsworthless allatonce,soyouhavetobeextremelycautiousinusingyoursecretkey.Itisessential todevelopaconsciousnessofthepossiblevulnerabilitiesofthesecurityofPGP, whichisusuallyextremelyhigh. Fortunatelymostoftheeverydaytaskscanbecarriedoutwithoutanydifficulties, becauseonlypublickeysareused.Ifyouwanttocheckthesignaturesofyouremailsyou havereceivedyouonlyhavetoapplythepublickeyofthesender.Evenifyousend confidentialinformationtootherpeople,youhavetoencryptthemusingthepublickeyof therecipient. Butaddingsuchapublickeyofanunknownpersontoyourkeyring,i.etothefile whichcollectsallthepublickeysisdefinitelyasecurityrelevantaction,becauseby addingthenewpublickeyyoudefinitelyrecognizethattheavailablepublickey youoftenhavereceivedfromnonreliablesources(i.e.keyservers)isactuallyidentical withthepublickeyasitwasinitiallygeneratedbythatpersonitself.Thiscould beaproblemifyoudon'tknowthatpersonorifyoucanonlycommunicatewithhimor herusinganunreliablechannelliketheinternetwhichfrequentlyhappens. Ofcourseyoucouldaddanewpublickeytoyourkeyringas"untrusted"withoutapplying yoursecretkeybutassoonasyouwanttoacceptapublickeyasreliableyouhaveto certifyityourselfusingthesecretkeyforsigningthekey. Sohowcanyoujudgethereliabilityofanunknownpublickey?PGPofferstwo differentwaystosolvethatproblem.YoucanobtaintheFINGERPRINTofthepublickey throughadirectandreliablecontactwiththatpersoncomparingthisfirsthand informationwiththefingerprintofthepublickeyyouhavereceivedfromunreliable sources.Ifthatconfirmstheauthenticityofthepublickeyyoucancertifythisnewkey yourselfsigningthenewkeywithyoursecretkeywhileaddingittoyourkeyring. Butifthenewpublickeyhasalreadybeencertifiedbyacertificationauthority youtrustaddingthiskeytoyourkeyringdoesnotrequireyoursignatureofthe key.However,thepremisewouldbethatyouhavesignedthepublickeyofthe certificationauthorityandyouhaveconsentedtocertifynewpublickeysbythe certificationauthority,whichisasecurityrelevantactionitself. Butevenifyouaddanoncertifiedkeytoyourkeyringyouonlyhavetoconfirmthe authenticityofthenewkeyoncebysigningit.Duringyoureverydayuseofthedifferent people'spublickeyyourownsecretkeywillneverbeused.Sosecurityrelevantactions doreducetosigningowndocuments(asthe"crowningfinish"ofyourcreativework) andtodecryptingmessagesmeantonlyforyoureyes. Pleasepayattentiontothefact,thatwheneversuchasecurityrelevantaction

iscarriedout,youalwayshavetoenteryourpassphrase! Forifyouaren'trequestedtoenteryourpassphrasethenyourpassphraseisstored somewhereorhasnotbeensetanyway,whichmakesitscompromisedrasticallyeasieror thereissomethingfoulwithyourPGPworkingenvironment,especiallywithyourbinary youareusing.Assoonasthathappenstoyouonce,youshouldchangeyourpassphrase whichmakesyoursecretkeybeencryptedfreshlyandyoushouldscanthesecurityof yourworkingenvironmentthoroughly(maybewiththehelpofothers).Withmultiuser systemsthereisthedangerofsomeonegettingaccesstothesuperuser'spasswordor tamperingwiththeworkingenvironmentbymakinguseofweaknessesofcertainsystem programsingainingrootpermission.Soitisusuallyadvisabletoinformyoursystem administratorifyouobservesucha"queerbehaviour"ofyourenvironment. Ifsomebodygottoknowyourpassphraseheorshejustwouldneedtogetyoursecretkey (ring)tobeabletosigninyournameorreadyourprivatedata.Practicallyyoucouldtry topreventsomeonecopyingyoursecretkeyringbyusingfilepermissionsprovidedbythe operatingsystem.Althoughwithasuitablenetworkingenvironment,onecouldrestrict theaccesstosensibledata,itcannotbeguaranteedthattheencryptedsecretkeyring willnotfallintothehandsofotherpeople,i.easaresultofburglary.Ofcourseduring normaloperationthereisafundamentaldifferencebetweenaresponsiblyadministered multiusersystemandanutterlyunprotecteddesktopPC.Butbecauseofthefact,thatin theworstcasethetheftofyoursecretkeyringistobeexpected,thequalityofyour passphraseisessentialwhichprotectsyoursecretkeyfrombeing(mis)usedbyothers. HowtoDealwithYourPassphrase Evenifyouhavefoundasophisticatedpassphrase(bettertwoofthem,soyoucanchange itwhennecessary)youshouldavoidmakingthefollowingmistakesinordertogetyour secretkeysecureforeternity. Don'teverwriteyourpassphrasedown(inplaintext)!Don'teventhinkaboutdoing so. Don'tuseyourpassphraseforsomethingelse(i.easloginpassword).Even similaritieswouldmakedrawingconclusionsmucheasier,ifyoujustweren't cautioussometime. Don'tcommunicateyourpassphrasetootherpeople,comehellorhighwater!You woulddestroythelinkbetweenyourpairofkeysandasingleindividual,thatis you.Nobody,exceptyou,hastherighttouseyoursecretkey,soyouhavetoresist anyattemptto"squeezethepassphraseoutofyou".Youshouldconsiderattempts ofsomebodytoobtainthepassphraseofotherpeoplenotasapeccadillobutasa perfidiousattackonprivacyincomputernetworks.Suchattemptsof"social engineering"destroytrustinthereliabilityofcryptographicmethodsandhaveto beseenassocialharmfulbehaviour,especiallyastherightofanindividualtouse aprivatekeyisthreatenedbytheexploitationofrelationshipsofdependancy(i.ein

acompany).Privacyisaright,notagenerousconcession. Takecarethatyouarenotobservedwhenenteringyourpassphrase.Everyonewho isawareofthevalueofcryptographywillavoid"peepingatyourfingers".Youcan easilyrecognizepeoplewithoutanyconsciousnessoftheproblemorwithsuspicious intentionbytheirbehaviourinthosesituations.Youdonothavetodefendyour right"toenteryourpassphraseunobserved",claimitasamatterofcourse. Don'teverforgetyourpassphrase.Ifyoudon'trememberyourpassphraseyouwill beinexactlythesamesituationassomeonewhohashiseyesonyourpassphrase butincontrasttohimyoucannotcatchyourselfenteringyourpassphrase.This situationisdesperateandwithoutanyhelp.Butitisratherunlikelythatyouwill forgetyourpassphraseifyouusePGPregularly. Pleasegeneratea"keyrevocationcertificate"whichisadocumentthatdeclares yourpublickeynullandvoidandhasbeensignedbyyourself.Therevocation certificatecouldbedistributedlikeyourpublickey(viakeyserver)iftheworst casehashappenedandyouhavetoorwanttowithdrawyourpublickey.Butbe suretokeepyourrevocationcertificatesafe. Pleasemakeabackupofyoursecretkeyringandlockitawayinasafeplace. AttacksonYourPassphrase VulnerabilitiesoftheOperatingSystem Ifyoureceivedaconfidentialmessageitwillusuallybestoredonadiskinplaintextafter decryptionwithyoursecretkey.Afterdeletingthisfilecontainingsensitivedataithas surelydisappearedfromthefilesystembutitisstillpossibletorecoverthephysically storeddata,becausedeletingafileonlycancelsthelinkbetweenthedestroyedfilename andtheoriginalblocksofdataonthemedium,whicharestillexistent.Toactually destroytheconfidentialdatathefilehastobeoverwrittenwithsomeotherdatain itsfulllengthbeforeitisdeleted,preferablyadozentimes.PGPhasanoptionw (wipe)forthispurposewhichoverwritesthecontentsofanexistingplaintextfilewith randomdataatleastonce.Special"filewipingutilities"dothatjobbyoverwritingthefile severaltimes. Sometexteditorscreatetemporaryfilesontheirown,whichholdacopyofthetext duringtheprocessofediting.Afterfinishingthose"tempfiles"willusuallyonlybedeleted not"wiped",leavingsensitivedataundestroyedonthemedium. Moreoveryourpassphraseisatrisktoappearonastoragemedium,ifyour operatingsystemisextendingitsmemoryby"swapping".WhileUNIXdoesseparate thisswapspacefromtherestofthefilesystem,sothatsomeonehastogainrootaccessto analyseit,MSWINDOWSdirectlystorespartsofthememorytodisk.Thereforewith someluckeveryonewhohasaccesstoyourharddiskcouldfindyourpassphraseorparts ofconfidentialinformationintheswapfileinplaintext.Especiallyinanetworking

environmentaswapfileisaseriousdangertoyourpassphrase.Itdefinitelywouldbethe leasttoavoidswappingwhileusingWINDOWSoratleasttowipetheswapfilebefore turningoffyourcomputer,becausedeletingdoesnotdestroythecontentsofyour swapfile. UNIXrestrictstheabilitytoexamineanyblocksofdatatothepersonofthesystem administrator.Inprincipleheorshealsohasaccesstothememory(/dev/kmem)andcan searchforyourpassphraseinthememoryduringtheexecutionofyourPGPprocess.Do nothesitatetospeaktoyoursystemadministratoraboutthisproblem.Aresponsible systemadministratorwillputhimselftoalotoftroubletopreventothersfromusingthe superuser'spasswordandheorshewillbeabletoassureyouthatyourpassphrasewill notbeatriskbyrootaccess.Atthispointthesecurityofyoursecretkeydependsonthe ethosandprofessionalityofanotherpersonwhoisresponsiblefortheUNIXsystem.At leastsinceBruceSchneier'sepiphanywebegintounderstandthatsecurityisaprocess andnotaproduct.Thereforedonotbothertoaskyoursystemadministatorabout monitoring,intrusiondetectionandriskmanagementtomakesurethattheintegrityof yourworkingenvironementiscarefullyobserved. PeterGutmannhasexaminedthereliabilityofsafedestructionofdatastoredon magneticdisksandsolidstatememoryandfoundsurprisinglythatdataseemtobemore resistanttodestructiononthesemediathanexpected.Incaseyourcomputerfallsinto thehandsofanattackerproceduresincluding"MagneticForceMicroscopy"canbe appliedtoretainstoreddatawhichhadevenbeenoverwrittenseveraltimes.Thereare differentreasonsforthepersistencyofformerlystoreddataonmagneticmediaranging fromtheinabilityofwritingdatatoexactlythesametracksothatolddataremainsat theedgestoalackofoverwriteperformancewhichleavesprogressivlydiminishing imagesofolderwrittendatainpresentpatternsonthedisk.Basedonananalysisofthe wayrawdataiswrittentodisksGutmannproposesamethodoftrulyerasingdatawhich usesasequenceof35consecutivewritecirclestogetridofolddatareliably. HealsofoundoutthatdatapresentinRAMisrecoverableafterpowerisswitchedoff dependingonthetimethedataisheldinmemoryunchanged.Interestinglynotonly staticRAMcould"remember"laststoredstatesoverdaysbutalsodynamicRAMcanhold suchinformationbecausethechargeofcellsisretainedwhiletheelectricfieldstresses thethinoxidethatmakesupstoragecapacitordielectricandthuschangesitselectric propertiesremaininginthecells.Thiseffectisnotexploitableunlessthedataremains constantforseveralminutesbutafterthattheinformationremainsfordaysdepending ontemperatureonceithasreachedacriticalthreshold.UnfortunatelyoverwritingRAM doesnothavethesameeffectaswithmagneticmedia,ratherthedatausedforerasure shouldbeappliedunchangedforaslongaspossibleandshouldnotbechangedasoftenas possibletobeeffective.AsaprecautionGutmannproposesthatsecurityrelevantdata likepassphrasesandsecretkeysshouldbeheldinspeciallydesignedRAMwhichhasto flipconstantlytoprevent"burningin"ofsecretinformationatall.

SnoopingAttacks Spendinglargetechnicaleffort,differentpossibilitiescouldberealizedwhichallcanlead toarevelationofyourpassphrasebutwhichalsohavetobeconsideredas"rather unlikely"withrespecttothenormalsituationofuse.Itispossibletocaptureallyour keyboardinputusinghiddenvideosurveillanceoraspeciallypreparedkeyboard,which emmitsadifferentradiosignalwitheverykeypress,tocompromisethewhole cryptosystemallatonce.Recentlymethodshavebeendisclosedtoreconstruct informationfromtheelectromagneticradiationofcomputingequipment(vanEck Radiation).Whetherornotthisisarealisticscenarioishardtosaybutthenecessary technicaleffortisnottoobigtoruleoutsuchadangerbasically.InDecember2000itwas reportedthatFBIagentsinstalledabuggingdeviceonasuspect'sbusinesscomputerto findoutthepasswordthesuspectwasusing. Butwithoutanybigeffort"keyloggingutilities"or"keypresssnoopingtools" canbeinstalledinoperatingsystemswithoutaccesscontrol(DOS/WINDOWS) whichwilldetecteverykeypressed,storingthemsomewhereorsendingthem overthenetwork.Thosekeyloggersreplacesomepartsoftheoperatingsystem,which controlthekeyboardinputbytamperedcodethusleadingtoanalterationofthe operatingsystem.WithcomputersrunnigDOSorWINDOWSeverybodywillbeableto installkeyloggerswithoutanydifficulties,ifheorshehasaccesstoyourharddisk.But suchanalterationcouldbedonebyabootvirusaswellorbasedonanetworkattackwith BackOrificegivinganadversarycontroloveryourmachineusingthenetworkconnection. Togetanefficientprotectionagainstthesealterationsoftheoperatingsystemitis necessarytochecktheintegrityofthecorrespondingroutinesoftheoperatingsystem regularlybeforeyouusePGP.ThiscouldbedonebygeneratingMD5fingerprintsof relevantpartsoftheoperatingsystemcomparingthemwiththeactualsoftware fingerprints(maybeautomatically)toensureachangeoftheoperatingsystemnotto remainundetected.Tripwirecanbeofhelpinthosesituations. WithUNIX"keylogging"requiresaccesstothecorrespondingdevicefiles(terminals) whichnormallyisnotpermittedtootherpeople.Analterationoftheinputroutinesofthe operatingsystemispossibleonlywithrootaccess.ButtheXWindowSytem(X11R6) whichisthegraphicaluserinterfaceforUNIXfeaturesaconceptualdesignerror,which couldbeexploitedfor"keypresssnooping"withoutrootaccess.Youwillfind comprehensiveinformationaboutthisinRuneBraathen'sCrashCourseinXWindows Security.YoushouldalwaysavoidenteringyourpassphraseduringaXWindowsession andyoushouldswitchtothecharacterbasedconsoleifpossible.Butifyoucannotdoso, youcanrestrictaccesstoyourXservertoyourlocalhostusingtheUNIXcommand "xhost",soyoucanonlybethreatenedbyuserswhohavealreadyloggedintoyourlocal computer. Convenienceand"BrandnewFeatures" Ontheonehandworkinginanetworkenvironmentisquiteprofitablebutontheother

handitalsobearssomesevererisksconcerningtheuseofPGP.InTCP/IPnetworks "packetsniffers"arearealthreat.Dumpinganypacketofdatatransmittedoverthe networkcanbemadeineffectivewiththeuseofcryptographicmethods.Byusingthe SecureShell(SSH)asareplacementforrloginonecanperformauthenticationwitha remotehostusingRSAandsubsequentlyalldatawillbetransferredoverthenetwork conventionallyencrypted(i.e.with3DESorIDEA)makingpacketsnifferscompletely useless.Thisencryptedconnectiontoaremotehostonlyrequiresverysmalladditional effort;foreveryhostparticipatingandforeveryuserapairofRSAkeyshastobe generatedandexchangedbetweenthesystemsreliably.Soanarbitraryconnectiontoany remotehost(aswithtelnetorrlogin)wouldnotbepossiblewithoutexchangingtrusted RSAkeys.Thisemphasizesthefact,thatagainofsecuritycanonlybereachedatthe expenseofpracticalconvenience.Butusingthesecureshellallowsreallylongandsecure passwordstoprotectthesecretkey. HowSecureisYourSourceforPGP? AsthesourcecodeofPGPispubliclyknown,itispossiblethatafakedversionofPGP willbedistributedasthelegitimateoriginal,whichmightstorethepassphraseorsendit overtheinternetviaemail.Conveniencenormallywouldurgeyoutousetheprecompiled versionofPGPwhichisincludedinyoursoftwaredistributionbeingconfigured"rough andready".ButyoushouldbothertoobtainaversionofPGPwhichhasbeencompiled usingscrutinizedsourcecode.StaleSchumacher(KeyID:CCEF447D)hassignedthe legitimatesourcecodeofPGP2.6.3i,soyoucanchecktheintegrityofthesoftware,ifyou havegothispublickey(orfingerprint)fromareliablesource.Pleaseaskyoursystem administratororyourcertificationauthorityforascrutinizedversionofPGPorbuildone yourself.InanycaseyoushouldgenerateMD5fingerprintsofyourreliablePGPbinary andstoretheminasafeplace,soyoucanverifytheintegrityofthebinaryyouare currentlyusingwiththisfingerprintfromtimetotime. SomePGPshellshavebeendevelopedforWINDOWSwhichcomfortablysaveusersthe troubleofusingPGPwithitscommandlineoptions.Insteadtheprocessesofdecryption, signingandkeymanagementhavebeenhiddenbehindsome"fancybuttonsand checkboxes".Clearlythereisadangerthatenteringyourpassphrasewithinashellwill causeundesirablesideeffects,especiallyifthePGPshellisdistributedaspurebinary withoutapublicationofthesourcecode. FollowingthesupportofJAVA,JAVAScriptandACTIVEXbythenewgenerationofweb browsersaseverelackofsecurityhasbecomeknown,becauseunauthorizedaccessto privatelocaldataoverthenetworkhasbeenpermittedduetotheimplementationof thesenewfeatures.Theconcertedactionofthesoftwareindustrytodeliver"brandnew features"inaprematureandimperfectconditionwillcertainlydamagethesecurityofthe browsersintheirfurtherdevelopmentparticularly,ifyoutakeintoaccounttherivalry betweenMicrosoftandNetscape. Thedemandforcomfortanduserfriendlinesslotsofuserscallfor,causessuspicionofan increaseofsecurityrelevantattacksusingappletsand"hostilewebpages"in

future.EventodaysomewebsitesintendtocausedestructiveeffectsbasedonJAVA applets.Soinfuturethosepagescouldalsobededicatedtothepurposeofhidden informationgathering.Youcanfacethesedangersbest,ifyoudonotuseyoursystemfor PGPandasaplatformfortestingwebbrowserssimultaneously. Usuallyafirewallisusefultoprotectagainstintruders,ifconfiguredcorrectly,whichhas becomemuchofanarttoday.Someproductsthatofferpersonalfirewallshavebeenfound toleakinformationoutintotheinternet,aproblemcalled"internalextrusion".Tocheck theabiltyofpersonalfirewallsagainstsuchleakagesSteveGibsondevelopedafree utilitycalledLeakTestwhichtriestopassoutthroughthefirewall.Unfortunatelymostof thecurrentproductstodayfailtheleaktest. ButeveniffirewallsworkreliablytheydonotblockfakedDNSrequestswhichcanbe usedtosendconfidentialinformationtothenameserverofahostiledomain,aswas reportedbyRichardCoxinaprominentsecuritymailinglist. WhatIsaGoodPassphrase? InthefollowingsectionIwilldiscusssomecriteria,youmightconsiderwhilechoosing yourpassphraseifyoudonotwanttoputthesecurityofyoursecretkeyatrisk. HowLongShouldaPassphraseBe? Thepassphraseprotectsyoursecretkeyfrombeing(mis)usedbyotherindividuals.Ifyou likehavingasmuchsecurityasIDEAoffers,a128bitstringof0'sand1'sasmentioned earlierwouldbeanappropriatesolution.Ifyoureplaceany4bitsbyahexadecimaldigit, thissolutionwillforceyoutorememberi.e.thepassphrase"A9524AAF55B3D42E86 B12F737B5FD6C4",whichprobablyisexpectingtomuchofthedigitalJoeBlow. Becauseofthefactthatyoushouldneverforgetyourpassphrase,otherwiseyour secretkeyisuselessandtheprotecteddataislost,solutionshavetobefoundthatwill worksafely.Atthispointtwodifferentstrategiescanbeofferedtoguaranteethe memorabilityotthepassphrase,bothleadingtoalossofsecurity. Youcanreducethenumberofcharactersuntilyoucanrememberthepassphrase orinsteadofusingrandomcharactersyoucantrytointroduce"meaning"intoyour passphrase. Bothstrategiesdoraisethequestionwhatlengthwillberequiredtomakesurethat apassphraseisstillsecure.Myargumentconcerningtheefficiencyofafuture computersystemhasshown,thatitwillbesufficienttoensure,thattheworkfor "systematicguessing"thepassphrasewillreachabout1022operations.Ifyouchooseyour passphraseinawaythatinprinciplethereare1022possiblepassphrases,youcertainly areonthesafeside.Tocausethisamountofwork72bitsor9Bytesoftrulyrandom datawillbesufficient,becausethiswillleave272or4,7*1021variations.

Strategy1:RandomCharacterStrings Ashorter,butstillsecurepassphrasewouldbe"4C721AFD945BBA39E6".Ifyou think,youcanremembersuchathingthissolutionisstronglyrecommended. Thenumberofcharacterscouldbereducedfurtherbyusingmorethanthose16 hexadecimalcharacters(09AF).Usingnotonlyallloweranduppercaselettersbutalso everyspecialcharacteryoucanenterthroughthekeyboardresultinginsome70different symbols,12ofthoserandomlychosencharacterswillbesufficienttocausetherequired work(7012=1,4*1022). Thenmaybeyourpassphrasewouldbee8ZWr!ySFt?m. Byusingthe<SHIFT>,<CTRL>and<ALT>keysandthecombination<CTRL><ALT>as wellyoucaneasilyincreasethenumberofdifferentcharactersto160,whichresultsinan unbeatablesecure10characterpassphraselike G<ALT>)a<CTRL>#Hs<CTRL><ALT>e.3<ALT>wY. Sothegainyouhaveachievedusingthemetakeysisrathermodestandyousimply cannotconstructasecurepassphrasewithlessthan10characters! Strategy2:"Meaningful"CharacterStrings Ifyoutrytofillyourpassphrasewithmeaning,youwillruleoutalotof"meaningless" combinationsfromtheamountofpassphrasestotestandthereforeyoueitheraccepta considerableextensionofyourpassphraseoradrasticaldeterioration. Adictionarycontainsmaybe60000differentitems,soanarbitrarychoiceoffivedifferent itemswouldagainproduceplentyofcombinations(600005=7,7*1023).Butyoursecure passphrasesalmagundi_latrine_warning_gowk_marathonnowhasalenghtof36 characters,apriceyouhavetopayforthefact,thatyouonlyneedtoremembertheorder ofthefivedifferentwords,whichallhavemeaningnow.

Onesinglewordchosenfromadictionaryisclearlyuselessasapassphrase.R.T. WilliamsdescribestheattemptoftestingPGPpassphrasesusinglowtechcomputer technology(PC486andPGP2.6.2).Performingatleasttwokeytestspersecondone easilycovers172800wordsaday,soeverydictionarywillbesearchedexhaustivelywithin ashortperiodoftime. Ifyoustillwanttouseasinglewordasapassphrase,itisadvisabletochoosearandom lookingword,whichhasnomeaningforanyoneexceptyou.Twcae,pwcab.wouldbeno poorcandidateformypassphrase,ifnobodycouldgettheideathatitreflectsthe quotationofI.Kant"Thoughtswithoutcontentareempty,perceptionswithoutconcepts areblind".ButthosewhoknowthatIambusywithphilosophyprofessionallymightget thisidea,sothispassphraseiscompletelyuselessforme.Butifyoucaninventsuchan "abbreviation",nobodywhoknowsyouwouldpossiblyassume,thiswouldbea good passphrasegivenanappropriatelengthandspendingplentyof<CTRL><ALT>.

UselessPassphrases Certainlyuselesspassphrasesarethose,whosesystematictestingwouldrequirefar lessthan1022keytests.ItisknownthatnotonlytheNSA(NationalSecurityAgency)is abletocrackkeysof40bit(5byte)lengthwithoutanyproblems,correspondingtoa randomcharacterstringof7characters(outof70),becausethisonlyresultsin1012 differentpossibilities.In1997BruceSchneierdevelopedascreensaverthatcracked40 bitS/MIMEkeysbybruteforcetoshowtheinsecurityofshortkeys. The PROTECTION of your PASSPHRASE is the crucial factor which determines the security of PGP.

RESULT

The trouble you are taking to choose a good passphrase and to make your working environment secure but also your consciousness of the various possibilities of practical attacks on the use of PGP builds the basis of your security and the basis of the trust of others in the value of cryptographic applications like PGP as well.

LongLivetheSigningKey! ClassicPGPkeyscanbeusedtosigndocumentsandtoencryptconfidentialmessages. Eventhoughithasbecomecommonpracticetouseonesinglekeyforbothsigningand encryptionthereisapileofgoodreasonsnottouseonekeyforbothpurposes.Foran attackerorwithabitofbadluckyourgovernmentitmakesaremarkabledifferenence whethersomeoneintendstoforgeyoursignatureortriestoaccesstheplaintextofyour encryptedcommunication. Akeyusedtocreatesignaturesusuallyhasaverylonglifetime,becausetrustedkey distributionisanawfulexpensiveprocedureandincaseofacompromiseofyoursecret keythesecurerevocationofyoursigningkeytakesequalpain.Moreoveryouwould probablyuseyoursigningkeymorefrequentlysothatspendinganextraefforttoprotect yoursecretkeywouldbeonlyprudent.Ontheotherhandkeyswhichprotectconfidential communicationshouldhaveashortlifetimetominimizethedamagecausedbyakey compromise.Thechangeofevenrevocationofashortlifeencryptionkeywouldbeapretty normalthingwhereasyouwouldprobablygothroughmuchtroubletoavoidthe revocationofyourlonglifesigningkey.Governmentshaveoftentoyedwiththeideaof demandingthedisclosureofprivateencryptionkeysusedtoprotectconfidential communicationbuthaveconfinedthemselvestoincludeprivatesigningkeysinthis demanduptonow.Usingtwodifferentkeysforsigningandencryptionisterribly advisableinthelightofthoseintentionsofgovernmentstoestablishtheseizureof

privatekeysasanaturalmeansoflawenforcementwhicharecurrentlydevelopingin differentcountriesallaroundtheglobeandespeciallyintheEuropeanUnion. Youcaneasilyspecifythepurposeofyourlonglifekeybyaddingsomethinglike"high securitysigningkey,notforencryption"toyourPGPuserIDandusethiskeytosignany shortlifetime"encryptionkey[expires:date]"whichcanbepublishedonawebsiteandcan bereplacedevenmonthlywithoutrevocationsothateveryonewhohasgotyoursigning keyreliablycanobtainyourcurrentencryptionkeyandcheckitsvaliditybeforestarting aconfidentialconversation.Thereisnoneedforawidedistributionofyourencryption keysusingkeyserversbecauseonlyyoursigningkeyhastobecertifiedproperlytoensure theauthenticityofallyourotherkeyswhicharetobereplacedfromtimetotime.This willimplythatyouuseadifferentkeyringfortheshortlifetimekeysinordertoseparate themfromthelongtermones.Tocompletethispicturethereisalsoaneedforasafedata havenwhichisimmuneagainstdemandsforcryptographickeys.

WorkinginaReliableSecurityEnvironment Ifyouarewillingtospendadditionalefforttokeepyoursecretkeyprotectedforalong time,youhavetothinkaboutavoidingallthoserisksanddifficultiesImentionedearlier. Atthispoint,Ithink,theReliableSecurityEnvironment(RSE)mightcomeinhandy.I startedtodevelopthissoftwareasaresponsetoallthoseproblemswhicharelurking aroundinanetworkedenvironmentaimingatasolutionwhichcreatesareliablestateof operationonaPCconnectedtoalocalethernetwhichhelpstoavoidthoserisksthatcan beavoided.Tobringthemachineintoareliablestateitisnecessarytorebootandclear thememoryandthentoestablishabasicoperatingsystem(LINUX)reducedtoitsbare minimumrunningentirelyinthemainmemorywithfirewallfunctionalitytorestrict networkconnectiontotheinevitableonestoaccessamailserver.Thisenvironment,I hope,willprovideenoughusefulfunctionalitytocreate,store,signandencryptdataand touseclassicPGPinawaythatallowsforareliableoperationinacompletelyunreliable network,evenforusersthatarenottoofamiliarwithLINUX.

TheNewertheBetter?VersionsofPGP WhenPGP5.0wasintroducedin1997itpromisedtogetridofalltheweakpointsof PGP2.6.xandtoclearthewayforamassiveuseofstrongcryptography,particularlyon moderndesktopcomputerswithagraphicaluserinterface.AlthoughIthink,thatusing PGPonthecommandlinedoesnotexpecttoomuchoftheresponsible,averageuser,I wouldsurelywelcomeimprovementsofthehandlingofPGPanditsintegrationin

standardapplications,aslongastheuserisalwaysunderstandingwhatheisdoingand whatconsequenceswillbecaused.Howeverimportantsuchquestionsofuserfriendliness willbeforthefurtherspreadingofPGP,Iwouldliketoconcentrateonthevaluationof thesecurityofthenewfeaturesofPGP5.x,becausesomeofthose"improvements"which havebeencarriedoutinaviewoftheadaptationofPGPtotherequirementsofmodern informationtechnologyturnoutasextremelyquestionable,ifnotincompatiblewiththe originalobjectiveoftheprotectionofprivacyincomputernetworks. FortunatelyPGP5.xisbackwardcompatible,soRSAkeyswhichhavebeen generatedwithPGP2.6.xarestillvalidandallsigneddocumentscanbecheckedandall encryptedmessagescanbedecryptedwithoutlimitation.AllthreemethodsRSA,IDEA andMD5canstillbeusedinPGP5.x.AdditionallyPGP5.xputsanewtypeofkeyat theuser'sdisposal(actuallytwokeys,oneforsigning(DSS)andoneforencryption (DH/ElGamal)),whichissupposedtomakethelatestadvancesincryptographyavailable totheuser.InthenewversionPGP5.xtheSecureHashAlgorithm(SHA1)with160bits replacestheold128bithashfunctionMD5.Digitalsignatureswillbegeneratedusingthe DigitalSignatureAlgorithm(DSA)withamaximum"keylength"of1024bitinsteadof theRSAcryptosystem.Andasymmetricencryption,whichwaspreviouslydonebyRSA, willbeperformedbyavariationoftheElGamalpublickeyalgorithm(Diffie/Hellman variation)whichuseskeysofmaximal4096bitsforencryption.Forsymmetricencryption inadditiontoIDEAPGP5.xoffersavarietyofalgorithmsincludingCAST(128bit)and tripleDES(168bit). ThisraisesthequestionhowhighthesecurityofthenewmethodsespeciallyDSA andElGamal/DiffieHellmanhastobevaluedcomparedtoMD5andRSA.Which problemistobesolvedbyapotentialdatafiendanalogoustotheproblemoffactoring withRSAtogainthesecretkey? BoththeDigitalSignatureAlgorithmandtheElGamalalgorithmusethefollowing relationbetweenthesecretkeyXandthepublickeyY: Y=GXmodP UsingthebaseG(generator)andthelargeprimePtocalculatetheremainderwill guarantee,thatitisimpossibletodrawconclusionsfromthepublickeyYtogain thesecretkeyX.Soapotentialdatafiendhastocalculateatable(oflogs)whichshows theappropriatepublickeyY(modP)foralargenumberofsecretkeysX,sothatonecan lookupthesecretkeyforagivenpublickey. TheDSS(DigitalSignatureStandard)restrictsthesizeoftheprimePto1024bits,which appearsasaminorrestrictioncomparedtotheRSAalgorithmwhichcommonlyuses 10242048bits.Butitismoreimportantforthedatafiend,thatthisstandard restrictsthesecretkeyto160bitsaswell.Thereforeitisenoughtochecka relevantpartofthenumbersbetween0and2160tofindthesecretkey,whilethe sizeoftheprimedoesonlyincreasethetimeforcalculationofonesingletest butdoesnotincreasetheamountofpossiblesecretkeys.

Therangeofnumbersforsecretkeysisstillverylarge,butitwouldbea misunderstandingtoconfusethesizeofthesecretkey(whichisalways160bit)withthe sizeoftheDSSkey(thatisthelengthoftheusedprime).Additionallytherangeof possiblesecretkeysmightberestrictedmore,ifananalysisoftherandomnumber generator,whichproducesthesecretkeys,willgivefurtherhints.Foranoverviewof necessarykeylengthsbasedontheresearchofLenstraandVerheultheircomparisonof symmetricandasymmetriccipherscanbeveryinformative. TheNewKeyFormat WiththeintroductionofthenewDSS/DHkeystheformatinwhichthosekeyswere storedhasalsobeenchanged.Thischangebecomesvisibleinthenewkeyfilenamesof thekeyringswhicharenolongernamedpubring.pgpandsecring.pgpbutpubring.pkr andsecring.skrlately.InthecommercialversionPGP5.5thisnewfileformat containsapieceofdata,theARR(AdditionalRecipientRecord),whichbrings alongdrasticchanges.TheARRisdesignatedforstoringasecondkey(theADK) intheuser'skeycertificate,themessagerecoverykeyofthecompanyor AdditonalDecryptionKey.Inthiswayacompanywillhaveaccesstothecontentof themessage,becausewhileusingtheuser'spublickeycertificatethemessagewillbe encryptedasecondtimewiththemessagerecoverykey.Duringtheprocessofkey generationthismessagerecoverykeywillbelinkedfirmlytotheuser'spublickey,so alwaysbothkeys,theuser'spublickeyandthemessagerecoverykeywillbeusedif someoneissendingaconfidentialmessage.Forthisreasonanytimeapublickeyis retrievedfromakeyserver,thecorrespondingmessagerecoverykeywillbesentin additiontotheaddressee'spublickey.AsfarasIknowthereisstillnoreliable mechanismwhichwillpreventauser'spublickeybeinglinkedwithanotherfaked messagerecoverykeywithouttheuser'sconsentorknowledge. Itwouldbewrongtomisunderstandthismechanismasa"comfortablereplacement"for encryptiontogroups,whichalreadyexists.Whereasusingthefacilitytosenda confidentialmessagetodifferentindividualssimultaneouslyisbasedonavoluntary decisionofthesender,theinscriptionofasecondkeyintotheuser'skeycertificatewill surelybeequivalenttoabolishinghisprivacyincomputernetworks.Asmuchas thismechanismwouldbeinaccordancewiththeorganisationalneedsoftradeand industry,thiscompulsorydepositionofacopyofeveryconfidentialmessageatacentral supervisoryauthoritydoesclearlycontradictanefficientprotectionoftheuser'sprivacy andpersonalityandmostimportant,itcontradictstheoriginalintentionoftheproject PrettyGoodPrivacy. Theobviousdangerswhichraisefromtheabolitionoftheuser'sselfresponsibilitybythis forcedmechanismofsupervisionwillcomeineffectifthenewkeyformatisintroduced underthecloakof"cryptographicinnovation"andwillthenbesanctionedasalegal formatwithinthescopeoflegalendevourstowardsregulationofcryptography.The legitimateinterestinmessagerecoverycouldbesatisfiedby"encryptiontogroups"onthe

basisofselfresponsibilityoftheuseraswell,withoutforcingeverypossiblesenderofa confidentialmessagetodepositareadablecopyofthemessageatacentralauthorityby usingthesupervisionkey.Iftheresponsibilityforthesensitiveuseof cryptographicmethodsshallbeexercisedbyselfresponsibleindividualsin future,itisessentialnotonlytousetheoldkeyformatwithoutADKs(PGP 2.6.x)butalsotowarnagainstthethreateningdangersofthosenewfeaturesto preventtheircreepingadoptionwithoutopendiscussion.

SecurityRelatedProblemsoftheNewSignatureFormat GiventhatthenewcryptographicalgorithmsincludingAESwhichwillspeedilyfindits wayintotheverynextversionsofPGPandGnuPGwillbesubjecttofurtherresearchand examination,thesecurityofthesealgorithmswillnotbeamajorconcern.Butwhatgives risetoserioussuspicionisthenewopensignatureformatthatbearsanumberofpossible andactualsecurityriskswhichhavenotbeenexaminedinfullyet. InmystudyKEYEXPERIMENTSHowPGPDealsWithManipulatedKeysI presentedtheresultsofexperimentalresearchontheADKfeatureofPGPandwarnedin anotetothepublicthattheADKproblemcreatesalonglivingriskwhichwouldnotat allbeeliminatedwiththebugfixesthatfollowedmypublication.Theexperimentsshow thatNetworkAssociatedInc.notonlyhadimplantedtheADKinthenewsignatures withoutanycheckingwhetheritisinsideoroutsidethehashedpartoftheselfsignature, sothatmanipulatedpublickeysencryptedmessagestoafakedADKandmadeeverynew DiffieHellmankeyatargetformanipulation.Itturnedoutthatakeymanipulation wouldnotevenbedetectedandthatafterconvertingoldRSAkeystothenewformateven thosewereaffectedandcouldbestuffedwithADKslongaftertheownerhadselfsigned them. Asexpectedtherewerelotsofattemptstoplaydowntheimportanceoftheproblem,some descriptionsoftheconditionsunderwhichtheADKproblemarisesarestillincorrect,but thesecurityrelevantriskoftheADKessentiallywas,thatnouserwasabletoavoidthe problembyusing"fixed"versionsofPGP.Unfortunatelytheproblemwouldnotgoaway untileverypossibleuserofPGPeitherusedaversionimmunetoADKsorwasvery carefulwitheverypublickeyandwouldexaminepublickeysforsubsequent manipulationsforwhichofficialPGPwassimplynohelp.AsRossAndersonwrote: Theproblemwon'tgoawayuntilallvulnerableversionsofPGPareretired, sinceit'sthesenderwhoisresponsibleforencryptingtotheADKs,notthe recipient. DuringtheprocessofbugfixingPhilipZimmermannreportedthattherewasasimilar problemrelatedtothedesignatedrevokerfeaturewhichwouldallowtoaddunauthorized

revocationkeypacketstoakeyandwhichhasbeenfixed.Oneneedsnotbeaprophetto suspectthattherearemoreundiscoveredsecurityrelevantproblemslurkinginthenew signatureformat.Notonlythenumberof21differentsubpacketswhichareallowedin newersignaturesshowthatweshouldnotbesurprisedwhenotherpacketsshowsecurity relevantcracksbutthereareveryfewspecificationswhichrequirethatthosesubpackets havetobeinthehashedpartofthesignatureatall.Circumstancesmightbeconceivable inwhichsubpacketsmayhaveconsequenceswhentheyreappearintheunhashedpartof thesignature.Thisraisesthequestionifanunhashedpartinsidethesignatureis tolerableatallbecauseitviolatestheusualpictureofasignatureandbearsapotentially riskyreservoirofdatawhichcanbeusedtoblowupasignaturewithouttheowners consent.Itseemstomethathavingunhashedpacketsinsignaturesisbloodynonsense. Andontheotherhandthevastmajorityofuserssimplydoesnotevenknowwhichofthe 21subpacketsareincludedintheirselfsignaturetheyareresponsiblefor. Therearenosecurityrelevantrisksinthenewsignatureformat?Thefinalwordonthat shouldbespokennotbeforesomeonehasexaminedthisexperimentally.Becausein theorythereisnodifferencebetweentheoryandpractice,butinpracticethereis.

KeepAnEyeontheThreat InthestruggleofimprovingPGPwithnewfeaturesNetworkAssociatesInc.havegoton thewrongtrack.IntheirresponsetotheADKProblemtheyhavemadeitclearthatthere willnotbeanADKfreeversionbecauseitwon'tsell.ManyFrenchusersofOpenPGP haveopenlyregrettedthewayPGPhasadoptedtothedemandsofbusinessandhave requiredarebirthas"athinnedversionofPGP,withoutsuperfluousgadgetlikethe SDAorspecialkeys(ADK,sharekeys,reconstructedkeys,specialRSAkeys,etc),by respectingsecurityminimalrequirements".AlthoughseeingPGPdriftingawayfromits originalobjectivesisasadthing,therealthreattoourdigitallifecomesfromavery differentdirectionanditaproachesdirectlywithoutanydisguise. TheBritishGovernmenthaspushedtheRegulationsofInvestigativePowersAct(RIPA) throughlegislationwhichprovidesfororderstodiscloseprivateencryptionkeysand threatenseveryoneservedwiththoseorderswithtwoorevenfiveyearsofjailwhofailsto complywiththedemands.Whilesomearestillfiguringouthowfarthepowersprovided bythisactwillreachtheconditionsunderwhichordersmaybeservedorsurveilance devicescanbeinstalledseemprettymuchstretchableothersbegintoprotestwhileother EUgovernmentsseemtoshowthepoliticalwilltoadoptthisfamouslegislation.The unequivocalobligationtorevealyourprivatecommunicationbylawisaneffectivemethod totempttheuninformedpublicintonotusingcryptographytoprotecttheirprivacyand tocriminalizethosewhodo.Thereforeitisimportantthatsomefarsightedpeoplehave beguntodevelopcryptoproductsthatcanhelptofacethisthreatsandwhichmay

possiblyleadawayfromPGPaswell.Itseemsthat2001promisestobecomeabusyyear.

ReferencestoOtherSourcesofInformation TheReliableSecurityEnvironment (RSE) moot: Defense against RIPA International Cryptography The Federal Information Standards Publication: DIGITAL SIGNATURE STANDARD (DSS) The passphrase FAQbyRandallT.Williams The Memorability and Security of Passwords - Some Empirical Results byJianxinYan,AlanBlackwell,RossAndersonandAlasdairGrant TheInternetPrivacyCoalition PGP AttacksbyW.Unruh Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other SystemsbyPaul C.Kocher Practical Attacks on PGPbyJoelMcNamara Commercial Data RecoverybyAdamBack Tutorial to SecurityofSECUDEsoftware

AFinalRequest IhavetriedtoturnallinformationIhavecomeacrossintoawellfoundedvaluationof thesecurityofPGP.MaybeIhavemadesomemistakesorIhavedrawnwrong conclusions.Pleasedonothesitateto send me your opinion,Iamlookingforwardtoyour comments.

ThanksaLot! IwouldliketothankStefanKelmforhishelpingsupportduringthecompositionofthis documentandespeciallyIwouldliketothankmyfriendThomasSchochforhisconstant moralsupportofthewholeproject.NumerousothersincludingThomasGebhardand ScottACrosbyhavecontributedhintsandsuggestionstoimprovethequalityofthis documentduringtherevision.Thankyouallverymuch.

Copyright 1998-2001Ralf Senderek Thisdocumentissigned digitallywithPGP.

The passphrase FAQ

A passphrase is a sentence or phrase used instead of a single password. Because of its length, a passphrase is more secure than a password. By using a phrase, it still is easy to remember. This document answers frequently asked questions about passphrases. A passphrase is basically a sentence or phrase that serves as a more secure password. A typical password is 6 to 8 characters, and often is a word that is present in a dictionary. That is very unsafe. A passphrase could be a complete sentence, preferably a nonsensical one. Such a sentence would be much harder to guess. MD5 and IDEA are based on 128 bit blocks. It should be trivial to change to a 56 bit DES key or keys of other sizes. Passwords are different than passphrases due to length. The same ideas will work for analyzing your password or passphrase.

Table of contents
How do I get random numbers? What is MD5? Should I use a pseudo-random number generator? What about hardware random number generators?

How do I get random numbers?

Random numbers are very hard to generate. Quite often non-random events affect the randomness of devices or circuits. A suggestion would be to make 1 to N markers and place them in a very good mixer. You might want to try coin flipping, but if you have a person involved, a coin flip can be biased enough to skew the results over the long term. A ball method like several lotteries use is a good random source, but don't use the numbers from the lottery. Lottery numbers are a little to obvious and it is easy to try them. A pool/billiards game uses a set of balls in a bottle that allows only one ball to be extracted at a time. This is a cheap and inexpensive source for random numbers. I leave it to the reader to figure out how to get the 16 balls translated to something useful for any particular application.

Those who are familiar with Dungeons and Dragons and the other role playing games may already have a set of dice numbered in a variety of sizes. The one caution with dice is that adding dice (e.g. 2 six sided dice) will change the output to a median number (odds of 7 are 1 in 6) and the extremes (odds of 2 and 12 are 1 in 36) are less likely to occur, losing some randomness. Be sure that you have random dice. The quality is sometimes not very good and may cause non-random results. You might want to look at RFC 1750 (Randomness Recommendations For Security) for more information on generating random numbers for secure purposes.

What is MD5? See also

PGP Attack FAQ: The one-way hash MD5 is what takes your passphrase and scrambles it into an IDEA key. In theory, MD5 should generate a different output for every possible bit combination as long as your key space is equal to or larger than 2128. Proving that MD5 will generate all 2128 outputs from a given key space equal to 2128 is practically impossible. This would be about the same as a brute force search on the IDEA key. An interesting problem is that theoretically you can produce an equivalent passphrase by searching any given key space that is 2128 or larger. In light of the attack on MD5, wait and watch. While a weakness has been found, the jury is still out on using unmodified MD5. A move to SHA or other hash function may be in the future for PGP.

Should I use a pseudo-random number generator? See also

PGP Attack FAQ: The pseudo-random number generator (PRNG) Using a pseudo-random number generator (PRNG) is in most cases a bad way to generate random numbers. The problem with PRNGs is the numbers are generated by a function. This includes the BASIC RND() function, the C rand() function or any other language that has a random function. Programmers have used this simple and relatively fast method in programs and games for years. The reason for this is because of the way PRNGs work. A simple PRNG will use code something like R = (A * R1 + B) mod(C): R1 = R: R = R / C. Primes are usually used for constants A, B, and C. Most languages have provisions for placing a seed value in R1 before calling the PRNG but it isn't needed and some PRNGs may not bother with the additive constant B. What makes a PRNG easy to break is that many only use 16 bits to store the values. That means we can brute force a 16 bit PRNG key space in 65536 * N attempts where N is the number of pseudo-random elements used. Almost anyone can probably search a standard PRNG key space in a day. A worst case search will probably last less than a week even on the average home computer. If you are lucky and have a good PRNG, then the search space may be 232 which isn't a whole lot better. Note that 40 bit keys can be brute forced by an individual with access to enough computing power in about a week or less and places like the NSA don't mind 40 bit keys.

What about hardware random number generators?

Hardware random number generators can provide much better quality random numbers than PRNGs. However it may be difficult to find a good piece of hardware that can serve as a source of random numbers. Hardware generators can be made using the noise from a variety of semiconductor PN junctions. A good example of this is simply amplified noise from a zener diode. Other noise sources are high value resistors and a number of commercial chips that use a variety techniques to make noise. A caution with hardware sources of random information is that they could be influenced by noise or other signals that are not random. Most places are saturated with 50 or 60 Hz noise from power, clock signals and other digital noise from computers, television and radio, and a variety of other types of electronic equipment. For safety, you may want to encrypt or hash the output of a hardware source. A good hash function or encryption will hide any undiscovered patterns.

Passphrase FAQ: Practical questions

Table of contents
How long should the passphrase be? What if I use all random letters? What if I use all random characters? What if I use another language? What if I use common phrases or quotes? What happens if I combine phrases and nonsense phrases? Does odd spelling, punctuation and capitalization help? What if I use random words? Can I use a small dictionary designed for passphrases?

How long should the passphrase be?

The rule of thumb is that you use one character per bit of key needed. You really get about 1.2 bits per English text character for key usage. Modifying the key size means 128 / 1.2 = 106.667 or 107 letters of text are needed. This assumes normal English structure, only lower case letters and spaces for the passphrase and for the calculation purposes, all spaces are ignored in the passphrase. Few of us are willing to type out a line and a half of text every time we use PGP though. This is where security fails and we use weak passphrases.

What if I use all random letters?

The standard alphabet has 26 letters in it. Doing the math again we get log(2128) / log(26) = 27.23 random letters are needed. Rounding up will mean using 28 letters to make it harder than the IDEA key.

Memorizing the 28 random letters would be tough to do, but it isn't impossible. This isn't too bad to type though. A variation on this idea is to use existing words but to remove the vowels or to replace them with characters like '3' for 'e' or '4' for 'a'. It's unclear how much advantage this variation would give you. This is a well-known idea and likely many of these variations are already present in the attackers' dictionaries.

What if I use all random characters?

If we use all possible printable ASCII characters we end up with 95 possible characters to work with. Punching buttons we end up needing log(2128) / log(95) = 19.48 random characters for this method. Rounding up again, 20 random characters are needed to make this method harder than the IDEA key. Memorizing 20 random characters is still a tough job, and it is kind of hard to type.

What if I use another language?

Using your native language is probably an obvious choice. Throughout this FAQ, data and statistics apply to English text. Using another language or combining languages will change the numbers some. It will not make your passphrase harder to guess. Attacking a different language or even multiple languages is still the same. The search space is roughly the size of the language or grows by adding the size of the average size of the vocabulary of the added language. Dictionary attacks in another language would run in the same manner as a dictionary attack in English. Using words from two or more different languages may give you a slight advantage as an attacker would have to combine all his available dictionaries which increases the time to guess the correct passphrase. Of course, if the attacker knows that you are fluent in e.g. Dutch and English, this increase in time would be negligible. So use dictionaries of languages no one would associate with you.

What if I use common phrases or quotes?

The short version on common phrases is don't use them ever. A book of quotes may contain 40,000 quotes. You could probably set an old PC XT in a corner and have common phrases checked in a relatively short amount of time without any special hardware. Simple phrases will be the first ones checked. If you are a Star Trek fan, "Beam me up Scottie" is a bad phrase to use. If you can find the phrase in any published work then don't use it. A simple background search will reveal what kind of music, books, TV shows, movies, games, hobbies, and everything else you might use. All the common phrases will be tried on the first pass of a key search. You can try 40,000 quotes using unmodified PGP in about 2.4 days. See

What happens if I combine phrases and nonsense phrases?

Combining phrases extends the phrase search some. Nonsense phrases will also slow down a brute force search. A smart attack would take advantage of normal phrase structure. Ordering nouns, verbs, adverbs, adjectives and all the other components of a sentence would be tried in a natural order. A good nonsense phrase begins to appear to be random as far as a brute force search goes, but it isn't really random.

Does odd spelling, punctuation and capitalization help?

A popular trick is to substitute digits for letters, or to randomly capitalize certain letters. Using this kind of "0dd sp3LLing5 and CaP!tal!ZaTiOn" will extend the search by about 1 million tries per word. Modifying the numbers for passphrases means you probably get more than 8 million (1 million per word) for a decent passphrase. Capitalization at random will cause word length dependent permutations. Adding a single digit 0-9 to a word multiplies the dictionary size by 10. This is a small gain but in some cases may be worth the trouble. Substituting 3 for E, 1 for I, 5 for S and 2 for Z adds the numbers to the possible alphabet. Adding the numbers 0-9 increases the alphabet to 36 characters. Switching letters, letter rotations, letter shifts, and other word scrambling won't help the randomness but they do slow the brute force search some. You can approach a random looking passphrase in this manner.

What if I use random words?

The Random House Dictionary (paperback, Ballantine Books, 1980) has around 74,000 words in it. Using the 128 bit key size we then need, log(2128) / log(74,000) = 7.91, random words from our dictionary. Rounding up, you will then need 8 random words to make the passphrase harder than the IDEA key. A brute force dictionary attack will then take slightly longer than a brute force attack on the IDEA key. This is a decent way to generate a passphrase except that it is kind of hard to remember sometimes. This is pretty easy to type though. This approach has been used in the Diceware method of passphrase generation.

Can I use a small dictionary designed for passphrases?

A smaller dictionary can be searched much faster. Just having one around is enough of a clue to start with that instead of the normal searches. So, you better be sure your key generation system is really random. Programs can be compromised, written poorly or simply monitored. Try Diceware for a good random passphrase generation system. It is irrelevant if the dictionary has any tricks that make the construction of the words more random. In the end, the search space is all that counts. The random number source may not be random and further reduce the search. For these reasons, you need to be sure your key generator is really random. Here is what effect different size dictionaries have. Using a 10,000 word dictionary, (from section 2.7) log(3.16E13) / log(10,000) = 3.37 or about 4 words are needed to last more than the average 6 months. Using the same dictionary to create an IDEA equivalent passphrase gives us log(2128) / log(10,000) = 9.63 or 10 words are needed. Using a 25,000 word dictionary means log(2128) / log(25,000) = 8.76 or 9 words. A 50,000 word dictionary needs log(2128) / log(50,000) = 8.20 or 9 words.

Passphrase FAQ: Strength of the passphrase

Table of contents
How do I make a strong passphrase? How strong is my passphrase? What are some passphrase examples?

How do I make a strong passphrase?

The answer depends on how secure your passphrase needs to be. Start with a normal phrase and then with a bit of random help, distort it. Make a nonsensical phrase by changing words. Remember to switch the sentence structure around in a random fashion. Add a few random words or characters to enhance the security. The goal is to create something you can remember and last as long as a brute force attack on the IDEA key. The phrase, "my unbreakable super pass phrase can't be beat", is weak by itself. So what if we change it some? "mile unbraking stupor past froze can tent bee beets" is all well and good except that in an attack, a homophone dictionary may be used. On the other hand, in one pass we have a nonsense phrase that has a different structure and words that don't quite logically connect. Add several random characters to make it impossible to guess by any means other than brute force and you are done. The phrase is fairly easy to remember because you used a normal phrase to construct it. If you forget the actual phrase you will probably be able to reconstruct it. Being human, we tend to do things the same in a predictable manner. For more security, you can generate fully random phrases or character sequences. This will take time and may be difficult to remember. Your level of security is easy to control by limiting the key length. One nearly foolproof method is Diceware.

How strong is my passphrase?

Now using what we know of absolute minimums and maximums of a passphrase, we can make up a little formula to calculate how secure any given passphrase is. For purposes here, random means really random. Pseudo-random methods like rnd() and linear congruential generators don't count here. The constants are based on the needs of PGP. You may need to change them for your use. PS = passphrase security FF = fudge factor (this is an attempt to include variables like nonsense phrases, odd spelling, punctuation, capitalization and numbers) RW = random words (Don't count as a nonsense phrase) RC = random characters RL = random letters OC = odd characters (other than lower case letters) LC = total character count (letters in whole words, spaces ignored) (don't count if a totally random system is used.) F1 = 0.5 = nonsensical phrases hooked together F2 = ? = odd spelling/misspelling, punctuation and capitalization (This is a permutation dependent on the number of characters changed and the length of the words used. To simplify use F2 = 4 * OC / LC) F3 = .09 = random numbers (exclude if F2 is used) FF = 1 + F1 + F2 + F3

 PS = RW/8 + RC/20 + RL/28 + LC/107 * FF Calculating the passphrase security (PS) should be a simple matter for most people. A PS > 1 means it will be easier to attack the IDEA key before your passphrase will crack. A PS < 1 means that it is probably easier to attack your passphrase instead of the IDEA key. If you have a PS under 1, you may still have a secure passphrase. An estimate is that PS values less than .35 can be broken in less than a year. The formula is under construction and is only a guide number. There is hope that any errors are on the conservative side and it is probably possible to fool the formula.

What are some passphrase examples?

These are examples of passphrases and the PS numbers associated with them. If you can work through these and get the same numbers, then you are well on your way to understanding how to make passphrases good or bad. .855 - Nonsense phrase. Example: betty was smoking tires in her peace of pipe organs and playing tuna fish. 1.05 - A random bunch of characters. Example: A6:o@6 Ls+\` uGX%3y[k 1.34 - Odd capitalization/punctuation and nonsense. Example: Web oF thE Trust is BrokEn cAn You Glue it Back ToGether? and give it xRays. .280 - An average phrase. Example: There is a sucker born every minute. 1.125 - Random words. Example: paper factors difference votes behind chain treaties never group .761 - Phrases with some random letters. Example: Ignorance is bliss. spgemxk Education cures ignorance.

Passphrase FAQ: PGP and passphrases

The popular encryption program PGP uses a passphrase to secure the secret keys. There are various ways to automate inputting of the passphrase. This section explains how secure (or rather: how insecure) these methods are.

Table of contents
How do I use the passphrase switch or variable? How do I use the environment variable PGPPASS? How do I use the -z switch? How do I use passphrases in batch files?

How do I use the passphrase switch or variable?

Old versions of PGP had the command-line option -zPassphrase that would tell PGP to use the passphrase "Passphrase" automatically.

Another option is to set the environment variable PGPPASS equal to the passphrase to be used. Yet another option is to set the environment variable PGPPASSFD that tells PGP from which file descriptor the passphrase should be read. By setting this variable to 0, the passphrase is read from standard input. It is recommended that you don't use these methods. The reason is that it becomes a huge security hole unless you are extremely careful. Misusing them or making common mistakes will leave you vulnerable to single word dictionary searches or hand your passphrase to an attacker. Double check using PGP in manual mode and a test case to be sure your batch process is working correctly before using it on sensitive data. The primary system for this section is an MSDOS PC. UNIX, Mac, and others will be different. The primary purpose here is to show you the possible risks. It is highly recommended that you read the PGP manual and the operating system manual for your system before using these methods. Even that isn't enough sometimes. Some manuals are pretty obscure or just don't have the information.

How do I use the environment variable PGPPASS?

Many people have developed some good and some bad methods to try to limit the security risk involved with using PGPPASS. My method for running serious batch programs is setting a dummy passphrase to allocate more environment space than you need in the autoexec.bat. If you don't allocate enough space then you may get an out of environment space error later. Then the batch program, usually QBASIC, changes the environment setting from the program through user prompts. The program process runs, and then resets PGPPASS to filler space. The security in this is that everything gets over written in memory. Your passphrase is never written to disk.

How do I use the -z switch?

The command line switch is a convenience for some users and batch processing. Under MSDOS, you are limited to a 128 character command line. A good passphrase can be over 80 characters in length and limits the usefulness of this. Additionally, if you have spaces in your passphrase, you will only get the first word or up to the first space if you don't enclose it in quotes. Many have found that their perfect passphrase was completely useless when PGP was only getting the first word.

How do I use passphrases in batch files?

The best recommendation is don't do it. If the batch file is found, then they have your passphrase. It gets kind of complex keeping this method secure. Set a dummy passphrase in your autoexec.bat. Now in a batch file, prompt for user input of the passphrase, set the real passphrase, execute the PGP commands, overwrite the passphrase, and then exit the batch file. Always make sure the real passphrase gets overwritten before you exit the batch file. Be careful about using quotes around passphrases with spaces in them and test everything.

Passphrase FAQ
V. 1.0 2 October 1993 '"PGP," warns Dorothy Denning, a Georgetown University professor who has worked closely with the National Security Agency, "could potentially become a widespread problem.' -- (E. Dexheimer) Comments to: Grady Ward, grady@netcom.com Contributors: John Kelsey, c445585@mizzou1.missouri.edu (Appendix A) RSA Data Security (Appendix C. The MD5 Algorithm) Jim Gillogly (Appendix D. The Secure Hash Algorithm)

FAQ: How do I choose a good password or phrase?

ANS: Shocking nonsense makes the most sense With the intrinsic strength of some of the modern encryption, authentication, and message digest algorithms such as RSA, MD5, SHS and IDEA the user password or phrase is becoming more and more the focus of vulnerability. For example, Deputy Ponder with the Los Angeles County Sheriff's Department admitted in early 1993 that both they and the FBI despaired of breaking the PGP 1.0 system except through a successful dictionary attack (trying many possible passwords or phrases from lists of probable choices and their variations) rather than "breaking" the underlying cryptographic algorithm mathematically. The fundamental reason why attacking or trying to guess the user's password or phrase will increasingly be the focus of cryptanalysis is that the user's choice of password may represent a much simpler cryptographic key than optimal for the encryption algorithm being used. This weakness of the user's password choice provides the potential cryptanalytic wedge. For example, suppose a user chooses the password 'david.' On the surface the entropy of this key (or the number of different equiprobable key states) appears to be five characters chosen from a set of twenty-six with replacements: 26^5 or 1.188 x 10^7. But since the user is apparently biased toward common given names, which a majority appear in lists numbering only 6,000-7,000 entries, the true entropy is undoubtedly much closer to 6.5 x 10^3, or about four orders of magnitude smaller than the raw length might suggest. (In fact this password probably possesses a much smaller entropy than even this for the very common name "david" would be one of the first names to be checked by an optimized dictionary attack program.) In other words the "entropy" of a keyspace is not a fixed physical quantity: the cryptanalyst can exploit whole cultural biases and contexts, not just byte frequencies, digraphs, or even whole-word correlations to reduce the key space he or she is trying to explore. To thwart this avenue of attack we would like to discover a method of selecting passwords or phrases that have at least as many bits of entropy (or "hard-to-guessness") as the entropy of the cryptographic key of the underlying algorithm being used. To compare, DES (Data Encryption Standard) is believed to have about 54-55 bits (~4 x 10 ^16) of entropy while the IDEA algorithm is believed to have about 128 bits (~3.5 x 10^38) of entropy. The closer the entropy of the user's password or phrase is to the intrinsic entropy of the cryptographic key of the underlying algorithm being used, the more likely an attacker would need to search a substantially

larger portion of the algorithm's key space in order to rediscover the key. Unfortunately many documents suggest choosing passwords or phrases that are distinctly inferior to the latest method. For example, one white paper widely archived on the internet suggests selecting an original password by constructing an acronym from a popular song lyric or from a line of script from, for example, the SF movie "Star Wars". Both of these ideas turn out to be weak because both the entire script to Stars Wars and entire sets of song lyrics to thousands of popular songs are available on-line to everyone and, in some cases, are already embedded into "crack" dictionary attack programs (See ftp.uwp.edu). However, the conflict between choosing an easy-to-remember key and choosing a key with a high level of entropy is not a hopeless task if we exploit mnemonic devices that have been used for a long time outside the field of cryptography. With the goal of making up a passphrase not included in any existing corpus yet very easy to remember, an effective technique is one known as "shocking nonsense." "Shocking nonsense" means to make up a short phrase or sentence that is both nonsensical and shocking in the culture of the user, that is, it contains grossly obscene, racist, impossible or other extreme juxtaposition of ideas. This technique is permissable because the passphrase, by its nature, is never revealed to anyone with sensibilities to be offended. Shocking nonsense is unlikely to be duplicated anywhere because it does not describe a matter-of-fact that could be accidentally rediscovered by anyone else and the emotional evocation makes it difficult for the creator to forget. A mild example of such shocking nonsense might be: "mollusks peck my galloping genitals ." The reader can undoubtedly make up many far more shocking or entertaining examples for himself or herself. Even relatively short phrases offer acceptable entropy because the far larger "alphabet" pool of word symbols that may be chosen than the 26 characters that form the Roman alphabet. Even choosing from a vocabulary of a few thousand words a five word phrase might have on the order of 58 to 60 bits of entropy -- more than what is needed for the DES algorithm, for example. When you are permitted to use passphrases of arbitrary length (in PGP for example) it is not necessary to further perturb your 'shocking nonsense' passphrase to include numbers or special symbols because the pool of word choices is already very high. Not needing those special symbols or numbers (that are not intrinsically meaningful) makes the shocking nonsense passphrase that much easier to remember. If you are forced to use, say, a Unix password utility that permits only passwords of restricted length, one good strategy is to process a your secret passphrase using MD5 or SHA, then UUENCODE the result and select your shorter key from the output. See Appendix C and D for actual MD5 and SHA source implmentations.

Appendix A. For software developers

For software developers designing "front-ends" or user interfaces to conventional short-password applications, very good results will come from permitting the user arbitrary length passphrases that are then "crunched" or processed using a strong digest algorithm such as the 160-bit SHS (Secure Hash Standard) or the 128-bit MD5 (Message Digest rev.5).[See following Appendices] The interface program then chooses the appropriate number of bits from the digest and supplies them to the engine enforcing a short password. This 'key crunching' technique will assure the developer that even the short password key space will have a far greater opportunity of being fully exploited by the user. John Kelsey writes: "I think it's a really good idea to use a randomly-generated salt to generate a key from a password, and

that this salt should be as large as possible. Basically, this is to keep an attacker from spending lots of computer power once to generate a dictionary of likely keys. If users use good techniques to choose passwords, this won't matter much, but if they don't, this may save them from having their encrypted files or transmissions routinely read. The simplest scheme I can see for this is simply to prepend a 128bit salt (generated as strongly as possible) to each encrypted file. Generate the key from the password by pre-filling a buffer with the 128-bit salt, then XORing in the keyed-in password, or by appending the key to the keyed-in password. Then, run SHA or MD5 or whatever to get the key. A secondary point: Adding a random salt ensures that people who use the same password/passphrase for lots of files/transmissions don't get the same key every time. Since most successful attacks against modern encryption schemes use lots of ciphertext from the same key, this might add some practical security, at relatively low cost." --John Kelsey, c445585@mizzou1.missouri.edu

Appendix B. A tool to experimentally investigate entropy

A practical Unix tool for investigating the entropy of typical user keys can be found in Wu and Manber's 'agrep' (approximate grep) similarity pattern matching tool available in C source from cs.arizona.edu [192.12.69.5]. This tool can determine the "edit distance," that is, the number of insertions, substitutions, or deletions that would be required of an arbitrary pattern in order for it to match any of a large corpus of words or phrases, say the usr/dict word list, or over the set of Star Trek trivia archives. The user can then adjust the pattern to give an arbitrary high threshold difference between it and common words and phrases in the corpus to make crack programs that systematically vary known strings less likely to succeed. It is often surprising to discover that a substring pattern like "hxirtes" is only of edit distance two from as many as forty separate words ranging from "bushfires" to "whitest." Certainly no password or phrase ought to be chosen as a working password or phrase that is within two or fewer edit distance from a known string or substring in any on-line collection.

Appendix C. An implementation in C of the Message Digest Rev.5 Algorithm

/* md5.h -- header file for implementation of MD5 RSA Data Security, Inc. MD5 Message-Digest Algorithm Created: 2/17/90 RLR Revised: 12/27/90 SRD,AJ,BSK,JT Reference C version Revised (for MD5): RLR 4/27/91 -- G modified to have y&~z instead of y&z FF, GG, HH modified to add in last register done Access pattern: round 2 works mod 5, round 3 works mod 3 distinct additive constant for each step round 4 added, working mod 7 */ /* Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing this software or this function.

-----

License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind. These notices must be retained in any copies of any part of this documentation and/or software. */ typedef unsigned int UINT4; /* Data structure for MD5 (Message-Digest) computation */ typedef struct { UINT4 i[2]; /* number of _bits_ handled mod 2^64 */ UINT4 buf[4]; /* scratch buffer */ unsigned char in[64]; /* input buffer */ unsigned char digest[16]; /* actual digest after MD5Final call */ } MD5_CTX; void void void void MD5Init(MD5_CTX *); MD5Update(MD5_CTX *,unsigned char *,unsigned int); MD5Final(MD5_CTX *); Transform(UINT4 *,UINT4 *);

#include <stdio.h> #include <stdlib.h> #include "md5.h" void findhash( FILE *fp ) { MD5_CTX char size_t int

ctx; buffer[ BUFSIZ ]; count; i,j;

);

MD5Init( &ctx ); while ( (count=fread(buffer,1,sizeof(buffer),fp)) > 0 ) MD5Update( &ctx, buffer, count ); MD5Final( &ctx ); j = 0; for ( i=0; i<sizeof(ctx.digest); i++ ) { printf( "%02x", (unsigned int) ctx.digest[i], i == (sizeof(ctx.digest)-1) ? '\n' : ' ' j++; if ( j == 4 || j == 8 || j == 12)

{printf(" ");} }

if ( j == 16 ) printf("\n");

int main( int argc, char **argv ) { int i; if ( argc <= 1 ) { fprintf( stderr, "Usage: %s filename\n", argv[0] } exit( 1 );

);

for ( i=1; i<argc; i++ ) { FILE *fp; fp = fopen( argv[i], "rb" ); if ( fp == NULL ) { perror( argv[i] ); exit( 1 ); } printf( "%s:\t\t", argv[i] ); findhash( fp ); fclose( fp ); } return 0; }

/* md5.c -- the source code for MD5 routines RSA Data Security, Inc. MD5 Message-Digest Algorithm Created: 2/17/90 RLR Revised: 1/91 SRD,AJ,BSK,JT Reference C Version */

/* Message-digest routines: To form the message digest for a message M (1) (2) (3) The Initialize a context buffer mdContext using MD5Init Call MD5Update on mdContext and M Call MD5Final on mdContext message digest is now in mdContext->digest[0...15]

*/ static unsigned char PADDING[64] = { 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }; 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

/* F, G, H and I are basic MD5 functions */ #define F(x, y, z) (((x) & (y)) | ((~x) & (z))) #define G(x, y, z) (((x) & (z)) | ((y) & (~z))) #define H(x, y, z) ((x) ^ (y) ^ (z)) #define I(x, y, z) ((y) ^ ((x) | (~z))) /* ROTATE_LEFT rotates x left n bits */ #define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n)))) /* FF, GG, HH, and II transformations for rounds /* Rotation is separate from addition to prevent #define FF(a, b, c, d, x, s, ac) \ {(a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define GG(a, b, c, d, x, s, ac) \ {(a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define HH(a, b, c, d, x, s, ac) \ {(a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define II(a, b, c, d, x, s, ac) \ {(a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } 1, 2, 3, and 4 */ recomputation */ \

/* The routine MD5Init initializes the message-digest context mdContext. All fields are set to zero. */ void MD5Init ( MD5_CTX *mdContext) { mdContext->i[0] = mdContext->i[1] = (UINT4)0; /* Load magic initialization constants. */ mdContext->buf[0] = (UINT4)0x67452301L; mdContext->buf[1] = (UINT4)0xefcdab89L; mdContext->buf[2] = (UINT4)0x98badcfeL; mdContext->buf[3] = (UINT4)0x10325476L; }

/* The routine MD5Update updates the message-digest context to account for the presence of each of the characters inBuf[0..inLen-1] in the message whose digest is being computed. */ void MD5Update (register MD5_CTX *mdContext, unsigned char *inBuf, unsigned int inLen) { register int i, ii; int mdi; UINT4 in[16]; /* compute number of bytes mod 64 */ mdi = (int)((mdContext->i[0] >> 3) & 0x3F); /* update number of bits */ if ((mdContext->i[0] + ((UINT4)inLen << 3)) < mdContext->i[0]) mdContext->i[1]++; mdContext->i[0] += ((UINT4)inLen << 3); mdContext->i[1] += ((UINT4)inLen >> 29); while (inLen--) { /* add new character to buffer, increment mdi */ mdContext->in[mdi++] = *inBuf++; /* transform if necessary */ if (mdi == 0x40) { for (i = 0, ii = 0; i < 16; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); Transform (mdContext->buf, in); mdi = 0; } } }

/* The routine MD5Final terminates the message-digest computation and ends with the desired message digest in mdContext->digest[0...15]. */ void MD5Final (MD5_CTX *mdContext) { UINT4 in[16]; int mdi; unsigned int i, ii; unsigned int padLen; /* save number of bits */ in[14] = mdContext->i[0]; in[15] = mdContext->i[1]; /* compute number of bytes mod 64 */ mdi = (int)((mdContext->i[0] >> 3) & 0x3F);

/* pad out to 56 mod 64 */ padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi); MD5Update (mdContext, PADDING, padLen); /* append length in bits and transform */ for (i = 0, ii = 0; i < 14; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); Transform (mdContext->buf, in); /* store buffer in digest */ for (i = 0, ii = 0; i < 4; i++, ii += 4) { mdContext->digest[ii] = (unsigned char)(mdContext->buf[i] & 0xFF); mdContext->digest[ii+1] = (unsigned char)((mdContext->buf[i] >> 8) & 0xFF); mdContext->digest[ii+2] = (unsigned char)((mdContext->buf[i] >> 16) & 0xFF); mdContext->digest[ii+3] = (unsigned char)((mdContext->buf[i] >> 24) & 0xFF); } } /* Basic MD5 step. Transforms buf based on in. Note that if the Mysterious Constants are arranged backwards in little-endian order and decrypted with the DES they produce OCCULT MESSAGES! */ void Transform(register UINT4 *buf,register UINT4 *in) { register UINT4 a = buf[0], b = buf[1], c = buf[2], d = buf[3]; /* Round 1 */ #define S11 7 #define S12 12 #define S13 17 #define S14 22 FF ( a, b, c, FF ( d, a, b, FF ( c, d, a, FF ( b, c, d, FF ( a, b, c, FF ( d, a, b, FF ( c, d, a, FF ( b, c, d, FF ( a, b, c, FF ( d, a, b, FF ( c, d, a, FF ( b, c, d, FF ( a, b, c, FF ( d, a, b, FF ( c, d, a, FF ( b, c, d, /* Round 2 */ #define S21 5 #define S22 9

d, c, b, a, d, c, b, a, d, c, b, a, d, c, b, a,

in[ 0], in[ 1], in[ 2], in[ 3], in[ 4], in[ 5], in[ 6], in[ 7], in[ 8], in[ 9], in[10], in[11], in[12], in[13], in[14], in[15],

S11, S12, S13, S14, S11, S12, S13, S14, S11, S12, S13, S14, S11, S12, S13, S14,

0xD76AA478L); 0xE8C7B756L); 0x242070DBL); 0xC1BDCEEEL); 0xF57C0FAFL); 0x4787C62AL); 0xA8304613L); 0xFD469501L); 0x698098D8L); 0x8B44F7AFL); 0xFFFF5BB1L); 0x895CD7BEL); 0x6B901122L); 0xFD987193L); 0xA679438EL); 0x49B40821L);

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

1 */ 2 */ 3 */ 4 */ 5 */ 6 */ 7 */ 8 */ 9 */ 10 */ 11 */ 12 */ 13 */ 14 */ 15 */ 16 */

#define S23 14 #define S24 20 GG ( a, b, c, GG ( d, a, b, GG ( c, d, a, GG ( b, c, d, GG ( a, b, c, GG ( d, a, b, GG ( c, d, a, GG ( b, c, d, GG ( a, b, c, GG ( d, a, b, GG ( c, d, a, GG ( b, c, d, GG ( a, b, c, GG ( d, a, b, GG ( c, d, a, GG ( b, c, d, /* Round 3 */ #define S31 4 #define S32 11 #define S33 16 #define S34 23 HH ( a, b, c, HH ( d, a, b, HH ( c, d, a, HH ( b, c, d, HH ( a, b, c, HH ( d, a, b, HH ( c, d, a, HH ( b, c, d, HH ( a, b, c, HH ( d, a, b, HH ( c, d, a, HH ( b, c, d, HH ( a, b, c, HH ( d, a, b, HH ( c, d, a, HH ( b, c, d, /* Round 4 */ #define S41 6 #define S42 10 #define S43 15 #define S44 21 II ( a, b, c, II ( d, a, b, II ( c, d, a, II ( b, c, d, II ( a, b, c, II ( d, a, b, II ( c, d, a, II ( b, c, d, II ( a, b, c, II ( d, a, b, II ( c, d, a, II ( b, c, d, II ( a, b, c,

d, c, b, a, d, c, b, a, d, c, b, a, d, c, b, a,

in[ 1], in[ 6], in[11], in[ 0], in[ 5], in[10], in[15], in[ 4], in[ 9], in[14], in[ 3], in[ 8], in[13], in[ 2], in[ 7], in[12],

S21, S22, S23, S24, S21, S22, S23, S24, S21, S22, S23, S24, S21, S22, S23, S24,

0xF61E2562L); 0xC040B340L); 0x265E5A51L); 0xE9B6C7AAL); 0xD62F105DL); 0x02441453L); 0xD8A1E681L); 0xE7D3FBC8L); 0x21E1CDE6L); 0xC33707D6L); 0xF4D50D87L); 0x455A14EDL); 0xA9E3E905L); 0xFCEFA3F8L); 0x676F02D9L); 0x8D2A4C8AL);

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

d, c, b, a, d, c, b, a, d, c, b, a, d, c, b, a,

in[ 5], in[ 8], in[11], in[14], in[ 1], in[ 4], in[ 7], in[10], in[13], in[ 0], in[ 3], in[ 6], in[ 9], in[12], in[15], in[ 2],

S31, S32, S33, S34, S31, S32, S33, S34, S31, S32, S33, S34, S31, S32, S33, S34,

0xFFFA3942L); 0x8771F681L); 0x6D9D6122L); 0xFDE5380CL); 0xA4BEEA44L); 0x4BDECFA9L); 0xF6BB4B60L); 0xBEBFBC70L); 0x289B7EC6L); 0xEAA127FAL); 0xD4EF3085L); 0x04881D05L); 0xD9D4D039L); 0xE6DB99E5L); 0x1FA27CF8L); 0xC4AC5665L);

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

d, c, b, a, d, c, b, a, d, c, b, a, d,

in[ 0], in[ 7], in[14], in[ 5], in[12], in[ 3], in[10], in[ 1], in[ 8], in[15], in[ 6], in[13], in[ 4],

S41, S42, S43, S44, S41, S42, S43, S44, S41, S42, S43, S44, S41,

0xF4292244L); 0x432AFF97L); 0xAB9423A7L); 0xFC93A039L); 0x655B59C3L); 0x8F0CCC92L); 0xFFEFF47DL); 0x85845DD1L); 0x6FA87E4FL); 0xFE2CE6E0L); 0xA3014314L); 0x4E0811A1L); 0xF7537E82L);

/* /* /* /* /* /* /* /* /* /* /* /* /*

49 50 51 52 53 54 55 56 57 58 59 60 61

*/ */ */ */ */ */ */ */ */ */ */ */ */

II ( d, a, b, c, in[11], S42, 0xBD3AF235L); /* 62 */ II ( c, d, a, b, in[ 2], S43, 0x2AD7D2BBL); /* 63 */ II ( b, c, d, a, in[ 9], S44, 0xEB86D391L); /* 64 */ buf[0] buf[1] buf[2] buf[3] } /* MD5 test vectors: d41d8cd98f00b204e9800998ecf8427e "" 0cc175b9c0f1b6a831c399e269772661 "a" 900150983cd24fb0d6963f7d28e17f72 "abc" f96b697d7cb7938d525a2f31aaf161d0 "message digest" c3fcd3d76192e4007dfb496cca67e13b "abcdefghijklmnopqrstuvwxyz" d174ab98d277d9f5a5611c2c9f419d9f "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijk\ lmnopqrstuvwxyz0123456789" 57edf4a22be3c955ac49da2e2107b67a "1234567890123456789012345678901234567\ 8901234567890123456789012345678901234567890" 900150983cd24fb0d6963f7d28e17f72 foo */ += += += += a; b; c; d;

Appendix D. The Secure Hash Algorithm

/* Implementation of NIST's Secure Hash Algorithm (FIPS 180) * Lightly bummed for execution efficiency. * * Jim Gillogly 3 May 1993 * * Compile: cc -O -o sha sha.c * * To remove the test wrapper and use just the nist_hash() routine, * compile with -DONT_WRAP * * Usage: sha [-vt] [filename ...] * * -v switch: output the filename as well * -t switch: suppress spaces between 32-bit blocks * * If no input files are specified, process standard input. * * Output: 40-hex-digit digest of each file specified (160 bits) * * Synopsis of the function calls: * * sha_file(char *filename, unsigned long *buffer) * Filename is a file to be opened and processed. * buffer is a user-supplied array of 5 or more longs. * The 5-word buffer is filled with 160 bits of nonterminated hash.

* Returns 0 if successful, non-zero if bad file. * * void sha_stream(FILE *stream, unsigned long *buffer) * Input is from already-opened stream, not file. * * void sha_memory(char *mem, long length, unsigned long *buffer) * Input is a memory block "length" bytes long. * * Caveat: * Not tested for case that requires the high word of the length, * which would be files larger than 1/2 gig or so. * * Limitation: * sha_memory (the memory block function) will deal with blocks no longer * than 4 gigabytes; for longer samples, the stream version will * probably be most convenient (e.g. perl moby_data.pl | sha). * * Bugs: * The standard is defined for bit strings; I assume bytes. * * test vector: "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" * should compute: * 0xd2516ee1L * 0xacfa5bafL * 0x33dfc1c4L * 0x71e43844L * 0x9ef134c8L * * test vector: "abc" * should compute: * 0x0164b8a9L * 0x14cd2a5eL * 0x74c4f7ffL * 0x082c4d97L * 0xf1edf880L * * Copyright 1993, Dr. James J. Gillogly * This code may be freely used in any application. */ #include <stdio.h> #include <memory.h> #define TRUE 1 #define FALSE 0 #define SUCCESS 0 #define FAILURE -1 int sha_file(); void sha_stream(), sha_memory(); static void nist_guts(); #ifndef ONT_WRAP #define HASH_SIZE 5 /* Using just the hash routine itself */ /* Produces 160-bit digest of the message /* External entries */

*/ main(argc, argv) int argc; char **argv; { unsigned long hbuf[HASH_SIZE]; char *s; int file_args = FALSE; /* If no files, take it from stdin */ int verbose = FALSE; int terse = FALSE; #ifdef MEMTEST sha_memory("abc", 3l, hbuf); /* NIST test value from appendix A */ if (verbose) printf("Memory:"); if (terse) printf("%08x%08x%08x%08x%08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]); else printf("%08x %08x %08x %08x %08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]); #endif for (++argv; --argc; ++argv) /* March down the arg list */ { verbose = TRUE; if (**argv == '-') /* Process one or more flags */ for (s = &(*argv)[1]; *s; s++) /* Obfuscated C contest entry */ switch(*s) { case 'v': case 'V': verbose = TRUE; break; case 't': case 'T': terse = TRUE; break; default: fprintf(stderr, "Unrecognized flag: %c\n", *s); return FALSE; } else /* Process a file */ { if (verbose) printf("%s:\t\t", *argv); file_args = TRUE; /* Whether or not we could read it */ if (sha_file(*argv, hbuf) == FAILURE) printf("Can't open file %s.\n", *argv); else if (terse) printf("%08x%08x%08x%08x%08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]); else printf("%08x %08x %08x %08x %08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]);

} } if (! file_args) /* No file specified */ { if (verbose) printf("%s:\t\t", *argv); sha_stream(stdin, hbuf);

} return TRUE;

if (terse) printf("%08x%08x%08x%08x%08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]); else printf("%08x %08x %08x %08x %08x\n", hbuf[0], hbuf[1], hbuf[2], hbuf[3], hbuf[4]);

#endif ONT_WRAP union longbyte { unsigned long W[80]; time */ char B[320]; counting */ }; sha_file(filename, buffer) char *filename; unsigned long *buffer; { FILE *infile;

/* Process 16 32-bit words at a /* But read them as bytes for

/* Hash a file */

if ((infile = fopen(filename, "rb")) == NULL) { int i; for (i = 0; i < 5; i++) buffer[i] = 0xdeadbeef; return FAILURE; } (void) sha_stream(infile, buffer); fclose(infile); return SUCCESS; } void sha_memory(mem, length, buffer) /* Hash a memory block */ char *mem; unsigned long length; unsigned long *buffer; { nist_guts(FALSE, (FILE *) NULL, mem, length, buffer); } void sha_stream(stream, buffer) FILE *stream; unsigned long *buffer; { nist_guts(TRUE, stream, (char *) NULL, 0l, buffer); } #define */ #define #define #define f0(x,y,z) (z ^ (x & (y ^ z))) f1(x,y,z) (x ^ y ^ z) f2(x,y,z) ((x & y) | (z & (x | y))) f3(x,y,z) (x ^ y ^ z) /* Magic functions

#define */ #define #define #define

K0 0x5a827999 K1 0x6ed9eba1 K2 0x8f1bbcdc K3 0xca62c1d6

/* Magic constants

#define S(n, X) ((X << n) | (X >> (32 - n)))

/* Barrel roll */

#define r0(f, K) \ temp = S(5, A) + f(B, C, D) + E + *p0++ + K; \ E = D; \ D = C; \ C = S(30, B); \ B = A; \ A = temp #define r1(f, K) \ temp = S(5, A) + f(B, C, D) + E + \ (*p0++ = *p1++ ^ *p2++ ^ *p3++ ^ *p4++) + K; \ E = D; \ D = C; \ C = S(30, B); \ B = A; \ A = temp static void nist_guts(file_flag, stream, mem, length, buf) int file_flag; /* Input from memory, or from stream? */ FILE *stream; char *mem; unsigned long length; unsigned long *buf; { int i, nread, nbits; union longbyte d; unsigned long hi_length, lo_length; int padded; char *s; register unsigned long *p0, *p1, *p2, *p3, *p4; unsigned long A, B, C, D, E, temp; unsigned long h0, h1, h2, h3, h4; h0 h1 h2 h3 h4 = = = = = 0x67452301; 0xefcdab89; 0x98badcfe; 0x10325476; 0xc3d2e1f0; /* Accumulators */

padded = FALSE; s = mem; for (hi_length = lo_length = 0; ;) /* Process 16 longs at a time */ { if (file_flag) { nread = fread(d.B, 1, 64, stream); /* Read as 64 bytes */

} else {

if (length < 64) nread = length; else nread = 64; length -= nread; memcpy(d.B, s, nread); s += nread;

} if (nread < 64) /* Partial block? */ { nbits = nread << 3; /* Length: bits */ if ((lo_length += nbits) < nbits) hi_length++; /* 64-bit integer */ if (nread < 64 && ! padded) /* Append a single bit */ { d.B[nread++] = 0x80; /* Using up next byte */ padded = TRUE; /* Single bit once */ } for (i = nread; i < 64; i++) /* Pad with nulls */ d.B[i] = 0; if (nread <= 56) /* Room for length in this block */ { d.W[14] = hi_length; d.W[15] = lo_length; } /* Full block -- get efficient */ if ((lo_length += 512) < 512) hi_length++; /* 64-bit integer */ } p0 = d.W; A = h0; B = h1; C = h2; D = h3; E = h4; r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); r0(f0,K0); p1 = &d.W[13]; p2 = &d.W[8]; p3 = &d.W[2]; p4 = &d.W[0]; r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f0,K0); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f0,K0); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f0,K0); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f0,K0); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f1,K1); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f2,K2); r1(f3,K3); r1(f3,K3); r1(f3,K3); r1(f3,K3);

} else {

h0 += A; h1 += B; h2 += C; h3 += D; h4 += E;

if (nread <= 56) break; /* If it's greater, length in next block */ } buf[0] = h0; buf[1] = h1; buf[2] = h2; buf[3] = h3; buf[4] = h4; }

Appendix E. Select References

Selection and of Passwords in Differing Threat Environments, Department of Defense Password Management Guideline, CSC-STD-002-85, published by the Computer Security Center of the Department of Defense Fort George G. Meade, MD 20755 Discovering Weak Passwords, The COPS Security Checker System by D. Farmer, E. Spafford, Purdue University Technical Report CSD-TR-993, West Lafayette, IN 47907 An Example of Automated Key Cracking, With Microscope and Tweezers: An Analysis of the Internet Virus of 1988, by M. Eichin, J. Rochlis, Massachusetts Institute of Technology, Cambridge, MA 02139 Password Vulnerabilities in Distributed Systems, Computer Emergency Response - An International Problem, by R. Pethia, K. van Wyk CERT/Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213 Key Metrics and the MD5 Message Digest Algorithm, Answers to Frequently Asked Questions About Today's Cryptography, Second edition, by Paul Fahn, RSA Laboratories, Redwood City, CA 94065 (available through anonymous FTP from rsa.com) Implementation Details of the MD5 Message Digest Algorithm, RFC-1321 ('request for comments') The MD5 algorithm, by R. Rivest, MIT Center for Computer Science (available on the internet from gatekeeper.dec.com) Implementation Details of the NIST Secure Hash Standard, The Secure Hash Standard (SHS) Specification, Jan 1992 DRAFT Federal Information Processing Standards Publication YY Director, Computer Systems Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899 (The SHS was approved as a Federal Standard in May, 1993) Other Possible Approaches to Password Generation, Automated Password Generator, NIST publication ????, Director, Computer Systems Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899 (a pronounceable password algorithm using DES)

-----BEGIN PGP SIGNED MESSAGE----Results of a Survey on PGP Pass Phrase Usage Arnold G. Reinhold Cambridge, Massachusetts, USA May 19, 1996

Revised June 1, 1995 Pass phrase management is arguably one of the weakest links in the PGP security chain. To gather some facts on actual pass phrase usage, I recently conducted a survey over the Internet. The survey questionnaire was posted to usenet four times: three times on alt.security.pgp, on March 10, 26 and April 13 and once on sci.crypt on April 24. A total of 46 responses were received, the last on May 7. One respondent declined to answer the pass phrase questions and was excluded. This is not an ideal survey in that the sample size is small and all the respondents are self-selected, but it is the best method for gathering some real data that I could come up with. Thanks to all those who took the trouble to respond. Results Q. 1. On which computer platform do you run PGP? (#number of responses) a. b. c. d. e. f. MS-DOS 24 Windows 12 Macintosh 8 Unix (multi-user) Unix (standalone) Other (specify) OS/2 4 Amiga 2 Atari 1

9 6

Eleven responders indicated two platforms and three indicated three platforms. Most Windows users also indicated MS-DOS. The number of responders who indicated multi-user Unix is a cause for concern. Multi-user Unix is generally considered an undesirable platform for PGP uses since it is so lacking in security. Six of the nine responders who indicated multi-user Unix indicated a personal computer platform as well. The wording of my question does not exclude the use of multi-user Unix systems for encryption only, which is less of a risk. Q. 2 How often do you use PGP? (#number of responses) a. b. c. d. e. f. Rarely 5 Once a month 9 Once a week 6 Several times a week Daily 4 Several times a day 7

14

The highest reported usage was 50 times/day. Q. 3. How long is your public key (pick the closest value)? (#number of responses) a. 384 bits 0

b. 512 bits 1 c. 768 bits 2 d. 1024 bits 33 f. 1280 bits 1 g. 2048 bits 2 d&g. 1024/2048 bits No response 1

Almost everyone is using long keys. Only three responders were using a public key less than 900 bits. Q. 4. How many characters are in your pass phrase? (characters) Minimum 8 First Quartile Median 21 Third Quartile Maximum 100 14 41

Q. 5. How many distinct words are in your pass phrase? (words) Minimum 0 First Quartile Median 4 Third Quartile Maximum 15 2 7

6. How many of these words are in an English dictionary or are proper names? (#number of responses) All Some None 15 15 15

The median fraction of words in an English Dictionary was 5 out of 8. Of the 15 who reported none, 4 indicated use of non-English dictionary words. Average Word Length Dividing the number of characters by the number of words gives an average pass phrase word length for each responder. The distribution of these values was: (characters) Minimum 3.3 First Quartile Median 5.3 Third Quartile Maximum 86.0 4.5 6.9

The median average word length for respondents whose pass phrase was composed entirely of English dictionary words was also 5.3 characters. This is shorter than the median length of words in an English dictionary [DAV] (6 based on a sample of 100), suggesting that pass phrase words are not chosen randomly. 7. Have you written down your pass phrase anywhere? Yes No 2 43

Almost no one admits to writing down their pass phrase. This is in accord with conventional wisdom, but in view of the numerous short pass phrases reported, it may be bad advice. See my article in Internet Secrets [REI]. 8. Any comments on pass phrases? Most respondents included some comment. See Appendix A, below. Several respondents included good suggestions for choosing a pass phrase. A few indicate some incorrect beliefs about pass phrases including: Changing one's pass phrase often is desirable -- it isn't if you don't change your key at the same time Eliminating spaces in a pass phrase is a good idea -- no particular advantage Using foreign language words helps -- not much, especially if it is a language you might be expected to know. Medium of Response a. b. c. d. e. Anonymous snail- mail Anonymous, encrypted e-mail Encrypted e-mail 3 Anonymous e-mail 3 Open e-mail 12 18 9

The medium which responders used to forward their answers to me is of interest in itself. To eliminate any possibility that the data collected could compromise someone's password, I had asked in my first posting that responses only be sent via conventional mail with no return address, i.e. "via anonymous snail-mail." I felt that this method provided the highest level of anonymity. Despite my request, I received about as many e-mail as snail-mail replies to the first posting. A number of the e-mail replies were anonymous. Several responders asked for my PGP public key. My subsequent repostings included my public key but still encouraged snail mail response by offering to contribute the price of postage on all replies received through end of April, 1995 to the Phil Zimmerman defense fund. The repostings did recommend anonymous, PGPencrypted responses as a less secure alternative. Entropy Analysis A pass phrase consisting of dictionary words is weaker than the same size pass phrase made up of random letters. To try to compare different responses on a single scale, I estimated the entropy of each responder's pass phrase using the following approximation: Est_Entropy = 15*num_of_dictionary_words + 5.5*num_of_characters* (1 - num_of_dictionary_words/num_of_words)

This formula assigns 15 bits of entropy to each English dictionary word and 5.5 bits per character to non-dictionary words. It is a very crude formula, and I believe it tends to overestimate the entropy of most pass phrases, but it does allow some further analysis of the survey data. Here are some results using this formula: Estimated Pass Phrase Entropy for all Responses (bits) Minimum 30 First Quartile Median 75 Third Quartile Maximum 473 60 157

Most respondents are using a pass phrase with substantially less entropy than the IDEA 128 bit session key. Median Est. Entropy by Frequency of Use a. b. c. d. e. f. Rarely 60 Once a month 110 Once a week 75 Several times a week Daily 69 Several times a day 90 (bits)

104

There seems to be no correlation between frequency of PGP usage and pass phrase strength. Median Est. Entropy by PGP Key Length (bits) <900 bits (b & c) 1024 bits (d) 3 responses 66 bits 75 bits 87 bits

33 responses

>1100 bits (f, g, d+g)

8 responses

Those who select stronger keys seem to choose stronger pass phrases as well. Median Est. Entropy by Medium of Response (bits) a. b. c. d. e. Snail mail 75 Anonymous, encrypted e-mail Encrypted e-mail 201 Anonymous e-mail 55 Open e-mail 65 105

No strong trend is evident. However, it appears that those responders that used PGP in answering the survey (despite my urgings) have stronger pass phrases: Response not encrypted (a+d+e) Response encrypted (b+c) How big should a pass phrase be? In his paper "Efficient DES Key Search," Michael J. Wiener [WEI] 33 responses 12 responses 75 bits 105 bits

describes a machine that could exhaustively search the 56 bit DES key space in 3.5 hours. He estimated that the machine would cost $1 Million to build in 1993. This method assumes knowledge of a block of plaintext and its matching cyphertext, the so-called "known plaintext" attack. An attacker who had someone's pass-phrase-protected secret key but lacked the pass phrase itself has all the information needed for a known plaintext attack on the pass phrase. The attack is somewhat more complex than in the DES case because the generation of possible pass phrases is harder and less certain than the enumeration of DES keys, and because the algorithm that must be executed to test each pass phrase is more complex, requiring both an MD5 and an IDEA pass. To get a rough estimate of the cost of a pass phrase attack, let's assume that a PGP pass phrase engine that could try 2^56 pass phrases in 3.5 hours could be built for $2 million using 1995 technology. Amortizing the cost over 3 years and assuming 24 hour/day operation gives a capital cost of $76/hour. Adding in $14/hr for power consumption, operator time and floor space, gives a total cost or $90/hr or $315/set of 2^56 pass phrases tested. This cost estimate implies the following rough relationship between bits of pass phrase entropy and the level of protection afforded in terms of cost of attack: Bits 56 60 64 68 72 76 80 Cost of Attack (1995) $315 $5,000 $81,000 $1,290,000 $21,000 ,000 $330,000,000 $5,300,000,000

To allow for progress in electronics, one bit of entropy should be added every 2 to 3 years. Using my rough estimate, 31% of responders had pass phrases with 60 bits of entropy or less; 20% had less than 56 bit of entropy. Recommendations This study, crude as it is, suggests that a significant minority of PGP users are using inadequate pass phrases. Before you say "Well, my pass phrase is long enough," remember that in PGP, as in all public key systems, the security of the messages you send depends on the security of the recipient's secret key, not on your own safeguards. And, in general, you have no way of knowing how careful he or she is. Of course, an attacker that was able to purloin someone's pass-phraseprotected secret key might also be in a position to bug their keyboard or to plant a program that would capture their pass phrase. Still, it is good practice to make every layer of security as effective as practical. Judging from their comments, users with apparently weak pass phrases often thought they were adequate. I believe there are there are two paths to strengthening PGP pass phrases: education and improvements to PGP itself.

Education It should be possible to develop a consensus on minimal standards for pass phrases. My recommendations would include, as a minimum: o Five or more randomly chosen dictionary words, or o A quotation of at least 10 words selected at random from a randomly chosen library book, or o A password of at least 8 random syllables. In addition, I think it is time to reconsider the "never write down your pass phrase" slogan. If writing down at least a portion of one's pass phrase leads to stronger pass phrase choices, it might be a good practice to recommend. Improvements to PGP There are a couple of ways PGP could be improved that would reduce the risk of pass phrase compromise: 1. PGP could warn users when they attempt to enter a pass phrase of 10 characters or less. 2. PGP could include a random pass phrase generator with a couple of options including random dictionary word selection and random pronounceable syllables. Peter Kwangjun Suk [SUK] has compiled a "list of 10760 `words' that are easy to remember but whose average length is 4.77 characters." It might be a good basis for a pass phrase generator. 3. (my favorite) PGP should change the way it hashes pass phrases to substantially increase the computation time required. The Opportunity for Improved Pass Phrase Hashing The Wiener DES engine, described above, assumed one DES trial every 20 nanoseconds in each of the parallel processing nodes. Increasing the time to 0.2 seconds would make such an engine 10,000,000 times more expensive. Also, by using large amounts of memory and as much of the power of the personal computer's microprocessor as possible, the silicon footprint of each node would be greatly increased. Each node in Wiener's DES design had 26,000 equivalent gates. An MD5/IDEA design would require several times as many, say 100,000. On the other hand, simulating the essential parts of a 486-class microprocessor and 1 megabyte of memory might require 10,000,000 equivalent gates, complicating the design of a search engine by another factor of 100. Combined, the two effects described above could make a pass phrase attack one billion times harder, with little negative impact on PGP users. Currently (as I read the source code) PGP uses the MD5 hash of the pass phrase as the IDEA key for encrypting the secret key. Instead, PGP could use the pass phrase as the initial value for a computation-time

intensive hash algorithm optimized to use as much of the processing resources in a typical personal computer as possible, including wide word multiplies, branches and lots of RAM. A good starting place for the design of a computation-time intensive hash algorithm might be the Randomizing by Shuffling method discovered by Carter Bays and S. D. Durham [BAY] and described in Knuth's The Art of Computer Programming [KNU]. The auxiliary table would be large, on the order of 1 megabyte, and filled using a 32-bit linear-congruential pseudo-random number generator. MD5 or SHA passes every so often would add security, but these hash algorithms should not be a large component of the compute time since they are optimized for hardware implementation. In addition, each encrypted secret key should have "salt" stored with it to prevent an attacker from developing a dictionary of IDEA keys that match common pass phrases. The computation-time intensive hash algorithm should have the number of iterations and amount of memory used as parameters. When generating secret keys or when changing pass phrases, users could be given a choice of levels of protection. Each level would specify the number of iterations and amount of memory. This would insure interoperability between different machines. Level A might be the existing PGP scheme for backwards compatibility, Level B might be set for 68000/8086 generation computers, Level C might be set for 486/68040 class machines, Level D might be set for Pentium/PowerPC class machines. Level E and above might double the number of iterations of the previous level. As PGP's gains wider acceptance, new users will likely be even less careful in pass phrase selection and less willing to use long pass phrases than the "early adopters" who responded to this survey. Adding a factor of 10^9 in the difficulty of recovering pass phrases is roughly equivalent to adding 30 bits of entropy to each pass phrase and would significantly improve the security of PGP for all users. References [BAY] C. Bays and S. D. Durham, ACM Trans. Math. Software 2, 1976, pp. 59-64 [DAV] P. Davies, Ed., "The American Heritage Dictionary of the English Language," (55,000 entries), Dell, 1973 [KNU] D. E. Knuth, "The Art of Computer Programming," Vol. 2 "SemiNumerical Algorithms," Second Edition, Sec. 3.2.2, Algorithm B, pp. 3233, Addison-Wesley, 1973 {REI] A. G. Reinhold, "Common Sense and Cryptography," in Internet Secrets, J. R. Levine and C. Baroudi, Ed., IDG Books, 1995, p. 148 [SUK] P. K. Suk, "Re: A Good Solution to the Passphrase Question," posted to alt.security.pgp, 4 Apr 1995 23:21:06 EDT, suk@usceast.cs.scarolina.edu [WEI] M. J. Wiener, "Efficient DES Key Search," Bell-Northern Research,

Ottawa, Ont., Canada, 1993, available at http://www.eff.org/pub/EFF/ Policy/Crypto/Misc/Technical/des_key_search.ps.gz Appendix A - Pass Phrase Survey Comments I do use another language, with numerals included. Longer the better, uses PGP 4-12 times/day. [8 chars, 2 words, 0 English] Uses PGP 50 times/day. Plans to increase to 21 chars. [12 chars, 1word, 0 English] Adds numbers & capitalization to make passphrase more difficult to guess. It's mine and it's SECRET. Event from childhood w/random punctuation & misspellings. [long comment] Plans to increase usage in the future. Pass phrase easy to get by other means: bug keyboard, video tape; therefore complexity not a deterrent. [100 chars, 15 Words, 13 English] Changes passphrase often, uses multiple languages. [long comment] Name of my favorite movie with ? substituted for a letter. Plans to change his passphrase. Why isn't your PGP public key in your .plan file? Mine is easily remembered, but a hybrid of different languages, (none English). I probably use PGP less because my pass phrase is such a pain to type in. [50 chars, 14 words, 11 English] Two keys, one for anonymous. Choose random words from dictionary. [Thailand] Phrase from literature. Includes 9 non-Latin chars, no blanks, uses PGP 30 times a day. Long random phrases are too hard to remember. uses PGP >6 times/day. [39 chars 7 English words] d-15,g-20 If PGP is so secure, how come the weak link is the passphrase. "The Turtle moves" In list of quotes from book he likes, changing to Spanish. Should enforce minimal length/complexity. [12 chars, 2 words, 0 English] Obscures simple phrase by substitutions e.g. "You won four quarts of jello" -> "u14KwartzuvjeLoh". SECDEV passphrase is 20 random alphanumerics selected by pair of dice & 6x6 table. They're easier to remember than strong 8-10 char passwords and stronger. Excerpt from one of the books he owns. Had PGP 2.3a so couldn't read my key. [Japan] All in German dictionary, better than passwords. Changes passphrase every month. Selects from books. "F**k the NSA (and alike)!" [From France where encryption is illegal!] I find PGP a difficult program to use. It ain't user friendly, that for sure. [23 chars, 4 English words] - ---------------------------------------------------------------------------Copyright (c) 1995, Arnold G. Reinhold, Cambridge, Mass. USA. The author hereby grants rights for free non-commercial electronic distribution of the entire text with attribution and signature attached.

-----BEGIN PGP SIGNATURE----Version: 2.6 iQCVAwUBL84Tx2truC2sMYShAQF3tgP/RI3OQNHMu9GmCi7713DeXtzGKPeSYRRF ti6EBsOdu8R1BdFVrW5/nBWG7HqcM0uNVl4Uy2kCAszb4Tonvsaf0qY0Dbw88EyE EyKcfIrFZWSFHn+DlblwzxgnDiYe8owYxDuzCy4Y3kIyGlc8pFXjljMBbKLslog5 PrRHbp6OkrY= =dYyx -----END PGP SIGNATURE-----