[ Contents ]
2. General functions
OpenPGP provides data integrity services for messages and data files
by using these core technologies:
- digital signatures
- encryption
- compression
- radix-64 conversion
In addition, OpenPGP provides key management and certificate
services, but many of these are beyond the scope of this document.
2.1. Confidentiality via Encryption
OpenPGP uses two encryption methods to provide confidentiality:
symmetric-key encryption and public key encryption. With public-key
encryption, the object is encrypted using a symmetric encryption
algorithm. Each symmetric key is used only once. A new "session key"
is generated as a random number for each message. Since it is used
only once, the session key is bound to the message and transmitted
with it. To protect the key, it is encrypted with the receiver's
public key. The sequence is as follows:
1. The sender creates a message.
2. The sending OpenPGP generates a random number to be used as a
session key for this message only.
3. The session key is encrypted using each recipient's public key.
These "encrypted session keys" start the message.
4. The sending OpenPGP encrypts the message using the session key,
which forms the remainder of the message. Note that the message
is also usually compressed.
5. The receiving OpenPGP decrypts the session key using the
recipient's private key.
6. The receiving OpenPGP decrypts the message using the session key.
If the message was compressed, it will be decompressed.
With symmetric-key encryption, an object may be encrypted with a
symmetric key derived from a passphrase (or other shared secret), or
a two-stage mechanism similar to the public-key method described
above in which a session key is itself encrypted with a symmetric
algorithm keyed from a shared secret.
Both digital signature and confidentiality services may be applied to
the same message. First, a signature is generated for the message and
attached to the message. Then, the message plus signature is
encrypted using a symmetric session key. Finally, the session key is
encrypted using public-key encryption and prefixed to the encrypted
block.
2.2. Authentication via Digital signature
The digital signature uses a hash code or message digest algorithm,
and a public-key signature algorithm. The sequence is as follows:
1. The sender creates a message.
2. The sending software generates a hash code of the message.
3. The sending software generates a signature from the hash code
using the sender's private key.
4. The binary signature is attached to the message.
5. The receiving software keeps a copy of the message signature.
6. The receiving software generates a new hash code for the
received message and verifies it using the message's signature.
If the verification is successful, the message is accepted as
authentic.
2.3. Compression
OpenPGP implementations MAY compress the message after applying the
signature but before encryption.
2.4. Conversion to Radix-64
OpenPGP's underlying native representation for encrypted messages,
signature certificates, and keys is a stream of arbitrary octets.
Some systems only permit the use of blocks consisting of seven-bit,
printable text. For transporting OpenPGP's native raw binary octets
through channels that are not safe to raw binary data, a printable
encoding of these binary octets is needed. OpenPGP provides the
service of converting the raw 8-bit binary octet stream to a stream
of printable ASCII characters, called Radix-64 encoding or ASCII
Armor.
Implementations SHOULD provide Radix-64 conversions.
Note that many applications, particularly messaging applications,
will want more advanced features as described in the OpenPGP-MIME
document, RFC 2015. An application that implements OpenPGP for
messaging SHOULD implement OpenPGP-MIME.
2.5. Signature-Only Applications
OpenPGP is designed for applications that use both encryption and
signatures, but there are a number of problems that are solved by a
signature-only implementation. Although this specification requires
both encryption and signatures, it is reasonable for there to be
subset implementations that are non-comformant only in that they omit
encryption.
Updated: 1999-05-23 wkoch