Gives the advanced user an insight of what is happening behind the user interface. These pieces are mainly from the doc's that comes with PGP 5 and 6, and the OpenPGP standard.

Content
Algorithms

Message digest, SHA, MD5
Asymmetrical Encryption, DSS, RSA, ElGamal, Diffie- Hellman, two keypairs
Symmetrical Encryption, Automatic selection, Modes, CAST, IDEA, 3DES

Keysizes for Diffie-Hellman/RSA (Encryption)
Keysizes for Digital signatures
Faster keygeneration for Diffie-Hellman keys
Public/private keyringfile
Specifying a default keypair.
PGP/MIME
Getting keys from email
Patches
Message ID
Longer fingerprint
Usernames
Files

About the Message Digest
The message digest, also called hashsum, is a compact (160-bit, or 128-bit) "distillate" of your message or file. You can also think of it as a "fingerprint" of the message or file. The message digest "represents" your message, such that if the message were altered in any way, a different message digest would be computed from it. This makes it possible to detect any changes made to the message by a forger. A message digest is computed using a cryptographically strong one-way hash function of the message. It should be computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. In that respect, a message digest is much better than a checksum, because it is easy to devise a different message that would produce the same checksum. But like a checksum, you can’t derive the original message from its message digest. [1]
The hashsum is also used in two other ways. If it is calculated over your pass phrase, the hashsum becomes the encryption key used for symmetrical encryption.
It can also be calculated over your public key, and become a fingerprint; a shorter way to represent your public key.

SHA
The message digest algorithm now used in PGP (Version 5.0 and later) is called SHA, which stands for Secure Hash Algorithm, designed by the NSA for National Institute of Standards and Technology (NIST). SHA is a 160-bit hash algorithm. Some people might regard anything from the NSA with suspicion, because the NSA is in charge of intercepting communications and breaking codes. But keep in mind that the NSA has no interest in forging signatures, and the government would benefit from a good unforgeable digital signature standard that would preclude anyone from repudiating their signatures. That has distinct benefits for law enforcement and intelligence gathering. Also, SHA has been published in the open literature and has been extensively peer reviewed by most of the best cryptographers in the world who specialise in hash functions, and the unanimous opinion is that SHA is extremely well designed. It has some design innovations that overcome all the observed weaknesses in message digest algorithms previously published by academic cryptographers. All new versions of PGP use SHA as the message digest algorithm for creating signatures with the new DSS keys that comply with the NIST Digital Signature Standard. [1]

NIST decided to "correct a technical flaw that made the standard less secure than had been thought. The NSA refused to elaborate on the exact nature of the flaw". The corrected version is now called SHA-1. [6]

From PGP version 5, SHA-1 is used to calculate hashsum‘s instead of the earlier MD5. The hashsum is used by DSS to create digital signatures. FIPS 180-1, Secure Hash Standard describes SHA-1 at; http://csrc.nist.gov/fips/fip180-1.txt

MD5
For compatibility reasons, new versions of PGP still use MD5 for RSA signatures, because older versions of PGP used MD5 for RSA signatures. The message digest algorithm used by older versions of PGP is the MD5 Message Digest Algorithm, placed in the public domain by RSA Data Security, Inc. MD5 is a 128-bit hash algorithm. In 1996, MD5 was all but broken by Hans Dobbertin, a German cryptographer. While MD5 was not completely broken at that time, it was discovered to have such serious weaknesses that no one should keep using it to generate signatures. Further work in this area might completely break it, thus allowing signatures to be forged. If you don’t want to someday find your PGP digital signature on a forged confession, you might be well advised to migrate to the new PGP DSS keys as your preferred method for making digital signatures, because DSS uses SHA as its secure hash algorithm. [1]

More details can be found in "On recent Results for MD2, MD4 and MD5", RSA Laboratories bulletin #4, 12 Nov, 1996. And The hash function RIPEMD-160 contains comparisons against other hash algorithms.

