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

http://www.pgp.com/downloads/sourcecode/index.html 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 email 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 http://www.pgp.com/

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 email 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 Email: Email 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