draft-ietf-openpgp-rfc2440bis-01.txt   draft-ietf-openpgp-rfc2440bis-02.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Counterpane Internet Security Category: INTERNET-DRAFT Counterpane Internet Security
draft-ietf-openpgp-rfc2440bis-01.txt draft-ietf-openpgp-rfc2440bis-02.txt
Expires Apr 2001 Lutz Donnerhacke Expires Apr 2001 Lutz Donnerhacke
October 2000 IN-Root-CA Individual Network e.V. October 2000 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-01.txt draft-ietf-openpgp-rfc2440bis-02.txt
Copyright 2000 by The Internet Society. All Rights Reserved. Copyright 2000 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 25 skipping to change at page 3, line 25
2.2. Authentication via Digital signature 7 2.2. Authentication via Digital signature 7
2.3. Compression 8 2.3. Compression 8
2.4. Conversion to Radix-64 8 2.4. Conversion to Radix-64 8
2.5. Signature-Only Applications 8 2.5. Signature-Only Applications 8
3. Data Element Formats 9 3. Data Element Formats 9
3.1. Scalar numbers 9 3.1. Scalar numbers 9
3.2. Multi-Precision Integers 9 3.2. Multi-Precision Integers 9
3.3. Key IDs 9 3.3. Key IDs 9
3.4. Text 9 3.4. Text 9
3.5. Time fields 10 3.5. Time fields 10
3.6. String-to-key (S2K) specifiers 10 3.6. Keyrings 10
3.6.1. String-to-key (S2k) specifier types 10 3.7. String-to-key (S2K) specifiers 10
3.6.1.1. Simple S2K 10 3.7.1. String-to-key (S2k) specifier types 10
3.6.1.2. Salted S2K 10 3.7.1.1. Simple S2K 10
3.6.1.3. Iterated and Salted S2K 11 3.7.1.2. Salted S2K 11
3.6.2. String-to-key usage 11 3.7.1.3. Iterated and Salted S2K 11
3.6.2.1. Secret key encryption 12 3.7.2. String-to-key usage 12
3.6.2.2. Symmetric-key message encryption 12 3.7.2.1. Secret key encryption 12
3.7.2.2. Symmetric-key message encryption 12
4. Packet Syntax 12 4. Packet Syntax 12
4.1. Overview 12 4.1. Overview 13
4.2. Packet Headers 13 4.2. Packet Headers 13
4.2.1. Old-Format Packet Lengths 13 4.2.1. Old-Format Packet Lengths 13
4.2.2. New-Format Packet Lengths 14 4.2.2. New-Format Packet Lengths 14
4.2.2.1. One-Octet Lengths 14 4.2.2.1. One-Octet Lengths 14
4.2.2.2. Two-Octet Lengths 14 4.2.2.2. Two-Octet Lengths 14
4.2.2.3. Five-Octet Lengths 14 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 15 4.2.3. Packet Length Examples 15
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 16 5. Packet Types 16
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16
5.2. Signature Packet (Tag 2) 17 5.2. Signature Packet (Tag 2) 17
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 19 5.2.2. Version 3 Signature Packet Format 20
5.2.3. Version 4 Signature Packet Format 21 5.2.3. Version 4 Signature Packet Format 21
5.2.3.1. Signature Subpacket Specification 22 5.2.3.1. Signature Subpacket Specification 22
5.2.3.2. Signature Subpacket Types 24 5.2.3.2. Signature Subpacket Types 24
5.2.3.3. Notes on Self-Signatures 24 5.2.3.3. Notes on Self-Signatures 24
5.2.3.4. Signature creation time 25 5.2.3.4. Signature creation time 25
5.2.3.5. Issuer 25 5.2.3.5. Issuer 25
5.2.3.6. Key expiration time 25 5.2.3.6. Key expiration time 25
5.2.3.7. Preferred symmetric algorithms 25 5.2.3.7. Preferred symmetric algorithms 25
5.2.3.8. Preferred hash algorithms 25 5.2.3.8. Preferred hash algorithms 25
5.2.3.9. Preferred compression algorithms 25 5.2.3.9. Preferred compression algorithms 26
5.2.3.10.Signature expiration time 26 5.2.3.10.Signature expiration time 26
5.2.3.11.Exportable Certification 26 5.2.3.11.Exportable Certification 26
5.2.3.12.Revocable 26 5.2.3.12.Revocable 26
5.2.3.13.Trust signature 27 5.2.3.13.Trust signature 27
5.2.3.14.Regular expression 27 5.2.3.14.Regular expression 27
5.2.3.15.Revocation key 27 5.2.3.15.Revocation key 27
5.2.3.16.Notation Data 28 5.2.3.16.Notation Data 28
5.2.3.17.Key server preferences 28 5.2.3.17.Key server preferences 28
5.2.3.18.Preferred key server 28 5.2.3.18.Preferred key server 29
5.2.3.19.Primary user id 28 5.2.3.19.Primary user id 29
5.2.3.20.Policy URL 29 5.2.3.20.Policy URL 29
5.2.3.21.Key Flags 29 5.2.3.21.Key Flags 29
5.2.3.22.Signer's User ID 30 5.2.3.22.Signer's User ID 30
5.2.3.23.Reason for Revocation 30 5.2.3.23.Reason for Revocation 30
5.2.3.24.Features 31
5.2.4. Computing Signatures 31 5.2.4. Computing Signatures 31
5.2.4.1. Subpacket Hints 31 5.2.4.1. Subpacket Hints 32
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 32 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 33
5.4. One-Pass Signature Packets (Tag 4) 33 5.4. One-Pass Signature Packets (Tag 4) 34
5.5. Key Material Packet 34 5.5. Key Material Packet 34
5.5.1. Key Packet Variants 34 5.5.1. Key Packet Variants 35
5.5.1.1. Public Key Packet (Tag 6) 34 5.5.1.1. Public Key Packet (Tag 6) 35
5.5.1.2. Public Subkey Packet (Tag 14) 34 5.5.1.2. Public Subkey Packet (Tag 14) 35
5.5.1.3. Secret Key Packet (Tag 5) 34 5.5.1.3. Secret Key Packet (Tag 5) 35
5.5.1.4. Secret Subkey Packet (Tag 7) 34 5.5.1.4. Secret Subkey Packet (Tag 7) 35
5.5.2. Public Key Packet Formats 34 5.5.2. Public Key Packet Formats 35
5.5.3. Secret Key Packet Formats 36 5.5.3. Secret Key Packet Formats 37
5.6. Compressed Data Packet (Tag 8) 38 5.6. Compressed Data Packet (Tag 8) 38
5.7. Symmetrically Encrypted Data Packet (Tag 9) 38 5.7. Symmetrically Encrypted Data Packet (Tag 9) 39
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 39 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 40
5.9. Literal Data Packet (Tag 11) 39 5.9. Literal Data Packet (Tag 11) 40
5.10. Trust Packet (Tag 12) 40 5.10. Trust Packet (Tag 12) 41
5.11. User ID Packet (Tag 13) 40 5.11. User ID Packet (Tag 13) 41
6. Radix-64 Conversions 40 5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15) 41
6.1. An Implementation of the CRC-24 in "C" 41 5.13. Modification Detection Code Packet (Tag 16) 43
6.2. Forming ASCII Armor 41 6. Radix-64 Conversions 43
6.3. Encoding Binary in Radix-64 43 6.1. An Implementation of the CRC-24 in "C" 44
6.4. Decoding Radix-64 45 6.2. Forming ASCII Armor 44
6.5. Examples of Radix-64 45 6.3. Encoding Binary in Radix-64 47
6.6. Example of an ASCII Armored Message 46 6.4. Decoding Radix-64 48
7. Cleartext signature framework 46 6.5. Examples of Radix-64 48
7.1. Dash-Escaped Text 46 6.6. Example of an ASCII Armored Message 49
8. Regular Expressions 47 7. Cleartext signature framework 49
9. Constants 47 7.1. Dash-Escaped Text 50
9.1. Public Key Algorithms 48 8. Regular Expressions 50
9.2. Symmetric Key Algorithms 48 9. Constants 51
9.3. Compression Algorithms 48 9.1. Public Key Algorithms 51
9.4. Hash Algorithms 49 9.2. Symmetric Key Algorithms 51
10. Packet Composition 49 9.3. Compression Algorithms 52
10.1. Transferable Public Keys 49 9.4. Hash Algorithms 52
10.2. OpenPGP Messages 50 10. Packet Composition 52
10.3. Detached Signatures 51 10.1. Transferable Public Keys 52
11. Enhanced Key Formats 51 10.2. OpenPGP Messages 53
11.1. Key Structures 51 10.3. Detached Signatures 54
11.2. Key IDs and Fingerprints 52 11. Enhanced Key Formats 54
12. Notes on Algorithms 53 11.1. Key Structures 54
12.1. Symmetric Algorithm Preferences 53 11.2. Key IDs and Fingerprints 55
12.2. Other Algorithm Preferences 54 12. Notes on Algorithms 56
12.2.1. Compression Preferences 54 12.1. Symmetric Algorithm Preferences 56
12.2.2. Hash Algorithm Preferences 54 12.2. Other Algorithm Preferences 57
12.3. Plaintext 55 12.2.1. Compression Preferences 57
12.4. RSA 55 12.2.2. Hash Algorithm Preferences 58
12.5. Elgamal 55 12.3. Plaintext 58
12.6. DSA 56 12.4. RSA 58
12.7. Reserved Algorithm Numbers 56 12.5. Elgamal 58
12.8. OpenPGP CFB mode 56 12.6. DSA 59
13. Security Considerations 58 12.7. Reserved Algorithm Numbers 59
14. Implementation Nits 59 12.8. OpenPGP CFB mode 60
15. Authors and Working Group Chair 60 13. Security Considerations 61
16. References 61 14. Implementation Nits 62
17. Full Copyright Statement 63 15. Authors and Working Group Chair 63
16. References 64
17. Full Copyright Statement 66
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 10, line 10 skipping to change at page 10, line 10
3.4. Text 3.4. Text
The default character set for text is the UTF-8 [RFC2279] encoding The default character set for text is the UTF-8 [RFC2279] encoding
of Unicode [ISO10646]. of Unicode [ISO10646].
3.5. Time fields 3.5. Time fields
A time field is an unsigned four-octet number containing the number A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC. of seconds elapsed since midnight, 1 January 1970 UTC.
3.6. String-to-key (S2K) specifiers 3.6. Keyrings
A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but
may be any suitable database. It is beyond the scope of this
standard to discuss the details of keyrings or other databases.
3.7. String-to-key (S2K) specifiers
String-to-key (S2K) specifiers are used to convert passphrase String-to-key (S2K) specifiers are used to convert passphrase
strings into symmetric-key encryption/decryption keys. They are strings into symmetric-key encryption/decryption keys. They are
used in two places, currently: to encrypt the secret part of private used in two places, currently: to encrypt the secret part of private
keys in the private keyring, and to convert passphrases to keys in the private keyring, and to convert passphrases to
encryption keys for symmetrically encrypted messages. encryption keys for symmetrically encrypted messages.
3.6.1. String-to-key (S2k) specifier types 3.7.1. String-to-key (S2k) specifier types
There are three types of S2K specifiers currently supported, as There are three types of S2K specifiers currently supported, as
follows: follows:
3.6.1.1. Simple S2K 3.7.1.1. Simple S2K
This directly hashes the string to produce the key data. See below This directly hashes the string to produce the key data. See below
for how this hashing is done. for how this hashing is done.
Octet 0: 0x00 Octet 0: 0x00
Octet 1: hash algorithm Octet 1: hash algorithm
Simple S2K hashes the passphrase to produce the session key. The Simple S2K hashes the passphrase to produce the session key. The
manner in which this is done depends on the size of the session key manner in which this is done depends on the size of the session key
(which will depend on the cipher used) and the size of the hash (which will depend on the cipher used) and the size of the hash
skipping to change at page 10, line 52 skipping to change at page 11, line 6
second gets preloaded with 1 octet of zero, the third is preloaded second gets preloaded with 1 octet of zero, the third is preloaded
with two octets of zeros, and so forth). with two octets of zeros, and so forth).
As the data is hashed, it is given independently to each hash As the data is hashed, it is given independently to each hash
context. Since the contexts have been initialized differently, they context. Since the contexts have been initialized differently, they
will each produce different hash output. Once the passphrase is will each produce different hash output. Once the passphrase is
hashed, the output data from the multiple hashes is concatenated, hashed, the output data from the multiple hashes is concatenated,
first hash leftmost, to produce the key data, with any excess octets first hash leftmost, to produce the key data, with any excess octets
on the right discarded. on the right discarded.
3.6.1.2. Salted S2K 3.7.1.2. Salted S2K
This includes a "salt" value in the S2K specifier -- some arbitrary This includes a "salt" value in the S2K specifier -- some arbitrary
data -- that gets hashed along with the passphrase string, to help data -- that gets hashed along with the passphrase string, to help
prevent dictionary attacks. prevent dictionary attacks.
Octet 0: 0x01 Octet 0: 0x01
Octet 1: hash algorithm Octet 1: hash algorithm
Octets 2-9: 8-octet salt value Octets 2-9: 8-octet salt value
Salted S2K is exactly like Simple S2K, except that the input to the Salted S2K is exactly like Simple S2K, except that the input to the
hash function(s) consists of the 8 octets of salt from the S2K hash function(s) consists of the 8 octets of salt from the S2K
specifier, followed by the passphrase. specifier, followed by the passphrase.
3.6.1.3. Iterated and Salted S2K 3.7.1.3. Iterated and Salted S2K
This includes both a salt and an octet count. The salt is combined This includes both a salt and an octet count. The salt is combined
with the passphrase and the resulting value is hashed repeatedly. with the passphrase and the resulting value is hashed repeatedly.
This further increases the amount of work an attacker must do to try This further increases the amount of work an attacker must do to try
dictionary attacks. dictionary attacks.
Octet 0: 0x03 Octet 0: 0x03
Octet 1: hash algorithm Octet 1: hash algorithm
Octets 2-9: 8-octet salt value Octets 2-9: 8-octet salt value
Octet 10: count, a one-octet, coded value Octet 10: count, a one-octet, coded value
skipping to change at page 11, line 50 skipping to change at page 12, line 5
Initially, one or more hash contexts are set up as with the other Initially, one or more hash contexts are set up as with the other
S2K algorithms, depending on how many octets of key data are needed. S2K algorithms, depending on how many octets of key data are needed.
Then the salt, followed by the passphrase data is repeatedly hashed Then the salt, followed by the passphrase data is repeatedly hashed
until the number of octets specified by the octet count has been until the number of octets specified by the octet count has been
hashed. The one exception is that if the octet count is less than hashed. The one exception is that if the octet count is less than
the size of the salt plus passphrase, the full salt plus passphrase the size of the salt plus passphrase, the full salt plus passphrase
will be hashed even though that is greater than the octet count. will be hashed even though that is greater than the octet count.
After the hashing is done the data is unloaded from the hash After the hashing is done the data is unloaded from the hash
context(s) as with the other S2K algorithms. context(s) as with the other S2K algorithms.
3.6.2. String-to-key usage 3.7.2. String-to-key usage
Implementations SHOULD use salted or iterated-and-salted S2K Implementations SHOULD use salted or iterated-and-salted S2K
specifiers, as simple S2K specifiers are more vulnerable to specifiers, as simple S2K specifiers are more vulnerable to
dictionary attacks. dictionary attacks.
3.6.2.1. Secret key encryption 3.7.2.1. Secret key encryption
An S2K specifier can be stored in the secret keyring to specify how An S2K specifier can be stored in the secret keyring to specify how
to convert the passphrase to a key that unlocks the secret data. to convert the passphrase to a key that unlocks the secret data.
Older versions of PGP just stored a cipher algorithm octet preceding Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm. passphrase to a key for the specified cipher algorithm.
For compatibility, when an S2K specifier is used, the special value For compatibility, when an S2K specifier is used, the special value
255 is stored in the position where the hash algorithm octet would 255 is stored in the position where the hash algorithm octet would
skipping to change at page 12, line 35 skipping to change at page 12, line 41
Cipher alg: use Simple S2K algorithm using MD5 hash Cipher alg: use Simple S2K algorithm using MD5 hash
This last possibility, the cipher algorithm number with an implicit This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility; it MAY use of MD5 and IDEA, is provided for backward compatibility; it MAY
be understood, but SHOULD NOT be generated, and is deprecated. be understood, but SHOULD NOT be generated, and is deprecated.
These are followed by an Initial Vector of the same length as the These are followed by an Initial Vector of the same length as the
block size of the cipher for the decryption of the secret values, if block size of the cipher for the decryption of the secret values, if
they are encrypted, and then the secret key values themselves. they are encrypted, and then the secret key values themselves.
3.6.2.2. Symmetric-key message encryption 3.7.2.2. Symmetric-key message encryption
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
packet at the front of a message. This is used to allow S2K packet at the front of a message. This is used to allow S2K
specifiers to be used for the passphrase conversion or to create specifiers to be used for the passphrase conversion or to create
messages with a mix of symmetric-key ESKs and public-key ESKs. This messages with a mix of symmetric-key ESKs and public-key ESKs. This
allows a message to be decrypted either with a passphrase or a allows a message to be decrypted either with a passphrase or a
public key. public key.
PGP 2.X always used IDEA with Simple string-to-key conversion when PGP 2.X always used IDEA with Simple string-to-key conversion when
encrypting a message with a symmetric algorithm. This is deprecated, encrypting a message with a symmetric algorithm. This is deprecated,
skipping to change at page 13, line 34 skipping to change at page 13, line 40
Bit 7 -- Always one Bit 7 -- Always one
Bit 6 -- New packet format if set Bit 6 -- New packet format if set
PGP 2.6.x only uses old format packets. Thus, software that PGP 2.6.x only uses old format packets. Thus, software that
interoperates with those versions of PGP must only use old format interoperates with those versions of PGP must only use old format
packets. If interoperability is not an issue, either format may be packets. If interoperability is not an issue, either format may be
used. Note that old format packets have four bits of content tags, used. Note that old format packets have four bits of content tags,
and new format packets have six; some features cannot be used and and new format packets have six; some features cannot be used and
still be backward-compatible. still be backward-compatible.
Also note that packets with a tag greater than or equal to 16 MUST
use new format packets. The old format packets can only express tags
less than or equal to 15.
Old format packets contain: Old format packets contain:
Bits 5-2 -- content tag Bits 5-2 -- content tag
Bits 1-0 - length-type Bits 1-0 - length-type
New format packets contain: New format packets contain:
Bits 5-0 -- content tag Bits 5-0 -- content tag
4.2.1. Old-Format Packet Lengths 4.2.1. Old-Format Packet Lengths
skipping to change at page 16, line 27 skipping to change at page 16, line 36
5 -- Secret Key Packet 5 -- Secret Key Packet
6 -- Public Key Packet 6 -- Public Key Packet
7 -- Secret Subkey Packet 7 -- Secret Subkey Packet
8 -- Compressed Data Packet 8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet 9 -- Symmetrically Encrypted Data Packet
10 -- Marker Packet 10 -- Marker Packet
11 -- Literal Data Packet 11 -- Literal Data Packet
12 -- Trust Packet 12 -- Trust Packet
13 -- User ID Packet 13 -- User ID Packet
14 -- Public Subkey Packet 14 -- Public Subkey Packet
15 -- Symmetrically Encrypted and Integrity Protected Data
Packet
16 -- Modification Detection Code Packet
60 to 63 -- Private or Experimental Values 60 to 63 -- Private or Experimental Values
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used A Public-Key Encrypted Session Key packet holds the session key used
to encrypt a message. Zero or more Encrypted Session Key packets to encrypt a message. Zero or more Encrypted Session Key packets
(either Public-Key or Symmetric-Key) may precede a Symmetrically (either Public-Key or Symmetric-Key) may precede a Symmetrically
Encrypted Data Packet, which holds an encrypted message. The Encrypted Data Packet, which holds an encrypted message. The
skipping to change at page 17, line 27 skipping to change at page 17, line 37
- MPI of Elgamal (Diffie-Hellman) value g**k mod p. - MPI of Elgamal (Diffie-Hellman) value g**k mod p.
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
The value "m" in the above formulas is derived from the session key The value "m" in the above formulas is derived from the session key
as follows. First the session key is prefixed with a one-octet as follows. First the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended which is equal to the Packet. Then a two-octet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then padded as described in identifier, modulo 65536. This value is then encoded as described
PKCS-1 block type 02 [RFC2437] to form the "m" value used in the in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m"
formulas above. value used in the formulas above.
Note that when an implementation forms several PKESKs with one Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several session key, forming a message that can be decrypted by several
keys, the implementation MUST make new PKCS-1 padding for each key. keys, the implementation MUST make new PKCS-1 encoding for each key.
An implementation MAY accept or use a Key ID of zero as a "wild An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic valid decrypted session key. This format helps reduce traffic
analysis of messages. analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
A signature packet describes a binding between some public key and A signature packet describes a binding between some public key and
skipping to change at page 20, line 40 skipping to change at page 20, line 50
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for described above. The details of the calculation are different for
DSA signature than for RSA signatures. DSA signature than for RSA signatures.
With RSA signatures, the hash value is encoded as described in With RSA signatures, the hash value is encoded as described in
PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
type DigestInfo, and then padded using PKCS-1 block type 01 EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value
[RFC2437]. This requires inserting the hash value as an octet as an octet string into an ASN.1 structure. The object identifier
string into an ASN.1 structure. The object identifier for the type for the type of hash being used is included in the structure. The
of hash being used is included in the structure. The hexadecimal hexadecimal representations for the currently defined hash
representations for the currently defined hash algorithms are: algorithms are:
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
The ASN.1 OIDs are: The ASN.1 OIDs are:
- MD2: 1.2.840.113549.2.2 - MD2: 1.2.840.113549.2.2
- MD5: 1.2.840.113549.2.5 - MD5: 1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1 - RIPEMD-160: 1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26 - SHA-1: 1.3.14.3.2.26
skipping to change at page 23, line 35 skipping to change at page 23, line 40
20 = notation data 20 = notation data
21 = preferred hash algorithms 21 = preferred hash algorithms
22 = preferred compression algorithms 22 = preferred compression algorithms
23 = key server preferences 23 = key server preferences
24 = preferred key server 24 = preferred key server
25 = primary user id 25 = primary user id
26 = policy URL 26 = policy URL
27 = key flags 27 = key flags
28 = signer's user id 28 = signer's user id
29 = reason for revocation 29 = reason for revocation
30 = features
100 to 110 = internal or user-defined 100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it Bit 7 of the subpacket type is the "critical" bit. If set, it
denotes that the subpacket is one that is critical for the evaluator denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize. If a subpacket is encountered that of the signature to recognize. If a subpacket is encountered that
is marked critical but is unknown to the evaluating software, the is marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
skipping to change at page 28, line 26 skipping to change at page 28, line 29
the signature cares to make. The "flags" field holds four octets of the signature cares to make. The "flags" field holds four octets of
flags. flags.
All undefined flags MUST be zero. Defined flags are: All undefined flags MUST be zero. Defined flags are:
First octet: 0x80 = human-readable. This note is text, a note First octet: 0x80 = human-readable. This note is text, a note
from one person to another, and has no from one person to another, and has no
meaning to software. meaning to software.
Other octets: none. Other octets: none.
Notation names are arbitrary strings encoded in UTF-8. They reside
two name spaces: The IETF name space and the user name space.
The IETF name space is registered with IANA. These names MUST NOT
contain the "@" character (0x40) is this is a tag for the user name
space.
Names in the user name space consist of a UTF-8 string tag followed
by "@" followed by a DNS domain name. Note that the tag MUST NOT
contain an "@" character. For example, the "sample" tag used by
Example Corporation could be "sample@example.com".
Names in a user space are owned and controlled by the owners of that
domain. Obviously, it's of bad form to create a new name in a DNS
space that you don't own.
5.2.3.17. Key server preferences 5.2.3.17. Key server preferences
(N octets of flags) (N octets of flags)
This is a list of flags that indicate preferences that the key This is a list of flags that indicate preferences that the key
holder has about how the key is handled on a key server. All holder has about how the key is handled on a key server. All
undefined flags MUST be zero. undefined flags MUST be zero.
First octet: 0x80 = No-modify First octet: 0x80 = No-modify
the key holder requests that this key only be modified or the key holder requests that this key only be modified or
skipping to change at page 31, line 6 skipping to change at page 31, line 27
revoked signature is the self-signature for certifying a user id, a revoked signature is the self-signature for certifying a user id, a
revocation denotes that that user name is no longer in use. Such a revocation denotes that that user name is no longer in use. Such a
revocation SHOULD inclide an 0x20 subpacket. revocation SHOULD inclide an 0x20 subpacket.
Note that any signature may be revoked, including a certification on Note that any signature may be revoked, including a certification on
some other person's key. There are many good reasons for revoking a some other person's key. There are many good reasons for revoking a
certification signature, such as the case where the keyholder leaves certification signature, such as the case where the keyholder leaves
the employ of a business with an email address. A revoked the employ of a business with an email address. A revoked
certification no longer is a part of validity calculations. certification no longer is a part of validity calculations.
5.2.3.24. Features
(array of one-octet values)
The features subpacket denotes which advanced OpenPGP features a
user's implementation supports. This is so that as features are
added to OpenPGP that cannot be backwards-compatible, a user can
state that they can use that feature.
This subpacket is similar to a preferences subpacket, and only
appears in a self-signature.
An implementation SHOULD NOT use a feature listed when sending to a
user who does not state that they can use it.
Defined features are:
1 - Modification Detection (packets 15 and 16)
If an implementation implements any of the defined features, it
SHOULD implement the features subpacket, too.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
The signature data is simple to compute for document signatures The signature data is simple to compute for document signatures
(types 0x00 and 0x01), for which the document itself is the data. (types 0x00 and 0x01), for which the document itself is the data.
For standalone signatures, this is a null string. For standalone signatures, this is a null string.
When a signature is made over a key, the hash data starts with the When a signature is made over a key, the hash data starts with the
skipping to change at page 40, line 37 skipping to change at page 41, line 31
other than local keyring files. other than local keyring files.
5.11. User ID Packet (Tag 13) 5.11. User ID Packet (Tag 13)
A User ID packet consists of data that is intended to represent the A User ID packet consists of data that is intended to represent the
name and email address of the key holder. By convention, it name and email address of the key holder. By convention, it
includes an RFC822 mail name, but there are no restrictions on its includes an RFC822 mail name, but there are no restrictions on its
content. The packet length in the header specifies the length of content. The packet length in the header specifies the length of
the user id. If it is text, it is encoded in UTF-8. the user id. If it is text, it is encoded in UTF-8.
5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15)
The Symmetrically Encrypted Integrity Protected Data Packet is a
variant of the Symmetrically Encrypted Data Packet. It is a new
feature created for OpenPGP that addresses the problem of detecting
a modification to encrypted data. It is used in combination with a
Modification Detection Code Packet.
There is a corresponding feature in the features signature subpacket
that denotes that an implementation can properly use this packet
type. An implementation SHOULD NOT use this packet when encrypting
to a recipient that does not state it can use this packet, and
SHOULD prefer this to older Symmetrically Encrypted Data Packet when
possible.
This packet contains data encrypted with a symmetric-key algorithm
and protected against modification by the SHA-1 hash algorithm. When
it has been decrypted, it will typically contain other packets
(often literal data packets or compressed data packets). The last
decrypted packet in this packet's payload MUST be a Modification
Detection Code packet.
The body of this packet consists of:
- A one-octet version number. The only currently defined value is
1.
- Encrypted data, the output of the selected symmetric-key cipher
operating in Cipher Feedback mode with shift amount equal to the
block size of the cipher (CFB-n where n is the block size).
The symmetric cipher used MUST be specified in a Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted Data Packet. In either case, the cipher
algorithm octet is prefixed to the session key before it is
encrypted.
The data is encrypted in CFB mode, with a CFB shift size equal to
the cipher's block size. The Initial Vector (IV) is specified as
all zeros. Instead of using an IV, OpenPGP prefixes an octet string
to the data before it is encrypted. The length of the octet string
equals the block size of the cipher in octets, plus two. The first
octets in the group, of length equal to the block size of the
cipher, are random; the last two octets are each copies of their 2nd
preceding octet. For example, with a cipher whose block size is 128
bits or 16 octets, the prefix data will contain 16 random octets,
then two more octets, which are copies of the 15th and 16th octets,
respectivelly. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix
data.
The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is
incorrect.
The plaintext of the data to be encrypted is passed through the
SHA-1 hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. Specifically,
the input to the hash function does not include the prefix data
described above; it includes all of the plaintext, and then also
includes two octets of values 0xD0, 0x14. These represent the
encoding of a Modification Detection Code packet tag and length
field of 20 octets.
The resulting hash value is stored in a Modification Detection Code
packet which MUST use the two octet encoding just given to represent
its tag and length field. The body of the MDC packet is the 20
octet output of the SHA-1 hash.
The Modification Detection Code packet is appended to the plaintext
and encrypted along with the plaintext using the same CFB context.
During decryption, the plaintext data should be hashed with SHA-1,
not including the prefix data but including the packet tag and
length field of the Modification Detection Code packet. The body of
the MDC packet, upon decryption, is compared with the result of the
SHA-1 hash. Any difference in hash values is an indication that the
message has been modified and SHOULD be reported to the user.
Likewise, the absence of an MDC packet, or an MDC packet in any
position other than the end of the plaintext, also represent message
modifications and SHOULD also be reported.
Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change
the version back to 1.
5.13. Modification Detection Code Packet (Tag 16)
The Modification Detection Code packet contains a SHA-1 hash of
plaintext data which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data which is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no
other place.
A Modification Detection Code packet MUST have a length of 20
octets.
The body of this packet consists of:
- A 20-octet SHA-1 hash of the preceding plaintext data of the
Symmetrically Encrypted Integrity Protected Data packet, not
including prefix data but including the tag and length byte of
the Modification Detection Code packet.
Note that the Modification Detection Code packet MUST always use a
new-format encoding of the packet tag, and a one-octet encoding of
the packet length. The reason for this is that the hashing rules for
modification detection include a one-octet tag and one-octet length
in the data hash. While this is a bit restrictive, it reduces
complexity.
6. Radix-64 Conversions 6. Radix-64 Conversions
As stated in the introduction, OpenPGP's underlying native As stated in the introduction, OpenPGP's underlying native
representation for objects is a stream of arbitrary octets, and some representation for objects is a stream of arbitrary octets, and some
systems desire these objects to be immune to damage caused by systems desire these objects to be immune to damage caused by
character set translation, data conversions, etc. character set translation, data conversions, etc.
In principle, any printable encoding scheme that met the In principle, any printable encoding scheme that met the
requirements of the unsafe channel would suffice, since it would not requirements of the unsafe channel would suffice, since it would not
change the underlying binary bit streams of the native OpenPGP data change the underlying binary bit streams of the native OpenPGP data
skipping to change at page 48, line 42 skipping to change at page 51, line 46
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA [IDEA] 1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, [SCHNEIER] - 2 - Triple-DES (DES-EDE, [SCHNEIER] -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC2144) 3 - CAST5 (128 bit key, as per RFC2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER] 5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK 6 - Reserved for DES/SK [AES]
7 - Reserved for AES with 128-bit key 7 - AES with 128-bit key
8 - Reserved for AES with 192-bit key 8 - AES with 192-bit key
9 - Reserved for AES with 256-bit key 9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH] 10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other implement IDEA and CAST5.Implementations MAY implement any other
algorithm. algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
skipping to change at page 49, line 22 skipping to change at page 52, line 27
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental) 4 - Reserved for double-width SHA (experimental)
5 - MD2 "MD2" 5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192" 6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit) 7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160"
"HAVAL-5-160"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD Implementations MUST implement SHA-1. Implementations SHOULD
implement MD5. implement MD5.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences messages and to transfer keys. Not all possible packet sequences
are meaningful and correct. This describes the rules for how are meaningful and correct. This describes the rules for how
skipping to change at page 51, line 5 skipping to change at page 54, line 7
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
Literal Message :- Literal Data Packet. Literal Message :- Literal Data Packet.
ESK :- Public Key Encrypted Session Key Packet | ESK :- Public Key Encrypted Session Key Packet |
Symmetric-Key Encrypted Session Key Packet. Symmetric-Key Encrypted Session Key Packet.
ESK Sequence :- ESK | ESK Sequence, ESK. ESK Sequence :- ESK | ESK Sequence, ESK.
Encrypted Message :- Symmetrically Encrypted Data Packet | Encrypted Data :- Symmetrically Encrypted Data Packet |
ESK Sequence, Symmetrically Encrypted Data Packet. Symmetrically Encrypted Integrity Protected Data Packet
Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.
One-Pass Signed Message :- One-Pass Signature Packet, One-Pass Signed Message :- One-Pass Signature Packet,
OpenPGP Message, Corresponding Signature Packet. OpenPGP Message, Corresponding Signature Packet.
Signed Message :- Signature Packet, OpenPGP Message | Signed Message :- Signature Packet, OpenPGP Message |
One-Pass Signed Message. One-Pass Signed Message.
In addition, decrypting a Symmetrically Encrypted Data packet and In addition, decrypting a Symmetrically Encrypted Data Packet or a
Symmetrically Encrypted Integrity Protected Data Packet as well as
decompressing a Compressed Data packet must yield a valid OpenPGP decompressing a Compressed Data packet must yield a valid OpenPGP
Message. Message.
10.3. Detached Signatures 10.3. Detached Signatures
Some OpenPGP applications use so-called "detached signatures." For Some OpenPGP applications use so-called "detached signatures." For
example, a program bundle may contain a file, and with it a second example, a program bundle may contain a file, and with it a second
file that is a detached signature of the first file. These detached file that is a detached signature of the first file. These detached
signatures are simply a signature packet stored separately from the signatures are simply a signature packet stored separately from the
skipping to change at page 55, line 49 skipping to change at page 58, line 56
An ElGamal key consists of a generator g, a prime modulus p, a An ElGamal key consists of a generator g, a prime modulus p, a
secret exponent x, and a public value y = g^x mod p. secret exponent x, and a public value y = g^x mod p.
The generator and prime must be chosen so that solving the discrete The generator and prime must be chosen so that solving the discrete
log problem is intractable. The group g should generate the log problem is intractable. The group g should generate the
multiplicative group mod p-1 or a large subgroup of it, and the multiplicative group mod p-1 or a large subgroup of it, and the
order of g should have at least one large prime factor. A good order of g should have at least one large prime factor. A good
choice is to use a "strong" Sophie-Germain prime in choosing p, so choice is to use a "strong" Sophie-Germain prime in choosing p, so
that both p and (p-1)/2 are primes. In fact, this choice is so good that both p and (p-1)/2 are primes. In fact, this choice is so good
that implementors SHOULD do it, as it avoids a small subgroup that implementers SHOULD do it, as it avoids a small subgroup
attack. attack.
In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that
if the generator g has only small prime factors, and if g divides if the generator g has only small prime factors, and if g divides
the order of the group it generates, then signatures can be forged. the order of the group it generates, then signatures can be forged.
In particular, choosing g=2 is a bad choice if the group order may In particular, choosing g=2 is a bad choice if the group order may
be even. On the other hand, a generator of 2 is a fine choice for an be even. On the other hand, a generator of 2 is a fine choice for an
encryption-only key, as this will make the encryption faster. encryption-only key, as this will make the encryption faster.
While verifying Elgamal signatures, note that it is important to While verifying Elgamal signatures, note that it is important to
skipping to change at page 56, line 33 skipping to change at page 59, line 40
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
768 bits. Note that present DSA is limited to a maximum of 1024 bit 768 bits. Note that present DSA is limited to a maximum of 1024 bit
keys, which are recommended for long-term use. Also, DSA keys MUST keys, which are recommended for long-term use. Also, DSA keys MUST
be an even multiple of 64 bits long. be an even multiple of 64 bits long.
12.7. Reserved Algorithm Numbers 12.7. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementor from actually implementing the issues that prevent an implementer from actually implementing the
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
The reserved symmetric key algorithm, DES/SK (6), does not have The reserved symmetric key algorithm, DES/SK (6), does not have
semantics defined. semantics defined.
The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do
not have OIDs. The reserved algorithm number 4, reserved for a not have OIDs. The reserved algorithm number 4, reserved for a
double-width variant of SHA1, is not presently defined. double-width variant of SHA1, is not presently defined.
We have reserved three algorithm IDs for the US NIST's Advanced
Encryption Standard. This algorithm will work with (at least) 128,
192, and 256-bit keys. We expect that this algorithm will be
selected from the candidate algorithms in the year 2000.
12.8. OpenPGP CFB mode 12.8. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
skipping to change at page 58, line 16 skipping to change at page 61, line 21
for an 8-octet block). for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR and the next BS octets of ciphertext. These are loaded into FR and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
13. Security Considerations 13. Security Considerations
As with any technology involving cryptography, you should check the * As with any technology involving cryptography, you should check
current literature to determine if any algorithms used here have the current literature to determine if any algorithms used here
been found to be vulnerable to attack. have been found to be vulnerable to attack.
This specification uses Public Key Cryptography technologies. * This specification uses Public Key Cryptography technologies.
Possession of the private key portion of a public-private key pair Possession of the private key portion of a public-private key
is assumed to be controlled by the proper party or parties. pair is assumed to be controlled by the proper party or parties.
Certain operations in this specification involve the use of random * Certain operations in this specification involve the use of
numbers. An appropriate entropy source should be used to generate random numbers. An appropriate entropy source should be used to
these numbers. See RFC 1750. generate these numbers. See RFC 1750.
The MD5 hash algorithm has been found to have weaknesses * The MD5 hash algorithm has been found to have weaknesses
(pseudo-collisions in the compress function) that make some people (pseudo-collisions in the compress function) that make some
deprecate its use. They consider the SHA-1 algorithm better. people deprecate its use. They consider the SHA-1 algorithm
better.
Many security protocol designers think that it is a bad idea to use * Many security protocol designers think that it is a bad idea to
a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces behind (signatures). In fact, this was one of the motivating forces
the V4 key format with separate signature and encryption keys. If behind the V4 key format with separate signature and encryption
you as an implementor promote dual-use keys, you should at least be keys. If you as an implementer promote dual-use keys, you should
aware of this controversy. at least be aware of this controversy.
The DSA algorithm will work with any 160-bit hash, but it is * The DSA algorithm will work with any 160-bit hash, but it is
sensitive to the quality of the hash algorithm, if the hash sensitive to the quality of the hash algorithm, if the hash
algorithm is broken, it can leak the secret key. The Digital algorithm is broken, it can leak the secret key. The Digital
Signature Standard (DSS) specifies that DSA be used with SHA-1. Signature Standard (DSS) specifies that DSA be used with SHA-1.
RIPEMD-160 is considered by many cryptographers to be as strong. An RIPEMD-160 is considered by many cryptographers to be as strong.
implementation should take care which hash algorithms are used with An implementation should take care which hash algorithms are
DSA, as a weak hash can not only allow a signature to be forged, but used with DSA, as a weak hash can not only allow a signature to
could leak the secret key. These same considerations about the be forged, but could leak the secret key. These same
quality of the hash algorithm apply to Elgamal signatures. considerations about the quality of the hash algorithm apply to
Elgamal signatures.
If you are building an authentication system, the recipient may * There is a somewhat-related potential security problem in
specify a preferred signing algorithm. However, the signer would be signatures. If an attacker can find a message that hashes to the
foolish to use a weak algorithm simply because the recipient same hash with a different algorithm, a bogus signature
structure can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash
algorithm H. Suppose that Mallet finds a message M' that has the
same hash value as M with H'. Mallet can then construct a
signature block that verifies as Alice's signature of M' with
H'. However, this would also constitute a weakness in either H
or H' or both. Should this ever occur, a revision will have to
be made to this document to revise the allowed hash algorithms.
* If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient
requests it. requests it.
Some of the encryption algorithms mentioned in this document have * Some of the encryption algorithms mentioned in this document
been analyzed less than others. For example, although CAST5 is have been analyzed less than others. For example, although
presently considered strong, it has been analyzed less than CAST5 is presently considered strong, it has been analyzed less
Triple-DES. Other algorithms may have other controversies than Triple-DES. Other algorithms may have other controversies
surrounding them. surrounding them.
Some technologies mentioned here may be subject to government * Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP-compliant. Often the implementations of PGP are not OpenPGP-compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
skipping to change at page 61, line 26 skipping to change at page 64, line 49
Email: rodney@tillerman.to Email: rodney@tillerman.to
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann. Philip R. Zimmermann.
16. References 16. References
[AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/
aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael>
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[BLOWFISH] Schneier, B. "Description of a New Variable-Length [BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software Key, 64-Bit Block Cipher (Blowfish)" Fast Software
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/