A Swedish investigation on Security on the Swedish Internet, October -97, http://www.snus.se/internetutred/ , chap 17, is also recommending SHA-1 for all new developments instead of MD5. (double check this recommendation)

DSS, Digital signatures
DSS is implemented in PGP 5 to replace RSA for creating digital signatures. The Digital Signature Standard is adopted as a Federal Information Processing Standard; http://csrc.nist.gov/fips/fips186.txt . A change notice - 1 is dated, 1996 December 30. Although DSS allows keys of any length, only keys between 512 and 1024 bits are permitted under the FIPS. As specified, it's intended to be used only for digital signatures and hashsums (although it is possible to use it for encryption as well.) [4]

RSA
There are two distinct types of keys supported by this version of PGP. One is the traditional RSA key used in older versions of PGP and the other is a new type of key called DSS/Diffie-Hellman which are based on the latest advancements in cryptographic technologies. [1]

RSA is supported in PGP 5.0 for backward compatibility. (except for key generation in the freeware version)

DSS is the replacement for RSA:s function to create digital signatures, and the ElGamal method that uses Diffie Hellman, replaces the RSA:s function for asymmetrical encryption.

PGP used RSA with one keypair for both signature and encryption/decryption.

RSA is patented under U.S. Patent 4,405,829, issued September 20, 1983 and held by RSA Data Security, Inc. California; the patent expires in 2000. The reason for why RSA is covered by patent within US and not in the rest of the world is a result of different patent laws. In US a patent can be filed up to one year after it has been published. In Europe and Japan, a patent can not be filed if the invention has been published. [2]

ElGamal.
Named after its creator Tather ElGamal, this is a public key encryption system that is based on the Diffie Hellman key exchange protocol. ElGamal may be used for encryption and digital signatures in a manner similar to the RSA algorithm. [4]

But in PGP it's only used for encryption, and DSS is used for signatures.

PKP [Public Key Partner] claimed that ElGamal was covered under the Diffie-Hellman patent. The patent for ElGamal expired on April 29, 1997, making ElGamal the first public-key cryptography algorithm suitable for encryption and digital signatures unencumbered by patents in United States. [7]

Diffie-Hellman
A system for exchanging cryptographic keys between active parties. Diffie-Hellman is not actually a method for encryption and decryption, but a method of developing and exchanging a shared private key over a public communication channel. In effect, the two parties agree to some common numerical values, and then each party creates a key. Mathematical transformations of the keys are exchanged. Each party can then calculate a third session key that can not easily be derived by an attacker who knows both exchange values. [5]

Diffie - Hellman is sometimes abbreviated to D-H.

The Diffie-Hellman and Hellman-Merkle patents [8] expires 1998, opening the door to royalty-free use of public key algorithms. Everyone will benefit from this, because the whole computer industry has been forced to work with a public key patent monopoly that stifled the use of public key algorithms for many years. Now the field is opening up. PGP offers Diffie-Hellman (the ElGamal variant of Diffie-Hellman) keys, and the NIST Digital Signature Standard (DSS) keys. With these new keys comes a range of new features, including improved speed and security. Also, there are now two separate key pairs for each user, one pair for encrypting/decrypting (Diffie-Hellman), and one pair for signing/verifying (DSS). These are presented to the user as if they were a single key pair, but from version 6.0 it is possible to give the user the capability to change his DH key without changing his DSS key. [3?]

In Diffie-Hellman, Alice combines Bob's public key with her own private key to create a sessionkey. And Bob combines his private key with Alice's public key to create the same session key. Thus the same sessionkey is created twice.

Two keypair
The keys you create as well as those you collect from others are stored on digital key rings, which are essentially files stored on your hard drive or on a floppy disk. Normally your private keys are stored in a file named "secring.skr" and your public keys are stored in another file named "pubring.pkr". These files are usually located in the same program directory as the other PGP program files. Thus we have a total of 4 keys:

