PGP An example of Public Key Encryption software

Company Was a personal project of Phil Zimmerman Then purchased by McAfee Software (maker of anti- virus software) The repurchased with a leveraged buyout It is now private

Published As a matter of policy, PGP makes their source code available for download at The software supplied here is the source code for the PGP Desktop product and includes the sources for the PGP Software Development Kit (SDK)

PGP (Pretty Good Privacy) What is PGP? Pretty Good Privacy (PGP) is strong encryption software that enables you to protect your and files by scrambling them so others cannot read them. It also allows you to digitally "sign" your messages in a way that allows others to verify that a message was actually sent by you. PGP is available in freeware and commercial versions all over the world. PGP was first released in 1991 as a DOS program that earned a reputation for being difficult. Current version is 9.5 and is idiot proof Available at

How Does PGP Work? When you install PGP, you will generate a pair of keys for yourself; a "paublic key" and a "private key". The private key is like a regular key. You will use it to unlock your messages. The public key is like a set of keyed-alike locks. You publish your public key (your lock) by sending it to a PGP key server on the Internet (PGP does this automatically) People who wish to send you private use a copy of your lock to lock the message. You keep the (private) key to yourself, so that only you can open and read the messages.

Applying the Keys

Digital Signatures PGP also allows you to sign a message or a file, with or without locking (encrypting) it. Each digital signature is uniquely generated by PGP based on the contents of the message and the signer's private key. The signature can be checked by anyone using the signer's public key. Since the signature is based partly on the contents of the message, if even one character of the message is changed, PGP will report that the signature is invalid. The signature is also based on the signer's private key, and the private key is held only by the signer, so recipients can be sure of exactly who signed the message.  while handwritten signatures are supposedly unique per signer, digital signatures are unique per document and signer. Written signatures can be photocopied from document to document and still appear valid. Digital signatures fail verification when applied to another document.

PGP Flowchart

Various flavors of PGP Determined by the particular communication path secured  PGP sent from client to client  PGP Disk Encryption: Screen to Disk  PGP Shredder: File to Delete  PGP Zip: Readable to compressed files  Etc.

Key Rings Just as you would carry a set of keys to various assets (safe, car, house, etc.) You carry keys to various data assets on your PGP Key ring PGP manages pairs, so that the private is kept secret, and the public is widely circulated

Key Generation and Passphrase You enter a long Passphrase that you can remember Which creates your unique keys  The longer the more secure You passphrase is required for all public key server updates  This way your public key is always under your control  Since people can find your private key on your key ring,  but they can never see your passphrase

Key Services Fingerprint When you get a public key from another source, you compare it to the fingerprint that they send you in the message The fingerprint may either be a Hexadecimal sequence, or a ‘biometric’ sequence of recognizable words

Key Services Subkeys You can have systems in PGP Keys  Similar to Master and individual keys for manual locks in an organization Normally master keys are for signatures  And subkeys are for encryption  Legally binding documents will demand this arrangement in some regions You also have an organization-wide Additional Decryption Key (ADK)  Where the security administrator gives you a particular additional set of keys (like classes of master keys in the real world)

Key Services Revocation You can grant various other people the right to revoke your key E.g., your employer’s PGP administrator This is used in conjunction with the larger Key and Security administration policy

Who can revoke a key? Obviously, a malicious (or erroneously) revocation of some (or all!) of the keys in the system will most likely be a system-wide failure It is impossible to arrange things so that this can not happen (if keys can be revoked at all) Because the principal having authority to revoke keys is very powerful,  the mechanisms used to control it should involve as many participants as possible to guard against malicious attacks,  while at the same time as few as possible to ensure that a key can be revoked without delay

How to distribute a new key After a key has been revoked, a new key must be distributed in some pre-determined manner. Assume that Carol's key has been revoked.  Until a new key has been disseminated, Carol is effectively silenced.  No one will be able to send her data without violating system security, and data coming from her will be discarded for the same reason. Or, in other words, the part of the system controlled by Carol is disconnected and so unavailable. The need for security was deemed higher than the need for availability in this design. One could lump together the authority to create new keys (and certify them) with the authority to revoke keys,  but there is no need to do so.  In fact, for reasons of security, this likely a bad idea.

How to spread the revocation The notification that a key has been revoked and should not be used again must be spread to all those that potentially hold the key, and as rapidly as possible. There are two means of spreading information (e.g., a key revocation here) in a distributed system:  either the information is pushed to users from a central point(s),  or it is pulled from a central point(s) to end users. Pushing the information is the simplest solution in that a message is sent to all participants. However, there is no way of knowing that all participants actually receive the message, and, pushing is not very securable nor very reliable. The alternative to pushing is pulling. In this setup, all keys are included within a certificate that requires the one using them to verify that the key is valid.

Recovery from a leaked key If loss of secrecy and/or authenticity is a system-wide failure, a strategy for recovery must be in place. This strategy will determine who has authority to revoke the key,  how to spread the revocation,  also how to deal with all messages encrypted with the key since the leak is recognized This recovery procedure can be extremely complicated, and while it is in progress the system might be very vulnerable to Denial of Service attacks