draft-ietf-openpgp-rfc2440bis-11.txt   draft-ietf-openpgp-rfc2440bis-12.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-11.txt draft-ietf-openpgp-rfc2440bis-12.txt
Expires Apr 2004 Lutz Donnerhacke Expires May 2005 Lutz Donnerhacke
October 2005 November 2004
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-11.txt draft-ietf-openpgp-rfc2440bis-12.txt
Copyright 2004 by The Internet Society. All Rights Reserved. Copyright 2004 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 52 skipping to change at page 3, line 52
4.2.2.3. Five-Octet Lengths 15 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 16 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 17 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 18
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 20 5.2.2. Version 3 Signature Packet Format 20
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 23
5.2.3.1. Signature Subpacket Specification 24 5.2.3.1. Signature Subpacket Specification 23
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 25
5.2.3.3. Notes on Self-Signatures 25 5.2.3.3. Notes on Self-Signatures 25
5.2.3.4. Signature creation time 26 5.2.3.4. Signature creation time 26
5.2.3.5. Issuer 27 5.2.3.5. Issuer 26
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 27
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 27
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 27
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 28 5.2.3.11.Exportable Certification 28
5.2.3.12.Revocable 28 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 29
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 29
skipping to change at page 4, line 28 skipping to change at page 4, line 28
5.2.3.20.Policy URL 31 5.2.3.20.Policy URL 31
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 32
5.2.3.23.Reason for Revocation 32 5.2.3.23.Reason for Revocation 32
5.2.3.24.Features 33 5.2.3.24.Features 33
5.2.3.25.Signature Target 34 5.2.3.25.Signature Target 34
5.2.3.26.Embedded Signature 34 5.2.3.26.Embedded Signature 34
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 35
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36
5.4. One-Pass Signature Packets (Tag 4) 37 5.4. One-Pass Signature Packets (Tag 4) 36
5.5. Key Material Packet 37 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 37 5.5.1. Key Packet Variants 37
5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.1. Public Key Packet (Tag 6) 37
5.5.1.2. Public Subkey Packet (Tag 14) 38 5.5.1.2. Public Subkey Packet (Tag 14) 37
5.5.1.3. Secret Key Packet (Tag 5) 38 5.5.1.3. Secret Key Packet (Tag 5) 38
5.5.1.4. Secret Subkey Packet (Tag 7) 38 5.5.1.4. Secret Subkey Packet (Tag 7) 38
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 38
5.5.3. Secret Key Packet Formats 40 5.5.3. Secret Key Packet Formats 39
5.6. Compressed Data Packet (Tag 8) 41 5.6. Compressed Data Packet (Tag 8) 41
5.7. Symmetrically Encrypted Data Packet (Tag 9) 42 5.7. Symmetrically Encrypted Data Packet (Tag 9) 42
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 43
5.10. Trust Packet (Tag 12) 44 5.10. Trust Packet (Tag 12) 44
5.11. User ID Packet (Tag 13) 44 5.11. User ID Packet (Tag 13) 44
5.12. User Attribute Packet (Tag 17) 44 5.12. User Attribute Packet (Tag 17) 44
5.12.1. The Image Attribute Subpacket 45 5.12.1. The Image Attribute Subpacket 45
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45
5.14. Modification Detection Code Packet (Tag 19) 47 5.14. Modification Detection Code Packet (Tag 19) 47
skipping to change at page 5, line 24 skipping to change at page 5, line 24
11. Enhanced Key Formats 59 11. Enhanced Key Formats 59
11.1. Key Structures 59 11.1. Key Structures 59
11.2. Key IDs and Fingerprints 60 11.2. Key IDs and Fingerprints 60
12. Notes on Algorithms 61 12. Notes on Algorithms 61
12.1. Symmetric Algorithm Preferences 61 12.1. Symmetric Algorithm Preferences 61
12.2. Other Algorithm Preferences 62 12.2. Other Algorithm Preferences 62
12.2.1. Compression Preferences 62 12.2.1. Compression Preferences 62
12.2.2. Hash Algorithm Preferences 63 12.2.2. Hash Algorithm Preferences 63
12.3. Plaintext 63 12.3. Plaintext 63
12.4. RSA 63 12.4. RSA 63
12.5. DSA 64 12.5. DSA 63
12.6. Reserved Algorithm Numbers 64 12.6. Elgamal 63
12.7. OpenPGP CFB mode 64 12.7. Reserved Algorithm Numbers 64
12.8. OpenPGP CFB mode 64
13. Security Considerations 65 13. Security Considerations 65
14. Implementation Nits 68 14. Implementation Nits 67
15. Authors and Working Group Chair 69 15. Authors and Working Group Chair 68
16. References (Normative) 70 16. References (Normative) 69
17. References (Non-Normative) 71 17. References (Non-Normative) 71
18. Full Copyright Statement 71 18. Full Copyright Statement 71
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."
skipping to change at page 14, line 6 skipping to change at page 14, line 6
Note that the most significant bit is the left-most bit, called bit Note that the most significant bit is the left-most bit, called bit
7. A mask for this bit is 0x80 in hexadecimal. 7. A mask for this bit is 0x80 in hexadecimal.
+---------------+ +---------------+
PTag |7 6 5 4 3 2 1 0| PTag |7 6 5 4 3 2 1 0|
+---------------+ +---------------+
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, the new packet format
used. Note that old format packets have four bits of content tags, is preferred. Note that old format packets have four bits of content
and new format packets have six; some features cannot be used and tags, and new format packets have six; some features cannot be used
still be backward-compatible. and still be backward-compatible.
Also note that packets with a tag greater than or equal to 16 MUST 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 use new format packets. The old format packets can only express tags
less than or equal to 15. 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
skipping to change at page 18, line 39 skipping to change at page 18, line 39
A signature packet describes a binding between some public key and A signature packet describes a binding between some public key and
some data. The most common signatures are a signature of a file or a some data. The most common signatures are a signature of a file or a
block of text, and a signature that is a certification of a User ID. block of text, and a signature that is a certification of a User ID.
Two versions of signature packets are defined. Version 3 provides Two versions of signature packets are defined. Version 3 provides
basic signature information, while version 4 provides an expandable basic signature information, while version 4 provides an expandable
format with subpackets that can specify more information about the format with subpackets that can specify more information about the
signature. PGP 2.6.x only accepts version 3 signatures. signature. PGP 2.6.x only accepts version 3 signatures.
Implementations SHOULD accept V3 signatures. Implementations SHOULD Implementations SHOULD accept V3 signatures. Implementations SHOULD
generate V4 signatures. Implementations MAY generate a V3 signature generate V4 signatures.
that can be verified by PGP 2.6.x.
Note that if an implementation is creating an encrypted and signed Note that if an implementation is creating an encrypted and signed
message that is encrypted to a V3 key, it is reasonable to create a message that is encrypted to a V3 key, it is reasonable to create a
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. These specified in a signature type octet in any given signature. These
meanings are: meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the has not been modified. The signature is calculated over the
text data with its line endings converted to <CR><LF> and text data with its line endings converted to <CR><LF>.
trailing spaces (0x020) and tabs (0x09) removed.
0x02: Standalone signature. 0x02: Standalone signature.
This signature is a signature of only its own subpacket This signature is a signature of only its own subpacket
contents. It is calculated identically to a signature over a contents. It is calculated identically to a signature over a
zero-length binary document. Note that it doesn't make sense to zero-length binary document. Note that it doesn't make sense to
have a V3 standalone signature. have a V3 standalone signature.
0x10: Generic certification of a User ID and Public Key packet. 0x10: Generic certification of a User ID and Public Key packet.
The issuer of this certification does not make any particular The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the assertion as to how well the certifier has checked that the
skipping to change at page 26, line 14 skipping to change at page 26, line 11
self-signature apply to the username, and subpackets that appear in self-signature apply to the username, and subpackets that appear in
the subkey self-signature apply to the subkey. Lastly, subpackets on the subkey self-signature apply to the subkey. Lastly, subpackets on
the direct-key signature apply to the entire key. the direct-key signature apply to the entire key.
Implementing software should interpret a self-signature's preference Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two usernames, Alice and Bob. Suppose that Alice prefers the two usernames, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the
software locates this key via Alice's name, then the preferred software locates this key via Alice's name, then the preferred
algorithm is CAST5, if software locates the key via Bob's name, then algorithm is CAST5, if software locates the key via Bob's name, then
the preferred algorithm is IDEA. If the key is located by key id, the preferred algorithm is IDEA. If the key is located by key ID,
the algorithm of the primary User ID of the key provides the default the algorithm of the primary User ID of the key provides the default
symmetric algorithm. symmetric algorithm.
Revoking a self-signature or allowing it to expire has a semantic Revoking a self-signature or allowing it to expire has a semantic
meaning that varies with the signature type. Revoking the meaning that varies with the signature type. Revoking the
self-signature on a User ID effectively retires that user name. The self-signature on a User ID effectively retires that user name. The
self-signature is a statement, "My name X is tied to my signing key self-signature is a statement, "My name X is tied to my signing key
K" and is corroborated by other users' certifications. If another K" and is corroborated by other users' certifications. If another
user revokes their certification, they are effectively saying that user revokes their certification, they are effectively saying that
they no longer believe that name and that key are tied together. they no longer believe that name and that key are tied together.
skipping to change at page 33, line 12 skipping to change at page 33, line 9
revocation signatures. It describes the reason why the key or revocation signatures. It describes the reason why the key or
certificate was revoked. certificate was revoked.
The first octet contains a machine-readable code that denotes the The first octet contains a machine-readable code that denotes the
reason for the revocation: reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations) 0x00 - No reason specified (key revocations or cert revocations)
0x01 - Key is superceded (key revocations) 0x01 - Key is superceded (key revocations)
0x02 - Key material has been compromised (key revocations) 0x02 - Key material has been compromised (key revocations)
0x03 - Key is retired and no longer used (key revocations) 0x03 - Key is retired and no longer used (key revocations)
0x20 - User Id information is no longer valid (cert revocations) 0x20 - User ID information is no longer valid (cert revocations)
Following the revocation code is a string of octets which gives Following the revocation code is a string of octets which gives
information about the reason for revocation in human-readable form information about the reason for revocation in human-readable form
(UTF-8). The string may be null, that is, of zero length. The length (UTF-8). The string may be null, that is, of zero length. The length
of the subpacket is the length of the reason string plus one. of the subpacket is the length of the reason string plus one.
An implementation SHOULD implement this subpacket, include it in all An implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
skipping to change at page 39, line 13 skipping to change at page 38, line 55
- A series of multiprecision integers comprising the key material: - A series of multiprecision integers comprising the key material:
- a multiprecision integer (MPI) of RSA public modulus n; - a multiprecision integer (MPI) of RSA public modulus n;
- an MPI of RSA public encryption exponent e. - an MPI of RSA public encryption exponent e.
V3 keys are deprecated. They contain three weaknesses in them. V3 keys are deprecated. They contain three weaknesses in them.
First, it is relatively easy to construct a V3 key that has the same First, it is relatively easy to construct a V3 key that has the same
key ID as any other key because the key ID is simply the low 64 bits key ID as any other key because the key ID is simply the low 64 bits
of the public modulus. Secondly, because the fingerprint of a V3 key of the public modulus. Secondly, because the fingerprint of a V3 key
hashes the key material, but not its length, which increases the hashes the key material, but not its length, there is an increased
opportunity for fingerprint collisions. Third, there are minor opportunity for fingerprint collisions. Third, there are minor
weaknesses in the MD5 hash algorithm that make developers prefer weaknesses in the MD5 hash algorithm that make developers prefer
other algorithms. See below for a fuller discussion of key IDs and other algorithms. See below for a fuller discussion of key IDs and
fingerprints. fingerprints.
The version 4 format is similar to the version 3 format except for The version 4 format is similar to the version 3 format except for
the absence of a validity period. This has been moved to the the absence of a validity period. This has been moved to the
signature packet. In addition, fingerprints of version 4 keys are signature packet. In addition, fingerprints of version 4 keys are
calculated differently from version 3 keys, as described in section calculated differently from version 3 keys, as described in section
"Enhanced Key Formats." "Enhanced Key Formats."
skipping to change at page 41, line 22 skipping to change at page 41, line 10
- MPI of DSA secret exponent x. - MPI of DSA secret exponent x.
Algorithm Specific Fields for Elgamal secret keys: Algorithm Specific Fields for Elgamal secret keys:
- MPI of Elgamal secret exponent x. - MPI of Elgamal secret exponent x.
Secret MPI values can be encrypted using a passphrase. If a Secret MPI values can be encrypted using a passphrase. If a
string-to-key specifier is given, that describes the algorithm for string-to-key specifier is given, that describes the algorithm for
converting the passphrase to a key, else a simple MD5 hash of the converting the passphrase to a key, else a simple MD5 hash of the
passphrase is used. Implementations SHOULD use a string-to-key passphrase is used. Implementations MUST use a string-to-key
specifier; the simple hash is for backward compatibility. The cipher specifier; the simple hash is for backward compatibility and is
for encrypting the MPIs is specified in the secret key packet. deprecated, though implementations MAY continue to use existing
private keys in the old format. The cipher for encrypting the MPIs
is specified in the secret key packet.
Encryption/decryption of the secret data is done in CFB mode using Encryption/decryption of the secret data is done in CFB mode using
the key created from the passphrase and the Initial Vector from the the key created from the passphrase and the Initial Vector from the
packet. A different mode is used with V3 keys (which are only RSA) packet. A different mode is used with V3 keys (which are only RSA)
than with other key formats. With V3 keys, the MPI bit count prefix than with other key formats. With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI (i.e., the first two octets) is not encrypted. Only the MPI
non-prefix data is encrypted. Furthermore, the CFB state is non-prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the resynchronized at the beginning of each new MPI value, so that the
CFB block boundary is aligned with the start of the MPI data. CFB block boundary is aligned with the start of the MPI data.
skipping to change at page 42, line 42 skipping to change at page 42, line 32
- Encrypted data, the output of the selected symmetric-key cipher - Encrypted data, the output of the selected symmetric-key cipher
operating in PGP's variant of Cipher Feedback (CFB) mode. operating in PGP's variant of Cipher Feedback (CFB) mode.
The symmetric cipher used may be specified in an Public-Key or The symmetric cipher used may be specified in an Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the Symmetric-Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted Data Packet. In that case, the cipher Symmetrically Encrypted Data Packet. In that case, the cipher
algorithm octet is prefixed to the session key before it is algorithm octet is prefixed to the session key before it is
encrypted. If no packets of these types precede the encrypted data, encrypted. If no packets of these types precede the encrypted data,
the IDEA algorithm is used with the session key calculated as the the IDEA algorithm is used with the session key calculated as the
MD5 hash of the passphrase. MD5 hash of the passphrase, though this use is deprecated.
The data is encrypted in CFB mode, with a CFB shift size equal to 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 the cipher's block size. The Initial Vector (IV) is specified as
all zeros. Instead of using an IV, OpenPGP prefixes a string of all zeros. Instead of using an IV, OpenPGP prefixes a string of
length equal to the block size of the cipher plus two to the data length equal to the block size of the cipher plus two to the data
before it is encrypted. The first block-size octets (for example, 8 before it is encrypted. The first block-size octets (for example, 8
octets for a 64-bit block length) are random, and the following two octets for a 64-bit block length) are random, and the following two
octets are copies of the last two octets of the IV. For example, in octets are copies of the last two octets of the IV. For example, in
an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is a an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is a
repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of
skipping to change at page 46, line 7 skipping to change at page 45, line 53
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
The Symmetrically Encrypted Integrity Protected Data Packet is a The Symmetrically Encrypted Integrity Protected Data Packet is a
variant of the Symmetrically Encrypted Data Packet. It is a new variant of the Symmetrically Encrypted Data Packet. It is a new
feature created for OpenPGP that addresses the problem of detecting feature created for OpenPGP that addresses the problem of detecting
a modification to encrypted data. It is used in combination with a a modification to encrypted data. It is used in combination with a
Modification Detection Code Packet. Modification Detection Code Packet.
There is a corresponding feature in the features signature subpacket There is a corresponding feature in the features signature subpacket
that denotes that an implementation can properly use this packet that denotes that an implementation can properly use this packet
type. An implementation SHOULD prefer this to the older type. An implementation MUST support decrypting these packets and
Symmetrically Encrypted Data Packet when possible. Since this data SHOULD prefer generating them to the older Symmetrically Encrypted
packet protects against modification attacks, this standard Data Packet when possible. Since this data packet protects against
encourages its proliferation. While blanket adoption of this data modification attacks, this standard encourages its proliferation.
packet would create interoperability problems, rapid adoption is While blanket adoption of this data packet would create
nevertheless important. An implementation SHOULD specifically denote interoperability problems, rapid adoption is nevertheless important.
support for this packet, but it MAY infer it from other mechanisms. An implementation SHOULD specifically denote support for this
packet, but it MAY infer it from other mechanisms.
For example, an implementation might infer from the use of a cipher For example, an implementation might infer from the use of a cipher
such as AES or Twofish that a user supports this feature. It might such as AES or Twofish that a user supports this feature. It might
place in the unhashed portion of another user's key signature a place in the unhashed portion of another user's key signature a
features subpacket. It might also present a user with an opportunity features subpacket. It might also present a user with an opportunity
to regenerate their own self-signature with a features subpacket. to regenerate their own self-signature with a features subpacket.
This packet contains data encrypted with a symmetric-key algorithm This packet contains data encrypted with a symmetric-key algorithm
and protected against modification by the SHA-1 hash algorithm. When and protected against modification by the SHA-1 hash algorithm. When
it has been decrypted, it will typically contain other packets it has been decrypted, it will typically contain other packets
skipping to change at page 46, line 55 skipping to change at page 46, line 50
all zeros. Instead of using an IV, OpenPGP prefixes an octet string 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 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 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 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 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 preceding octet. For example, with a cipher whose block size is 128
bits or 16 octets, the prefix data will contain 16 random octets, 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, then two more octets, which are copies of the 15th and 16th octets,
respectively. Unlike the Symmetrically Encrypted Data Packet, no respectively. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix special CFB resynchronization is done after encrypting this prefix
data. data. See OpenPGP CFB Mode below for more details.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
The plaintext of the data to be encrypted is passed through the 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 SHA-1 hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. The input to the plaintext in a Modification Detection Code packet. The input to the
hash function includes the prefix data described above; it includes hash function includes the prefix data described above; it includes
all of the plaintext, and then also includes two octets of values all of the plaintext, and then also includes two octets of values
skipping to change at page 47, line 29 skipping to change at page 47, line 25
its tag and length field. The body of the MDC packet is the 20 its tag and length field. The body of the MDC packet is the 20
octet output of the SHA-1 hash. octet output of the SHA-1 hash.
The Modification Detection Code packet is appended to the plaintext The Modification Detection Code packet is appended to the plaintext
and encrypted along with the plaintext using the same CFB context. and encrypted along with the plaintext using the same CFB context.
During decryption, the plaintext data should be hashed with SHA-1, During decryption, the plaintext data should be hashed with SHA-1,
including the prefix data as well as the packet tag and length field including the prefix data as well as the packet tag and length field
of the Modification Detection Code packet. The body of the MDC of the Modification Detection Code packet. The body of the MDC
packet, upon decryption, is compared with the result of the SHA-1 packet, upon decryption, is compared with the result of the SHA-1
hash. Any difference in hash values is an indication that the hash.
message has been modified and SHOULD be reported to the user.
Likewise, the absence of an MDC packet, or an MDC packet in any Any failure of the MDC indicates that the message has been modified
position other than the end of the plaintext, also represent message and MUST be treated as a security problem. Failures include a
modifications and SHOULD also be reported. difference in the hash values, but also the absence of an MDC
packet, or an MDC packet in any position other than the end of the
plaintext. Any failure SHOULD be reported to the user.
Note: future designs of new versions of this packet should consider Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change rollback attacks since it will be possible for an attacker to change
the version back to 1. the version back to 1.
5.14. Modification Detection Code Packet (Tag 19) 5.14. Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
plaintext data which is used to detect message modification. It is plaintext data which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
skipping to change at page 50, line 39 skipping to change at page 50, line 39
signatures applied to the message. signatures applied to the message.
The format of an Armor Header is that of a key-value pair. A colon The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value. (':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message. the user, but OpenPGP should continue to process the message.
Currently defined Armor Header Keys are: Currently defined Armor Header Keys are:
- "Version", that states the OpenPGP Version used to encode the - "Version", that states the OpenPGP implementation and version
message. used to encode the message.
- "Comment", a user-defined comment. OpenPGP defines all text to - "Comment", a user-defined comment. OpenPGP defines all text to
be in UTF-8. A comment may be any UTF-8 string. However, the be in UTF-8. A comment may be any UTF-8 string. However, the
whole point of armoring is to provide seven-bit-clean data. whole point of armoring is to provide seven-bit-clean data.
Consequently, if a comment has characters that are outside the Consequently, if a comment has characters that are outside the
US-ASCII range of UTF, they may very well not survive transport. US-ASCII range of UTF, they may very well not survive transport.
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should
skipping to change at page 51, line 30 skipping to change at page 51, line 30
said than done. Also, there are communities of users who have no said than done. Also, there are communities of users who have no
need for UTF-8 because they are all happy with a character set need for UTF-8 because they are all happy with a character set
like ISO Latin-5 or a Japanese character set. In such instances, like ISO Latin-5 or a Japanese character set. In such instances,
an implementation MAY override the UTF-8 default by using this an implementation MAY override the UTF-8 default by using this
header key. An implementation MAY implement this key and any header key. An implementation MAY implement this key and any
translations it cares to; an implementation MAY ignore it and translations it cares to; an implementation MAY ignore it and
assume all text is UTF-8. assume all text is UTF-8.
The Armor Tail Line is composed in the same manner as the Armor The Armor Tail Line is composed in the same manner as the Armor
Header Line, except the string "BEGIN" is replaced by the string Header Line, except the string "BEGIN" is replaced by the string
"END." "END".
6.3. Encoding Binary in Radix-64 6.3. Encoding Binary in Radix-64
The encoding process represents 24-bit groups of input bits as The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to output strings of 4 encoded characters. Proceeding from left to
right, a 24-bit input group is formed by concatenating three 8-bit right, a 24-bit input group is formed by concatenating three 8-bit
input groups. These 24 bits are then treated as four concatenated input groups. These 24 bits are then treated as four concatenated
6-bit groups, each of which is translated into a single digit in the 6-bit groups, each of which is translated into a single digit in the
Radix-64 alphabet. When encoding a bit stream with the Radix-64 Radix-64 alphabet. When encoding a bit stream with the Radix-64
encoding, the bit stream must be presumed to be ordered with the encoding, the bit stream must be presumed to be ordered with the
skipping to change at page 55, line 5 skipping to change at page 55, line 5
is calculated on the text using canonical <CR><LF> line endings. is calculated on the text using canonical <CR><LF> line endings.
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text. considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the When reversing dash-escaping, an implementation MUST strip the
string "- " if it occurs at the beginning of a line, and SHOULD warn string "- " if it occurs at the beginning of a line, and SHOULD warn
on "-" and any character other than a space at the beginning of a on "-" and any character other than a space at the beginning of a
line. line.
Also, any trailing whitespace -- spaces (0x020) and tabs (0x09) -- Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
at the end of any line is removed when the cleartext signature is the end of any line is removed when the cleartext signature is
generated. generated.
8. Regular Expressions 8. Regular Expressions
A regular expression is zero or more branches, separated by '|'. It A regular expression is zero or more branches, separated by '|'. It
matches anything that matches one of the branches. matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match A branch is zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc. for the first, followed by a match for the second, etc.
skipping to change at page 60, line 12 skipping to change at page 60, line 12
The format of an OpenPGP V3 key is as follows. Entries in square The format of an OpenPGP V3 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition. brackets are optional and ellipses indicate repetition.
RSA Public Key RSA Public Key
[Revocation Self Signature] [Revocation Self Signature]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding User Each signature certifies the RSA public key and the preceding User
ID. The RSA public key can have many User IDs and each User ID can ID. The RSA public key can have many User IDs and each User ID can
have many signatures. have many signatures. V3 keys are deprecated. Implementations MUST
NOT generate new V3 keys, but MAY continue to use existing ones.
The format of an OpenPGP V4 key that uses two public keys is similar The format of an OpenPGP V4 key that uses multiple public keys is
except that the other keys are added to the end as 'subkeys' of the similar except that the other keys are added to the end as "subkeys"
primary key. of the primary key.
Primary-Key Primary-Key
[Revocation Self Signature] [Revocation Self Signature]
[Direct Key Signature...] [Direct Key Signature...]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
[User Attribute [Signature ...] ...] [User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...] Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. This binding the primary key to tie the two keys together. This binding
signature may be in either V3 or V4 format, but SHOULD be V4. signature may be in either V3 or V4 format, but SHOULD be V4.
In the above diagram, if the binding signature of a subkey has been In the above diagram, if the binding signature of a subkey has been
revoked, the revoked key may be removed, leaving only one key. revoked, the revoked key may be removed, leaving only one key.
In a key that has a main key and subkeys, the primary key MUST be a In a V4 key, the primary key MUST be a key capable of certification.
key capable of certification. The subkeys may be keys of any other The subkeys may be keys of any other type. There may be other
type. There may be other constructions of V4 keys, too. For example, constructions of V4 keys, too. For example, there may be a
there may be a single-key RSA key in V4 format, a DSA primary key single-key RSA key in V4 format, a DSA primary key with an RSA
with an RSA encryption key, or RSA primary key with an Elgamal encryption key, or RSA primary key with an Elgamal subkey, etc.
subkey, etc.
It is also possible to have a signature-only subkey. This permits a It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures) but is primary key that collects certifications (key signatures) but is
used only used for certifying subkeys that are used for encryption used only used for certifying subkeys that are used for encryption
and signatures. and signatures.
11.2. Key IDs and Fingerprints 11.2. Key IDs and Fingerprints
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. modulus n, followed by exponent e) with MD5. Note that both V3 keys
and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire followed by the two-octet packet length, followed by the entire
Public Key packet starting with the version field. The key ID is Public Key packet starting with the version field. The key ID is
the low order 64 bits of the fingerprint. Here are the fields of the low order 64 bits of the fingerprint. Here are the fields of
the hash material, with the example of a DSA key: the hash material, with the example of a DSA key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) high order length octet of (b)-(f) (1 octet) a.2) high order length octet of (b)-(f) (1 octet)
skipping to change at page 61, line 41 skipping to change at page 61, line 41
e.3) MPI of DSA group generator g; e.3) MPI of DSA group generator g;
e.4) MPI of DSA public key value y (= g**x mod p where x is secret). e.4) MPI of DSA public key value y (= g**x mod p where x is secret).
Note that it is possible for there to be collisions of key IDs -- Note that it is possible for there to be collisions of key IDs --
two different keys with the same key ID. Note that there is a much two different keys with the same key ID. Note that there is a much
smaller, but still non-zero probability that two different keys have smaller, but still non-zero probability that two different keys have
the same fingerprint. the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key Also note that if V3 and V4 format keys share the same RSA key
material, they will have different key ids as well as different material, they will have different key IDs as well as different
fingerprints. fingerprints.
Finally, the key ID and fingerprint of a subkey are calculated in Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first the same way as for a primary key, including the 0x99 as the first
octet (even though this is not a valid packet ID for a public octet (even though this is not a valid packet ID for a public
subkey). subkey).
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. Symmetric Algorithm Preferences
skipping to change at page 62, line 32 skipping to change at page 62, line 32
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has message anyway, but MUST warn the keyholder that the protocol has
been violated. (For example, suppose that Alice, above, has software been violated. (For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless, that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEA-encrypted message, but it warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway.) would ideally decrypt it anyway.)
An implementation that is striving for backward compatibility MAY
consider a V3 key with a V3 self-signature to be an implicit
preference for IDEA, and no ability to do TripleDES. This is
technically non-compliant, but an implementation MAY violate the
above rule in this case only and use IDEA to encrypt the message,
provided that the message creator is warned. Ideally, though, the
implementation would follow the rule by actually generating two
messages, because it is possible that the OpenPGP user's
implementation does not have IDEA, and thus could not read the
message. Consequently, an implementation MAY, but SHOULD NOT use
IDEA in an algorithm conflict with a V3 key.
12.2. Other Algorithm Preferences 12.2. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
12.2.1. Compression Preferences 12.2.1. Compression Preferences
skipping to change at page 64, line 6 skipping to change at page 63, line 45
12.4. RSA 12.4. RSA
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA-signature-only, and
RSA-encrypt-only keys. These types are deprecated. The "key flags" RSA-encrypt-only keys. These types are deprecated. The "key flags"
subpacket in a signature is a much better way to express the same subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it. NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
768 bits. 1024 bits.
It is permissible for an implementation to support RSA merely for
backward compatibility; for example, such an implementation would
support V3 keys with IDEA symmetric cryptography. Note that this is
an exception to the other MUST-implement rules. An implementation
that supports RSA in V4 keys MUST implement the MUST-implement
features.
12.5. DSA 12.5. DSA
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 1024 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.6. Reserved Algorithm Numbers 12.6. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less
than 1024 bits.
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 implementer 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.
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public key identifier of 20. These are no longer permitted. with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. MUST NOT generate Elgamal signatures.
12.7. 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
and Twofish have a block size of 16 octets. Also note that the and Twofish have a block size of 16 octets. Also note that the
skipping to change at page 66, line 5 skipping to change at page 65, line 45
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 * As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here the current literature to determine if any algorithms used here
have 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. It
Possession of the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is assumed to be controlled by the proper party or parties. pair is controlled and secured by the proper party or parties.
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
random numbers. An appropriate entropy source should be used to random numbers. An appropriate entropy source should be used to
generate 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, with
(pseudo-collisions in the compress function) that make some collisions found in a number of cases. MD5 is deprecated for use
people deprecate its use. They consider the SHA-1 algorithm in OpenPGP. Implementations MUST NOT generate new signatures
better. using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid.
* SHA384 requires the same work as SHA512. In general, there are * SHA384 requires the same work as SHA512. In general, there are
few reasons to use it -- you need a situation where one needs few reasons to use it -- you need a situation where one needs
more security than SHA256, but do not want to have the 512-bit more security than SHA256, but do not want to have the 512-bit
data length. data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use 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 (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be 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. RIPEMD-160 is considered by many cryptographers to be as strong.
An implementation should take care which hash algorithms are An implementation should take care which hash algorithms are
used with DSA, as a weak hash can not only allow a signature to used with DSA, as a weak hash can not only allow a signature to
be forged, but could leak the secret key. These same be forged, but could leak the secret key.
considerations about the quality of the hash algorithm apply to
Elgamal signatures.
* There is a somewhat-related potential security problem in * There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature same hash with a different algorithm, a bogus signature
structure can be constructed that evaluates correctly. structure can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash For example, suppose Alice DSA signs message M using hash
algorithm H. Suppose that Mallet finds a message M' that has the algorithm H. Suppose that Mallet finds a message M' that has the
same hash value as M with H'. Mallet can then construct a same hash value as M with H'. Mallet can then construct a
signature block that verifies as Alice's signature of M' with signature block that verifies as Alice's signature of M' with
skipping to change at page 68, line 6 skipping to change at page 67, line 42
1. Implementers treat MDC errors and decompression failures as 1. Implementers treat MDC errors and decompression failures as
security problems. security problems.
2. Implementers implement Modification Detection with all due 2. Implementers implement Modification Detection with all due
speed and encourage its spread. speed and encourage its spread.
3. Users migrate to implementations that support Modification 3. Users migrate to implementations that support Modification
Detection with all due speed. Detection with all due speed.
* PKCS1 has been found to be vulnerable to attacks in which a * PKCS1 has been found to be vulnerable to attacks in which a
system reports that errors in padding differently from errors in system that reports errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution this attack and prevent it from happening. The simplest solution
is report a single error code for all variants of decryption is report a single error code for all variants of decryption
errors so as not to leak information to an attacker. errors so as not to leak information to an attacker.
* 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
skipping to change at page 68, line 46 skipping to change at page 68, line 30
identical to the deprecated V3 keys except for the version identical to the deprecated V3 keys except for the version
number. An implementation MUST NOT generate them and may accept number. An implementation MUST NOT generate them and may accept
or reject them as it sees fit. Similarly, these versions or reject them as it sees fit. Similarly, these versions
generated V2 PKESK packets (Tag 1). An implementation may accept generated V2 PKESK packets (Tag 1). An implementation may accept
or reject V2 PKESK packets as it sees fit, and MUST NOT generate or reject V2 PKESK packets as it sees fit, and MUST NOT generate
them. them.
* PGP 2.6.x will not accept key-material packets with versions * PGP 2.6.x will not accept key-material packets with versions
greater than 3. greater than 3.
* Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign
keys. They only handle Elgamal Encrypt-only keys.
* There are many ways possible for two keys to have the same key * There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus key ids). Perhaps material, but different fingerprints (and thus key IDs). Perhaps
the most interesting is an RSA key that has been "upgraded" to the most interesting is an RSA key that has been "upgraded" to
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will created at different times, yet with the same key material will
have different fingerprints. have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* PGP 2.6.X and 5.0 do not trim trailing whitespace from a * PGP 2.6.X and 5.0 do not trim trailing whitespace from a
 End of changes. 

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