• Public Key for Diffie-Hellman in pubring.pkr (encryption)
• Public Key for DSS in pubring.pkr (signatures)
• Private Key for Diffie-Hellman in secring.skr (encryption)
• Private Key for DSS in secring.skr (signatures)

The keys are stored -encrypted with your pass phrase- as files on your harddisk/floppy. The password is the same for both keys. But you can set two different times, in seconds, that the password for the signature key, and the encryption key should remain in the RAM-memory.

PGP offers a selection of three different secret-key algorithms to encrypt the actual message. By secret key algorithm, we mean a conventional, or symmetric, block cipher that uses the same key to both encrypt and decrypt. The three symmetric block ciphers offered are CAST, Triple-DES, and IDEA. They are not "home-grown" algorithms. Teams of cryptographers with distinguished reputations developed them all. [1] From version 5.5.3, the user can select a preferred algorithm when he generates his keypair.

Automatic key selection
PGP public keys that were generated by PGP Version 5.0 or later have information embedded in them that tells a sender what block ciphers are understood by the recipient’s software, so that the sender’s software knows which ciphers can be used to encrypt. DSS/Diffie-Hellman public keys will accept CAST, IDEA, or triple-DES as the block cipher, with CAST as the default selection. At present, for compatibility reasons, RSA keys do not provide this feature. Only the IDEA cipher is used by PGP to send messages to RSA keys, because older versions of PGP only supported RSA and IDEA. [1]

Modes
For the cryptographically curious, all three ciphers operate on 64-bit blocks of plaintext and ciphertext. CAST and IDEA have key sizes of 128 bits, while triple-DES uses a 168-bit key. Like Data Encryption Standard (DES), any of these ciphers can be used in Cipher Feedback (CFB) and Cipher Block Chaining (CBC) modes. PGP uses them in 64-bit CFB mode. [1]

CAST
Zimmerman writes: I included the CAST encryption algorithm in PGP because it shows promise as a good block cipher with a 128-bit key size, it’s very fast, and it’s free. Its name is derived from the initials of its designers, Carlisle Adams and Stafford Tavares of Northern Telecom (Nortel). Nortel has applied for a patent for CAST, but they have made a commitment in writing to make CAST available to anyone on a royalty-free basis. CAST appears to exceptionally well-designed, by people with good reputations in the field. The design is based on a very formal approach, with a number of formally provable assertions that give good reasons to believe that it probably requires key exhaustion to break its 128-bit key.

CAST has no weak or semiweak keys. There are strong arguments that CAST is completely immune to both linear and differential cryptanalysis, the two most powerful forms of cryptanalysis in the published literature, both of which have been effective in cracking DES. While CAST is too new to have developed a long track record, its formal design and the good reputations of its designers will undoubtedly attract the attentions and attempted cryptanalytic attacks of the rest of the academic cryptographic community. I’m getting nearly the same preliminary gut feeling of confidence from CAST that I got years ago from IDEA, the cipher I selected for use in earlier versions of PGP. At that time, IDEA was also too new to have a track record, but it has held up well. [1]

[Added 31 dec –98. The CAST algorithm is proprietary to Entrust Technologies, Inc.]
Technical details are in RFC 2144, May 1997, "The CAST-128 Encryption Algorithm"

IDEA
The IDEA (International Data Encryption Algorithm) block cipher is based on the design concept of "mixing operations from different algebraic groups." It was developed at ETH in Zurich by James L. Massey and Xuejia Lai, and published in 1990. Early published papers on the algorithm called it IPES (Improved Proposed Encryption Standard), but they later changed the name to IDEA. So far, IDEA has resisted attack much better than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. And IDEA is more resistant than DES to Biham and Shamir ’s highly successful differential cryptanalysis attack, as well as attacks from linear cryptanalysis. As this cipher continues to attract attack efforts from the most formidable quarters of the cryptanalytic world, confidence in IDEA is growing with the passage of time. Sadly, the biggest obstacle to IDEA’s acceptance as a standard has been the fact that Ascom Systec holds a patent on its design, and unlike DES and CAST, IDEA has not been made available to everyone on a royalty-free basis. [1]
To license IDEA for commercial use, read their Licensing Concept for the International Data Encryption Algorithm Hint; the price is $15 for 1 - 50 end users licences.

Triple-DES
As a hedge, PGP includes three-key triple-DES in its repertoire of available block ciphers. IBM developed the DES in the mid-1970s. While it has a good design, its 56-bit key size is too small by today’s standards. Triple-DES is very strong, and has been well-studied for many years, so it might be a safer bet than the newer ciphers such as CAST and IDEA. Triple-DES is the DES applied three times to the same block of data, using three different keys, except that the second DES operation is run backwards, in decrypt mode. Although triple-DES is much slower than either CAST or IDEA, speed is usually not critical for e-mail applications. While triple-DES uses a key size of 168 bits, it appears to have an effective key strength of at least 112 bits against an attacker with impossibly immense data storage capacity to use in the attack. According to a paper presented by Michael Weiner at Crypto96, [search for link to add about that paper] any remotely plausible amount of data storage available to the attacker would enable an attack that would require about as much work as breaking a 129-bit key. Triple-DES is not encumbered by any patents. [1]

Keysizes for Diffie Hellman/RSA encryption
PGP supports two distinct types of keys - the traditional RSA key used in older versions of PGP and a new type of key called DSS/ Diffie-Hellman which is based on the latest advancements in cryptographic technologies.

The Diffie - Hellman key is used for encryption, and it’s size ranges from 512-4096 bits. The key size corresponds to the number of bits used to construct your digital key. The larger the key, the less chance someone will ever be able to crack it but the longer it will take to perform the decryption and encryption process. You will need to strike a balance between the convenience of performing PGP functions quickly with a smaller key and the increased level of security provided by a larger key. Unless you are exchanging extremely sensitive information which is of enough interest that someone would be willing to mount an expensive and time consuming cryptographic attack in order to read it, you are probably safe using a key composed of 2048 bits. [1]

The RSA-keys ranges from 512 - 2048 bits. The upper limit of 2048 bits for RSA-keys is for backward compatibility reasons. For DSS, the FIPS standard defines the key length to be between 512 and 1024 bits.

Keysizes for Digital signatures
When you create a DSS/Diffie-Hellman key, there is one number of bits for the DSS portion, used for digital signatures, and another number for the Diffie-Hellman portion, which is used for en/decryption. The size of the DSS portion of the key is increased in fixed increments and is less than the size of the Diffie-Hellman portion of the key. In effect, each user has two keypairs; one for signature with DSA, and another one for encrypting with ElGamal. To use maximum keysize write in 4096 in the custom selectable box.

To use the new SHA hash algorithm, users will have to use DSS as their signature algorithm, because PGP's RSA signatures continue to use the MD5 hash for backward-compatibility reasons.

If you plan to exchange e-mail with someone who has PGP 5 or later, then you can take advantage of the new DSS/Diffie-Hellman keys. However, if you are corresponding with someone who is using a previous version of PGP, you have to use the traditional RSA keys to communicate with them.

PGP detects if the recipient key is new or old and encrypts accordingly. But if you select several recipients that has a mixture of both old and new keys, PGP encrypts to the new keys only, and warns you that the recipients with the old key will not be able to decrypt the message.

Faster key generation for Diffie-Hellman keys
When this setting is selected, it requires less time to generate a new DSS/Diffie-Hellman key pair. Using a precalculated set of prime numbers rather than going through the time-consuming process each time a new key is generated speeds up this process. Although it is extremely unlikely that anyone could ever crack your key based on their knowledge of these canned prime numbers, it may be prudent to spend the extra time to create a set of keys with the maximum level of security. More details can be found at the FAQ for comp.security.pgp; http://www.pgp.net/pgpnet/pgp-faq/faq-appendix4.html.

Private/Public Key Ring File
The Public Key Ring File shows the current location and name of the file where the PGP program expects to find your Public keyring file. The default location is \Program Files\PGP\PGP60\pubring.pkr. If you plan on storing your public keys in a file with a different name or in some other location, then you specify this information here. Some users like to keep their private keyring on a floppy and then only insert this disk when they need to sign or decrypt mail. You can use the browse button to search through your files rather than having to explicitly type in the path. The default location for the private keyring is \Program Files\PGP\PGP60\secring.skr

Specifying a Default Key Pair
Each time you create a set of keys, the keys are designated as your default keys and are automatically selected when you perform certain PGP functions. For instance, your default key pair is used when you sign a message or someone's public key. If you have more than one set of keys, you can designate one pair as your default set. Notice the selected key are now boldfaced, indicating they are your default key. The PGPKeys window displays different colours depending on choosed keys. RSA type keys are blue and DSS/Diffie-Hellman keys are gold.

OpenPGP
The global effort to create a common protocol for encrypting email is getting turned on its head. The Internet Engineering Task Force, an international body responsible for adopting Net standards, has decided to work with _both_ S/MIME, created by RSA Data Security and PGP/MIME from Pretty Good Privacy
More details about:
MIME. A goldmine of information is in comp.mail.mime FAQ (frequently asked questions list)
PGP/MIME se http://atropos.c2.net/~raph/pgpmime.html and http://atropos.c2.net/~raph/comparison.html.and IETF's "An Open Specification for Pretty Good Privacy (openpgp)"
S/MIME S/MIME-Central RSA's own information and IETF's "S/MIME Mail Security (smime)"

In November, 1998, IETF adopted "OpenPGP Message Format" as a proposed standard in RFC 2440.

If you are communicating with another PGP user who is using an e-mail application that adheres to the PGP/MIME standard, click on and depress the PGP/MIME button. When you click one of these buttons, they remain indented to indicate the operations you want to perform. If you set the PGP/MIME feature on from the Preferences dialogue box, it will automatically be used as default with every mail. You can also manually turn it on or off by clicking on the PGP/Mime button for mail that should be treated differently.

ACII-Armour- Base 64 - Radix 64
se rfc 1521 [add link]

Plug-in requirements for PGPfreeware, Version 5.0 :

• Microsoft Outlook 8.0 for Windows 95 and NT 4.0. Dont confuse this with 'Outlook Express' that comes with Microsoft's Internet Explorer 4.x. Outlook Express does not support plug-ins, and can thus not be accessed by PGP 5.
• Microsoft Exchange 4.0 for Windows 95 and NT 4.0
• QUALCOMM Eudora Pro or Light 3.0.3 for Windows 95 and NT 4.0
• QUALCOMM Eudora Pro or Light 3.0 for Macintosh
• Claris Emailer 2.0 v1 or greater for Macintosh

If you are communicating with other PGP users, and they have encrypted and signed their mail using the PGP/MIME standard, a lock icon will appear when you open your e-mail. In this case, you can decrypt and verify the message and any attached files by simply double-clicking this icon.

If you are using an e-mail application that is not yet supported by the PGP plug-ins, you must encrypt and sign your e-mail via the Windows clipboard. Essentially, you copy the contents of your message to the clipboard, encrypt and/or sign its contents, then paste it into your email editor before sending it. If you plan to attach any files with your message, you must encrypt them from the Windows Explorer before attaching them.

Get keys from email.
A common usage is to include a URL to find your key on a keyserver in the signature of all your email. Such a URL might look like this: <http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x272727>

You would need to replace the key ID at the end (0x27272727) with your own key ID of course. You can find this by selecting your key in PGPkeys, and then choosing Properties from the menu. More details at; http://www.pgp.net

If your key is signed by an organisation, using PGP:s Certification Authorithy, you instead add the adress to the issuing organisation, instead of the public keyserever on Internet. PGP:s Certification Authorithy is a separate program that is installed in a Internet connected server at the organisation.

Patches
Latest versions 29 Okt -97.

• QUALCOMM Eudora Light is now up at version 3.0.3 for Windows 95 and NT 4.0. http://www.eudora.com
• When PGP is installed on Eudora it appears an instability problem. Symptom: An immedtiate crash in mfc40.dll when trying to send a message (encrypted or not). A patch exists at http://www.privacy.com.au/
• On PGP:s web-site, http://www.pgp.com there is in the Windows FAQ, pathes that "Includes the Passphrase issue workaround and the Microsoft Outlook/Exchange Plug-in Fix." These are not availible outside US. but they might be found at http://www.privacy.com.au
• The article "PGP fixes flaw in crypto software", August 29, 1997 describes one of the patches; that the PGP password can be written to swapfiles on the harddisk. "The fix involves PGP users changing their preferences to set the password to expire in a very short time, like one second. That removes the password from the machine entirely." Details at; http://www.news.com/News/Item/0,4,13853,00.html

Message ID (removed in ver 5.5.3)
Whenever a text is encrypted and the output format is base64, it contains a MessageID header that looks like this:
MessageID: 0Dv61 B01gc 2aX0F GMZmv mIrJ9 240Mz /v
The 32 characters after MessageID are unique for each encrypted message. The message ID is not used anymore. It is a remaining from the times when the mailsystems on BBS:s and fidonet limited the length of a email. PGP would then split a long email into smaller chunks, and used the messageID to put the pieces back again.

Longer fingerprint
The fingerprint is a hashsum which is calculated over the whole public key, and the primary userID. The new hashalgorithm, SHA, produces a longer hashsum (160 bit) than the older MD5 algorithm (128 bit). The result is that the fingerprint increase from 32 characters to 40 characters. This is mainly an esthetical detail for those who print their fingerprint on their business card. As an example, here is two fingerprints:
PGP 5.0; B6F5 DE0A 39EA 41B7 8744 6C7A 0B63 5BA5 3CEA EF2C
PGP 2.x; B9C9 F4C4 81F0 201D A62F 3C60 9CCF 0CCA

A stripped fingerprint is used in PGP's certification server. Instead of using the full 160 bits length of the fingerprint, the key server does only use the least significant 64 bits. The reason for using only a portion of the fingerprint is probably a trade of between the ability to distinguish between different key, and still being able to quickly search for a specific key. Example:
The PGP 5.x key above is in the certification server represented by; 0B63 5BA5 3CEA EF2C

User names
Even if PGP 5 supports usernames with non-us characters like åäö, these characters should be avoided for compatibility reasons with the 7-bit US-ASCII. In order to differentiate between surnam and family name, this syntax can be used:
Laszlo BARANYI. so the familyname is written with Capital characters.

National language support.
There is no easy way  to translate the English text to other languages. There are three things to translate.
1) PGP:s text on the screen. You have to dig into the source code, translate phrases, and recompile.
2) Rewrite Windows help file from scratch. (or does it exists a disassembler that convert a .hlp-file to rtf-format?)
3) Cut & Paste 150 pages of PGP:s documentation that is in PDF-format, and paste it into a a textfile, translate it, and recreta a national PDF-file.

Installationproblems.
At installationtime, PGP 5 automatically removes your old version of PGP, including your private and public keyrings. PGP 5 seems to do the removal if the old version of PGP is stored just below the root. Like; \PGP, but not \Crypto\PGP. In any way, verify that your backup is fresh before installing PGP 5.

References
Source: "Web Security & Commerce", ISBN 1-56592-269-7 Simon Garfinkle
[1] The on-linehelp in PGP.
[2] page 220 in Web Security & Commerce
[3] page 355 in Web Security & Commerce
[4] Page 201 in Web Security & Commerce
[5] Page 200 in Web Security & Commerce
[6] page 479, in Applied Cryptography, Bruce Schneier.
[7] page 479, Applied Cryptography, Bruce Schneier.
[8] The Diffie-Hellman patent, "Cryptographic Apparatus and Method" by Martin E. Hellman, Bailey W. Diffie, and Ralph C. Merkle has number; 4.200.770 and can be found at http://patent.womplex.ibm.com/

More reading
To read nearly 30 non-technical articles about PGP, go to http://www.news.com/ and enter the searchword 'PGP'.

Start of a list of websites that contains more info about PGP.(or easier, link to several existing resource lists)
Australian Privacy  - Security for Australia
PGP 5 Tips: , 11 dec 1997, by brad@his.com

An Open Specification for Pretty Good Privacy (openpgp) The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols.
The mailinglist ietf-open-pgp mailing list is useful to follow the current standardisationwork.

Work that remains: Insert technical information from PGP ver 2.6. Much of those basics are also aplicable in PGP 5.

Update on the differences between PGP ver 5.0 and 5.5.3. (or what's new in PGP ver 5.5.3)

Synchronizing keyserver with local keyring
Any change in the keyserver can automatically be transferred to the local keyring with a single mouseclick. It is also possible to select between several different keyservers. The LDAP, Lightweight Directory Access Protocol, which is also used in all X500 catalogues are also supported. Thus any existing X500 catalogue should be able to act as a keyserver for PGP-certificates. This should preferably be used against a trusted keyserver, like a corporate keyserver.

Selecting symmetrical algorithm.
When a keypair is created, the user is asked about witch symmetrical algorithm that he prefer other users of PGP 5.x to use when they send mail to him. CAST (=default) Triple-DES or IDEA. The choice is written into the certificate for the owner’s public key. Thus the choice can not be changed once the public key has been distributed to all other users.

If the selected algorithm will be broken in the future, then everyone has to replace their existing public key, and redistribute it with another algorithm as their preferred choice. Technically, it would be easier to just change those bits in the certificate that reflects the chosen algorithm, and then certify it again. In that way, the KeyID would be unchanged.

Rephrasing. When PGP encrypts a message, it checks the recipient’s certificate, to check what algorithm the recipients prefers, and will use that algorithm.

No RSA.
The freeware version contains no RSA-encryption and is therefore not backward compatible. It is best suited for new users that don’t need backward compatibility. This is possibly to avoid licensing problems until year 2000 when the RSA-patent expires. The commercial versions do however contain RSA and is thus backward compatible.

Encrypting to groups.
It is possible to create groups, and encrypt a message to all recipients in the group. The message is then automatically sent to a mailing list. All recipients can decipher the message. This is a convenient way for creating encrypted conversations within a closed group within an emaillist.

Encrypting to corporate key.
In the corporate version of PGP, there is the possibility to encrypt a copy of each message, to also be readably by the company security officer. If so, the user is clearly alerted that the message goes to an ADK, Additional Decryption Key. Technically, this is equivalent to encrypt a message to two recipients. They can both read the message without the knowledge of your private key. Se "encrypting to groups" above.

Deleting a signature.
If you find that you -for some reason-would like to redraw an signature from a public key, then that is possible. The main usage of this function is possibly in corporate key servers. When a user has quitted at the company, without revoking his key, then the security officer can:

* Remove his signature from that key, and this change will be reflected to all other users when they update their keyrings from the companies key server.
* Spread the key to keyservers on Internet
* Remove the key from the company’s keyserver.

Hint. Another way to avoid a user who falsely keep using the companies key, is to require that he sends in a copy of his revoked key, before it is ever used. When the user quits, then the revoked key is taken out from the safe, and the key is revoked. This is preferred instead of storing a copy of the user encryptionkey. On the other hand, the one who keeps the key's to the safe with all employees revoked keys, is now the weak link. He has the power to revoke all keys.

Wipe files.
When a key has been encrypted, the plaintext can be overwriting with a bitpattern. This makes it impossible to retrieve the plaintext with software tools, like a binary diskeditor. Even links to the plaintext is removed. In the PGP News groups there are currently (8 Dec -97) roomers that claim that the wiping don’t seems to work. The future will tell if they are right.

Comments.
In the PGP preferences | PGP General | Comment block (optitional) it is possible to define an own message string that is included with every folllowing message. It could for an example be a pointer to your web page where your public key is.

If the field is not filled in, the default message is;
"Version: PGPfreeware 5.5.3 for non-commercial use <http://www.pgp.com>"

The PGP data recovery scheme (this chapter is under writing and doublechecking)
PGP also have a Business Security Suite starting with version 5.5, that includes a data recovery scheme. Below are extracts from the On-line help.

"About message recovery keys
Corporate Message Recovery Keys are keys that allow security officers to decrypt messages that have been sent to or from people within your organization. There are two types of keys: incoming message recovery keys and outgoing message recovery keys ."

"Outgoing Message Recovery Key
The Outgoing Message Recovery Key causes encrypted mail sent from people in your organization also to be encrypted to the Outgoing Message Recovery Key."

"Incoming Message Recovery Key
The Incoming Message Recovery Key causes encrypted mail sent to people in your organization to also be encrypted to the Incoming Message Recovery Key."

During key generation, the certificate for an employee, will be signed by the Corporate Signing Key. The certificate includes two public key; The employees own public key and the Incoming Message Recovery Key for the company. For unknown reason, the signature from the Corporate Signing Key is not shown as other peoples signatures, that users might have been used to. Instead it is indicated with special symbols. And the only way to check which key it is that has signed the employees key, is to select the key, and click on 'properties'. In the box; "Corporate Message Recovery Key" the Corporate Signing Key has been called an 'agent'.

"While the security officer may not ordinarily use the Message Recovery keys, there may be circumstances when it is necessary to recover someone’s e-mail, for example, if someone is injured and out of work for some time or if e-mail records are subpoenaed by a law enforcement agency and the corporation must decrypt mail as evidence for a court case. "

Keys created by version 5.5 is not useful in ver 5.0.
If the employees public key is used in PGP 5.0, there is nothing in ver 5.0 that indicates that the key is signed by the company, or that the company's incomming message recovery key is in the certificate. This could be the reason for why PGP 5.0 will not encrypt messages to PGP 5.5 keys. Otherwise an PGP 5.0 user would beleive that the message was private, while it is readable by the company's Incoming Message Recovery Key.

Keys created in ver 5.0 is not changed by ver 5.5
Keys that are imported to ver 5.5 will not have their certificate changed. Otherwise, it would be possible to add a key to anothers certificate and then upload it to the keyserver.

More to experiment.
The concept of letting the sender of a message encrypt to a company key as well as the intended recipient, is an interresting concept. What mechanism protects a key from having an unauthorised public key attached to it as if it where a company key.

"While the security officer may not ordinarily use the Message Recovery keys, there may be circumstances when it is necessary to recover someone’s e-mail, for example, if someone is injured and out of work for some time or if e-mail records are subpoenaed by a law enforcement agency and the corporation must decrypt mail as evidence for a court case. "

To protect the sessionkeys from an eavesdropper they are RSA encrypted. One sessionkey is encrypted to the intended recipient's RSA key, and the other sessionkey is encrypted to company's corporate RSA key. Thus each message will become a little bit longer for each extra recipient. (Typically a few hundred bytes.)

This forms a basic data recovery scheme. When the company wants to read a message from an employee, they:
1) Use their private RSA key to reach the sessionkey.
2) Let the sessionkey decipher the encrypted message.

It is thus possible for the company to decrypt and read all employee's files, stored on harddisk or sent by email, without requiring access to the sender's private RSA-key.

An example.
A sender encrypts a message to two recipients. This requires four identical copy's of the sessionkey. Each session key is then encrypted to four unique RSA keys which thus can read the message.
1) The sender encrypt the message to his own public key. This is common practice for bussnes related messages, so the sender can read his own messages.
2) The company's public RSA key
3) The public RSA key to Recipient #1
4) The public RSA key to Recipient #2

If the company's private key is compromised then all encrypted messages can easily be read on a large-scale and in real time.

Latest change 26 Dec -98, Laszlo Baranyi, lb@qainfo.se