rfc9580v6.txt   rfc9580.txt 
skipping to change at line 234 skipping to change at line 234
5.7. Symmetrically Encrypted Data Packet (Type ID 9) 5.7. Symmetrically Encrypted Data Packet (Type ID 9)
5.8. Marker Packet (Type ID 10) 5.8. Marker Packet (Type ID 10)
5.9. Literal Data Packet (Type ID 11) 5.9. Literal Data Packet (Type ID 11)
5.9.1. Special Filename _CONSOLE (Deprecated) 5.9.1. Special Filename _CONSOLE (Deprecated)
5.10. Trust Packet (Type ID 12) 5.10. Trust Packet (Type ID 12)
5.11. User ID Packet (Type ID 13) 5.11. User ID Packet (Type ID 13)
5.12. User Attribute Packet (Type ID 17) 5.12. User Attribute Packet (Type ID 17)
5.12.1. Image Attribute Subpacket 5.12.1. Image Attribute Subpacket
5.13. Symmetrically Encrypted and Integrity Protected Data Packet 5.13. Symmetrically Encrypted and Integrity Protected Data Packet
(Type ID 18) (Type ID 18)
5.13.1. Symmetrically Encrypted and Integrity Protected Data 5.13.1. Version 1 Symmetrically Encrypted and Integrity
Packet Version 1 Format Protected Data Packet Format
5.13.2. Symmetrically Encrypted and Integrity Protected Data 5.13.2. Version 2 Symmetrically Encrypted and Integrity
Packet Version 2 Format Protected Data Packet Format
5.13.3. EAX Mode 5.13.3. EAX Mode
5.13.4. OCB Mode 5.13.4. OCB Mode
5.13.5. GCM Mode 5.13.5. GCM Mode
5.14. Padding Packet (Type ID 21) 5.14. Padding Packet (Type ID 21)
6. Base64 Conversions 6. Base64 Conversions
6.1. Optional Checksum 6.1. Optional Checksum
6.1.1. An Implementation of the CRC24 in "C" 6.1.1. An Implementation of the CRC24 in "C"
6.2. Forming ASCII Armor 6.2. Forming ASCII Armor
6.2.1. Armor Header Line 6.2.1. Armor Header Line
6.2.2. Armor Headers 6.2.2. Armor Headers
skipping to change at line 327 skipping to change at line 327
13.6. Fingerprint Usability 13.6. Fingerprint Usability
13.7. Avoiding Ciphertext Malleability 13.7. Avoiding Ciphertext Malleability
13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature 13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature
13.9. Escrowed Revocation Signatures 13.9. Escrowed Revocation Signatures
13.10. Random Number Generation and Seeding 13.10. Random Number Generation and Seeding
13.11. Traffic Analysis 13.11. Traffic Analysis
13.12. Surreptitious Forwarding 13.12. Surreptitious Forwarding
13.13. Hashed vs. Unhashed Subpackets 13.13. Hashed vs. Unhashed Subpackets
13.14. Malicious Compressed Data 13.14. Malicious Compressed Data
14. Implementation Considerations 14. Implementation Considerations
14.1. Constrained Legacy Fingerprint Storage for v6 Keys 14.1. Constrained Legacy Fingerprint Storage for Version 6 Keys
15. IANA Considerations 15. IANA Considerations
15.1. Renamed Protocol Group 15.1. Renamed Protocol Group
15.2. Renamed and Updated Registries 15.2. Renamed and Updated Registries
15.3. Removed Registry 15.3. Removed Registry
15.4. Added Registries 15.4. Added Registries
15.5. Registration Policies 15.5. Registration Policies
15.5.1. Registries That Use RFC Required 15.5.1. Registries That Use RFC Required
15.6. Designated Experts 15.6. Designated Experts
15.6.1. Key and Signature Versions 15.6.1. Key and Signature Versions
15.6.2. Encryption Versions 15.6.2. Encryption Versions
skipping to change at line 381 skipping to change at line 381
A.10.3. Sample v2 SEIPD Packet A.10.3. Sample v2 SEIPD Packet
A.10.4. Decryption of Data A.10.4. Decryption of Data
A.10.5. Complete AEAD-OCB Encrypted Packet Sequence A.10.5. Complete AEAD-OCB Encrypted Packet Sequence
A.11. Sample AEAD-GCM Encryption and Decryption A.11. Sample AEAD-GCM Encryption and Decryption
A.11.1. Sample Symmetric Key Encrypted Session Key Packet (v6) A.11.1. Sample Symmetric Key Encrypted Session Key Packet (v6)
A.11.2. Starting AEAD-GCM Decryption of the Session Key A.11.2. Starting AEAD-GCM Decryption of the Session Key
A.11.3. Sample v2 SEIPD Packet A.11.3. Sample v2 SEIPD Packet
A.11.4. Decryption of Data A.11.4. Decryption of Data
A.11.5. Complete AEAD-GCM Encrypted Packet Sequence A.11.5. Complete AEAD-GCM Encrypted Packet Sequence
A.12. Sample Messages Encrypted Using Argon2 A.12. Sample Messages Encrypted Using Argon2
A.12.1. Version 4 SKESK Using Argon2 with AES-128 A.12.1. v4 SKESK Using Argon2 with AES-128
A.12.2. Version 4 SKESK Using Argon2 with AES-192 A.12.2. v4 SKESK Using Argon2 with AES-192
A.12.3. Version 4 SKESK Using Argon2 with AES-256 A.12.3. v4 SKESK Using Argon2 with AES-256
Appendix B. Upgrade Guidance (Adapting Implementations from RFCs Appendix B. Upgrade Guidance (Adapting Implementations from RFCs
4880 and 6637) 4880 and 6637)
B.1. Terminology Changes B.1. Terminology Changes
Appendix C. Errata Addressed by This Document Appendix C. Errata Addressed by This Document
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
skipping to change at line 479 skipping to change at line 479
Both digital signature and confidentiality services may be applied to Both digital signature and confidentiality services may be applied to
the same message. First, a signature is generated for the message the same message. First, a signature is generated for the message
and attached to the message. Then, the message plus signature is and attached to the message. Then, the message plus signature is
encrypted using a symmetric message key derived from the session key. encrypted using a symmetric message key derived from the session key.
Finally, the session key is encrypted using public key encryption and Finally, the session key is encrypted using public key encryption and
prefixed to the encrypted block. prefixed to the encrypted block.
2.2. Authentication via Digital Signature 2.2. Authentication via Digital Signature
The digital signature uses a cryptographic hash function and a public The digital signature uses a cryptographic hash function and a public
key signature algorithm. The sequence is as follows: key algorithm capable of signing. The sequence is as follows:
1. The sender creates a message. 1. The sender creates a message.
2. The sending implementation generates a hash digest of the 2. The sending implementation generates a hash digest of the
message. message.
3. The sending implementation generates a signature from the hash 3. The sending implementation generates a signature from the hash
digest using the sender's private key. digest using the sender's private key.
4. The signature is attached to or transmitted alongside the 4. The signature is attached to or transmitted alongside the
skipping to change at line 572 skipping to change at line 572
The string [00 09 01 FF] forms an MPI with the value 511. The string [00 09 01 FF] forms an MPI with the value 511.
Additional rules: Additional rules:
* The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. * The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
* The length field of an MPI describes the length starting from its * The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01]. When parsing an MPI formed correctly. It should be [00 01 01]. When parsing an MPI
in a v6 Key, Signature, or Public Key Encrypted Session Key in a version 6 Key, Signature, or Public Key Encrypted Session Key
(PKESK) packet, the implementation MUST check that the encoded (PKESK) packet, the implementation MUST check that the encoded
length matches the length starting from the most significant non- length matches the length starting from the most significant non-
zero bit; if it doesn't match, reject the packet as malformed. zero bit; if it doesn't match, reject the packet as malformed.
* Unused bits of an MPI MUST be zero. * Unused bits of an MPI MUST be zero.
3.2.1. Using MPIs to Encode Other Data 3.2.1. Using MPIs to Encode Other Data
Note that in some places, MPIs are used to encode non-integer data, Note that in some places, MPIs are used to encode non-integer data,
such as an elliptic curve (EC) point (see Section 11.2) or an octet such as an elliptic curve (EC) point (see Section 11.2) or an octet
string of known, fixed length (see Section 11.3). The wire string of known, fixed length (see Section 11.3). The wire
representation is the same: 2 octets of length in bits counted from representation is the same: 2 octets of length in bits counted from
the first non-zero bit, followed by the smallest series of octets the first non-zero bit, followed by the smallest series of octets
that can represent the value while stripping off any leading zero that can represent the value while stripping off any leading zero
octets. octets.
3.3. Key IDs and Fingerprints 3.3. Key IDs and Fingerprints
A Key ID is an 8-octet scalar that identifies a key. Implementations A Key ID is an 8-octet scalar that identifies a key. Implementations
SHOULD NOT assume that Key IDs are unique. A fingerprint is more SHOULD NOT assume that Key IDs are unique. A fingerprint is more
likely to be unique than a key ID. The fingerprint and key ID of a likely to be unique than a Key ID. The fingerprint and Key ID of a
key are calculated differently according to the version of the key. key are calculated differently according to the version of the key.
Section 5.5.4 describes how Key IDs and Fingerprints are formed. Section 5.5.4 describes how Key IDs and Fingerprints are formed.
3.4. Text 3.4. Text
Unless otherwise specified, the character set for text is the UTF-8 Unless otherwise specified, the character set for text is the UTF-8
[RFC3629] encoding of Unicode [ISO10646]. [RFC3629] encoding of Unicode [ISO10646].
3.5. Time Fields 3.5. Time Fields
skipping to change at line 617 skipping to change at line 617
3.6. Keyrings 3.6. Keyrings
A keyring is a collection of one or more keys in a file or database. A keyring is a collection of one or more keys in a file or database.
Typically, a keyring is simply a sequential list of keys, but it may Typically, a keyring is simply a sequential list of keys, but it may
be any suitable database. It is beyond the scope of this be any suitable database. It is beyond the scope of this
specification to discuss the details of keyrings or other databases. specification to discuss the details of keyrings or other databases.
3.7. String-to-Key (S2K) Specifier 3.7. String-to-Key (S2K) Specifier
A string-to-key (S2K) specifier type is used to convert a passphrase A string-to-key (S2K) Specifier Type is used to convert a passphrase
string into a symmetric key encryption/decryption key. Passphrases string into a symmetric key encryption/decryption key. Passphrases
requiring use of S2K conversion are currently used in two places: to requiring use of S2K conversion are currently used in two places: to
encrypt the secret part of private keys and for symmetrically encrypt the secret part of private keys and for symmetrically
encrypted messages. encrypted messages.
3.7.1. S2K Specifier Types 3.7.1. S2K Specifier Types
There are four types of S2K Specifier Types currently specified and There are four types of S2K Specifier Types currently specified and
some reserved values: some reserved values:
skipping to change at line 692 skipping to change at line 692
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 a different hash output. Once the passphrase is will each produce a 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, and any excess octets first hash leftmost, to produce the key data, and any excess octets
on the right are discarded. on the right are discarded.
3.7.1.2. Salted S2K 3.7.1.2. Salted S2K
Salted S2K includes a "salt" value in the S2K Specifier Type -- some Salted S2K includes a "salt" value in the S2K Specifier -- some
arbitrary data -- that gets hashed along with the passphrase string arbitrary data -- that gets hashed along with the passphrase string
to help prevent dictionary attacks. to help 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 Type, followed by the passphrase. Specifier, followed by the passphrase.
3.7.1.3. Iterated and Salted S2K 3.7.1.3. Iterated and Salted S2K
Iterated and Salted S2K includes both a salt and an octet count. The Iterated and Salted S2K includes both a salt and an octet count. The
salt is combined with the passphrase, and the resulting value is salt is combined with the passphrase, and the resulting value is
repeated and then hashed. This further increases the amount of work repeated and then hashed. This further increases the amount of work
an attacker must do to try dictionary attacks. an attacker must do to try dictionary attacks.
Octet 0: 0x03 Octet 0: 0x03
Octet 1: hash algorithm Octet 1: hash algorithm
skipping to change at line 726 skipping to change at line 726
The count is coded into a 1-octet number using the following formula: The count is coded into a 1-octet number using the following formula:
#define EXPBIAS 6 #define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
The above formula is described in [C99], where "Int32" is a type for The above formula is described in [C99], where "Int32" is a type for
a 32-bit integer, and the variable "c" is the coded count, octet 10. a 32-bit integer, and the variable "c" is the coded count, octet 10.
Iterated and Salted S2K hashes the passphrase and salt data multiple Iterated and Salted S2K hashes the passphrase and salt data multiple
times. The total number of octets to be hashed is specified in the times. The total number of octets to be hashed is specified in the
encoded count in the S2K Specifier Type. Note that the resulting encoded count in the S2K Specifier. Note that the resulting count
count value is an octet count of how many octets will be hashed, not value is an octet count of how many octets will be hashed, not an
an iteration count. iteration count.
Initially, one or more hash contexts are set up the same as the other Initially, one or more hash contexts are set up the same as 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 Then the salt, followed by the passphrase data, is repeatedly
processed as input to each hash context until the number of octets processed as input to each hash context until the number of octets
specified by the octet count has been hashed. The input is truncated specified by the octet count has been hashed. The input is truncated
to the octet count, except if the octet count is less than the to the octet count, except if the octet count is less than the
initial size of the salt plus passphrase. That is, at least one copy initial size of the salt plus passphrase. That is, at least one copy
of the full salt plus passphrase will be provided as input to each of the full salt plus passphrase will be provided as input to each
hash context regardless of the octet count. After the hashing is hash context regardless of the octet count. After the hashing is
skipping to change at line 776 skipping to change at line 776
of t, p, and m as described above, the required key size as the tag of t, p, and m as described above, the required key size as the tag
length T, 0x13 as the version v, and Argon2id as the type. length T, 0x13 as the version v, and Argon2id as the type.
For the recommended values of t, p, and m, see Section 4 of For the recommended values of t, p, and m, see Section 4 of
[RFC9106]. If the recommended value of m for a given application is [RFC9106]. If the recommended value of m for a given application is
not a power of 2, it is RECOMMENDED to round up to the next power of not a power of 2, it is RECOMMENDED to round up to the next power of
2 if the resulting performance would be acceptable; otherwise, round 2 if the resulting performance would be acceptable; otherwise, round
down (keeping in mind that m must be at least 8*p). down (keeping in mind that m must be at least 8*p).
As an example, with the first recommended option (t=1, p=4, m=2^21), As an example, with the first recommended option (t=1, p=4, m=2^21),
the full S2K Specifier Type would be: the full S2K Specifier would be:
04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX 01 04 15 XX 01 04 15
where XX represents a random octet of salt. where XX represents a random octet of salt.
3.7.2. S2K Usage 3.7.2. S2K Usage
Simple S2K and Salted S2K Specifier Types can be brute-forced when Simple S2K and Salted S2K Specifiers can be brute-forced when used
used with a low-entropy string, such as those typically provided by with a low-entropy string, such as those typically provided by users.
users. In addition, the usage of Simple S2K can lead to key and In addition, the usage of Simple S2K can lead to key and
initialization vector (IV) reuse (see Section 5.3). Therefore, when initialization vector (IV) reuse (see Section 5.3). Therefore, when
generating an S2K Specifier Type, an implementation MUST NOT use generating an S2K Specifier, an implementation MUST NOT use Simple
Simple S2K. Furthermore, an implementation SHOULD NOT generate a S2K. Furthermore, an implementation SHOULD NOT generate a Salted S2K
Salted S2K unless the implementation knows that the input string is unless the implementation knows that the input string is high entropy
high entropy (for example, it generated the string itself using a (for example, it generated the string itself using a known good
known good source of randomness). source of randomness).
It is RECOMMENDED that implementations use Argon2. If Argon2 is not It is RECOMMENDED that implementations use Argon2. If Argon2 is not
available, Iterated and Salted S2K MAY be used if care is taken to available, Iterated and Salted S2K MAY be used if care is taken to
use a high octet count and a strong passphrase. However, this method use a high octet count and a strong passphrase. However, this method
does not provide memory hardness, unlike Argon2. does not provide memory hardness, unlike Argon2.
3.7.2.1. Secret Key Encryption 3.7.2.1. Secret Key Encryption
The first octet following the public key material in a Secret Key The first octet following the public key material in a Secret Key
packet (Section 5.5.3) indicates whether and how the secret key packet (Section 5.5.3) indicates whether and how the secret key
skipping to change at line 886 skipping to change at line 886
| | |S2K- |secrets || check(secrets))| | | | |S2K- |secrets || check(secrets))| |
| | |specifier, | | | | | |specifier, | | |
| | |IV | | | | | |IV | | |
+---------+------------+------------+--------------------------+----+ +---------+------------+------------+--------------------------+----+
Table 2: OpenPGP Secret Key Encryption (S2K Usage Octet) Registry Table 2: OpenPGP Secret Key Encryption (S2K Usage Octet) Registry
When emitting a secret key (with or without passphrase protection), When emitting a secret key (with or without passphrase protection),
an implementation MUST only produce data from a row with "Generate?" an implementation MUST only produce data from a row with "Generate?"
marked as "Yes". Each row with "Generate?" marked as "No" is marked as "Yes". Each row with "Generate?" marked as "No" is
described for backward compatibility (for reading v4 and earlier keys described for backward compatibility (for reading version 4 and
only) and MUST NOT be used to generate new output. Version 6 secret earlier keys only) and MUST NOT be used to generate new output.
keys using these formats MUST be rejected. Version 6 secret keys using these formats MUST be rejected.
Note that compared to a version 4 secret key, the parameters of a Note that compared to a version 4 secret key, the parameters of a
passphrase-protected version 6 secret key are stored with an passphrase-protected version 6 secret key are stored with an
additional pair of length counts, each of which is 1 octet wide. additional pair of length counts, each of which is 1 octet wide.
Argon2 is only used with Authenticated Encryption with Associated Argon2 is only used with Authenticated Encryption with Associated
Data (AEAD) (S2K usage octet 253). An implementation MUST NOT create Data (AEAD) (S2K usage octet 253). An implementation MUST NOT create
and MUST reject as malformed any Secret Key packet where the S2K and MUST reject as malformed any Secret Key packet where the S2K
usage octet is not AEAD (253) and the S2K Specifier Type is Argon2. usage octet is not AEAD (253) and the S2K Specifier Type is Argon2.
3.7.2.2. Symmetric Key Message Encryption 3.7.2.2. Symmetric Key Message Encryption
OpenPGP can create a Symmetric Key Encrypted Session Key (SKESK) OpenPGP can create a Symmetric Key Encrypted Session Key (SKESK)
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
Specifier Types 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 SKESK packets and PKESK packets. This allows messages with a mix of SKESK packets and PKESK packets. This allows
a message to be decrypted with either a passphrase or a public key a message to be decrypted with either a passphrase or a public key
pair. pair.
Implementations predating [RFC2440] always used the International Implementations predating [RFC2440] always used the International
Data Encryption Algorithm (IDEA) with Simple S2K conversion when Data Encryption Algorithm (IDEA) with Simple S2K conversion when
encrypting a message with a symmetric algorithm; see Section 5.7. encrypting a message with a symmetric algorithm; see Section 5.7.
IDEA MUST NOT be generated but MAY be consumed for backward IDEA MUST NOT be generated but MAY be consumed for backward
compatibility. compatibility.
skipping to change at line 1479 skipping to change at line 1479
An implementation MUST generate a version 6 signature when signing An implementation MUST generate a version 6 signature when signing
with a version 6 key. An implementation MUST generate a version 4 with a version 6 key. An implementation MUST generate a version 4
signature when signing with a version 4 key. Implementations MUST signature when signing with a version 4 key. Implementations MUST
NOT create version 3 signatures; they MAY accept version 3 NOT create version 3 signatures; they MAY accept version 3
signatures. See Section 10.3.2.2 for more details about packet signatures. See Section 10.3.2.2 for more details about packet
version correspondence between keys and signatures. version correspondence between keys and signatures.
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
indicated by the signature Type ID in any given signature. Please indicated by the Signature Type ID in any given signature. Please
note that the vagueness of these meanings is not a flaw but rather a note that the vagueness of these meanings is not a flaw but rather a
feature of the system. Because OpenPGP places final authority for feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other signer's casual act might be more rigorous than some other
authority's positive act. See Section 5.2.4 for detailed information authority's positive act. See Section 5.2.4 for detailed information
on how to compute and verify signatures of each type. on how to compute and verify signatures of each type.
+======+====================================+==================+ +======+====================================+==================+
| ID | Name | Reference | | ID | Name | Reference |
+======+====================================+==================+ +======+====================================+==================+
skipping to change at line 1632 skipping to change at line 1632
or by a (deprecated) Revocation Key. The signature is computed over or by a (deprecated) Revocation Key. The signature is computed over
the same data as the certification that it revokes, and it should the same data as the certification that it revokes, and it should
have a later creation date than that certification. have a later creation date than that certification.
5.2.1.14. Timestamp Signature (Type ID 0x40) 5.2.1.14. Timestamp Signature (Type ID 0x40)
This signature is only meaningful for the timestamp contained in it. This signature is only meaningful for the timestamp contained in it.
5.2.1.15. Third-Party Confirmation Signature (Type ID 0x50) 5.2.1.15. Third-Party Confirmation Signature (Type ID 0x50)
This signature is a signature over some other OpenPGP Signature This signature is a signature over another OpenPGP Signature packet.
packet(s). It is analogous to a notary seal on the signed data. A It is analogous to a notary seal on the signed data. A Third-Party
Third-Party Confirmation signature SHOULD include one or more Confirmation signature SHOULD include a Signature Target subpacket
Signature Target subpackets to give easy identification. Note that that identifies the confirmed signature.
we really do mean SHOULD. There are plausible uses for this (such as
a blind party that only sees the signature, not the key or source
document) that cannot include a target subpacket.
5.2.1.16. Reserved (Type ID 0xFF) 5.2.1.16. Reserved (Type ID 0xFF)
An implementation MUST NOT create any signature with this type and An implementation MUST NOT create any signature with this type and
MUST NOT validate any signature made with this type. See MUST NOT validate any signature made with this type. See
Section 5.2.4.1 for more details. Section 5.2.4.1 for more details.
5.2.2. Version 3 Signature Packet Format 5.2.2. Version 3 Signature Packet Format
The body of a version 3 Signature packet contains: The body of a version 3 Signature packet contains:
* A 1-octet version number with value 3. * A 1-octet version number with value 3.
* A 1-octet length of the following hashed material; it MUST be 5: * A 1-octet length of the following hashed material; it MUST be 5:
- A 1-octet signature Type ID. - A 1-octet Signature Type ID.
- A 4-octet creation time. - A 4-octet creation time.
* An 8-octet Key ID of the signer. * An 8-octet Key ID of the signer.
* A 1-octet public key algorithm. * A 1-octet public key algorithm.
* A 1-octet hash algorithm. * A 1-octet hash algorithm.
* A 2-octet field holding left 16 bits of the signed hash value. * A 2-octet field holding left 16 bits of the signed hash value.
skipping to change at line 1693 skipping to change at line 1690
* 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 signatures than for RSA signatures; see Sections 5.2.3.1 and DSA signatures than for RSA signatures; see Sections 5.2.3.1 and
5.2.3.2. 5.2.3.2.
5.2.3. Versions 4 and 6 Signature Packet Formats 5.2.3. Versions 4 and 6 Signature Packet Formats
The body of a v4 or v6 Signature packet contains: The body of a version 4 or version 6 Signature packet contains:
* A 1-octet version number. This is 4 for v4 signatures and 6 for * A 1-octet version number. This is 4 for version 4 signatures and
v6 signatures. 6 for version 6 signatures.
* A 1-octet signature Type ID. * A 1-octet Signature Type ID.
* A 1-octet public key algorithm. * A 1-octet public key algorithm.
* A 1-octet hash algorithm. * A 1-octet hash algorithm.
* A scalar octet count for the hashed subpacket data that follows * A scalar octet count for the hashed subpacket data that follows
this field. For a v4 signature, this is a 2-octet field. For a this field. For a version 4 signature, this is a 2-octet field.
v6 signature, this is a 4-octet field. Note that this is the For a version 6 signature, this is a 4-octet field. Note that
length in octets of all of the hashed subpackets; an this is the length in octets of all of the hashed subpackets; an
implementation's pointer incremented by this number will skip over implementation's pointer incremented by this number will skip over
the hashed subpackets. the hashed subpackets.
* A hashed subpacket data set (zero or more subpackets). * A hashed subpacket data set (zero or more subpackets).
* A scalar octet count for the unhashed subpacket data that follows * A scalar octet count for the unhashed subpacket data that follows
this field. For a v4 signature, this is a 2-octet field. For a this field. For a version 4 signature, this is a 2-octet field.
v6 signature, this is a 4-octet field. Note that this is the For a version 6 signature, this is a 4-octet field. Note that
length in octets of all of the unhashed subpackets; an this is the length in octets of all of the unhashed subpackets; an
implementation's pointer incremented by this number will skip over implementation's pointer incremented by this number will skip over
the unhashed subpackets. the unhashed subpackets.
* An unhashed subpacket data set (zero or more subpackets). * An unhashed subpacket data set (zero or more subpackets).
* A 2-octet field holding the left 16 bits of the signed hash value. * A 2-octet field holding the left 16 bits of the signed hash value.
* Only for v6 signatures, a variable-length field containing: * Only for version 6 signatures, a variable-length field containing:
- A 1-octet salt size. The value MUST match the value defined - A 1-octet salt size. The value MUST match the value defined
for the hash algorithm as specified in Table 23. for the hash algorithm as specified in Table 23.
- The salt, which is a random value of the specified size. - The salt, which is a random value of the specified size.
* One or more MPIs comprising the signature. This portion is * One or more MPIs comprising the signature. This portion is
algorithm specific. algorithm specific.
5.2.3.1. Algorithm-Specific Fields for RSA Signatures 5.2.3.1. Algorithm-Specific Fields for RSA Signatures
skipping to change at line 1835 skipping to change at line 1832
5.2.3.6. Notes on Signatures 5.2.3.6. Notes on Signatures
The concatenation of the data being signed, the signature data from The concatenation of the data being signed, the signature data from
the version number through the hashed subpacket data (inclusive), and the version number through the hashed subpacket data (inclusive), and
(for signature versions later than 3) a 6-octet trailer (see (for signature versions later than 3) a 6-octet trailer (see
Section 5.2.4) is hashed. The resulting hash value is what is Section 5.2.4) is hashed. The resulting hash value is what is
signed. The high 16 bits (first two octets) of the hash are included signed. The high 16 bits (first two octets) of the hash are included
in the Signature packet to provide a way to reject some invalid in the Signature packet to provide a way to reject some invalid
signatures without performing a signature verification. When signatures without performing a signature verification. When
verifying a v6 signature, an implementation MUST reject the signature verifying a version 6 signature, an implementation MUST reject the
if these octets do not match the first two octets of the computed signature if these octets do not match the first two octets of the
hash. computed hash.
There are two fields consisting of Signature subpackets. The first There are two fields consisting of Signature subpackets. The first
field is hashed with the rest of the signature data, while the second field is hashed with the rest of the signature data, while the second
is not hashed into the signature. The second set of subpackets (the is not hashed into the signature. The second set of subpackets (the
"unhashed section") is not cryptographically protected by the "unhashed section") is not cryptographically protected by the
signature and should include only advisory information. See signature and should include only advisory information. See
Section 13.13 for more information. Section 13.13 for more information.
The differences between a v4 and v6 signature are two-fold: first, a The differences between a version 4 and version 6 signature are two-
v6 signature increases the width of the fields that indicate the size fold: first, a version 6 signature increases the width of the fields
of the hashed and unhashed subpackets, making it possible to include that indicate the size of the hashed and unhashed subpackets, making
significantly more data in subpackets. Second, the hash is salted it possible to include significantly more data in subpackets.
with random data (see Section 13.2). Second, the hash is salted with random data (see Section 13.2).
The algorithms for converting the hash function result to a signature The algorithms for converting the hash function result to a signature
are described in Section 5.2.4. are described in Section 5.2.4.
5.2.3.7. Signature Subpacket Specification 5.2.3.7. Signature Subpacket Specification
A subpacket data set consists of zero or more Signature subpackets. A subpacket data set consists of zero or more Signature subpackets.
In Signature packets, the subpacket data set is preceded by a 2-octet In Signature packets, the subpacket data set is preceded by a 2-octet
(for v4 signatures) or 4-octet (for v6 signatures) scalar count of (for version 4 signatures) or 4-octet (for version 6 signatures)
the length in octets of all the subpackets. A pointer incremented by scalar count of the length in octets of all the subpackets. A
this number will skip over the subpacket data set. pointer incremented by this number will skip over the subpacket data
set.
Each subpacket consists of a subpacket header and a body. The header Each subpacket consists of a subpacket header and a body. The header
consists of: consists of:
* The encoded subpacket length (1, 2, or 5 octets). * The encoded subpacket length (1, 2, or 5 octets).
* The encoded subpacket Type ID (1 octet). * The encoded Subpacket Type ID (1 octet).
* The subpacket-specific data. * The subpacket-specific data.
The subpacket length field covers the encoded subpacket Type ID and The subpacket length field covers the encoded Subpacket Type ID and
the subpacket-specific data, and it does not include the subpacket the subpacket-specific data, and it does not include the subpacket
length field itself. It is encoded similarly to a 1-octet, 2-octet, length field itself. It is encoded similarly to a 1-octet, 2-octet,
or 5-octet OpenPGP format packet header. The encoded subpacket or 5-octet OpenPGP format packet header. The encoded subpacket
length can be decoded as follows: length can be decoded as follows:
if the 1st octet < 192, then if the 1st octet < 192, then
lengthOfLength = 1 lengthOfLength = 1
subpacketLen = 1st_octet subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then if the 1st octet >= 192 and < 255, then
lengthOfLength = 2 lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then if the 1st octet = 255, then
lengthOfLength = 5 lengthOfLength = 5
subpacket length = [4-octet scalar starting at 2nd_octet] subpacket length = [4-octet scalar starting at 2nd_octet]
Bit 7 of the encoded subpacket Type ID is the "critical" bit. If Bit 7 of the encoded Subpacket Type ID is the "critical" bit. If
set, it denotes that the subpacket is one that is critical for the set, it denotes that the subpacket is one that is critical for the
evaluator of the signature to recognize. If a subpacket is evaluator of the signature to recognize. If a subpacket is
encountered that is marked critical but is unknown to the evaluating encountered that is marked critical but is unknown to the evaluating
implementation, the evaluator SHOULD consider the signature to be in implementation, the evaluator SHOULD consider the signature to be in
error. error.
An implementation SHOULD ignore any non-critical subpacket of a type An implementation SHOULD ignore any non-critical subpacket of a type
that it does not recognize. that it does not recognize.
An evaluator may "recognize" a subpacket but not implement it. The An evaluator may "recognize" a subpacket but not implement it. The
purpose of the critical bit is to allow the signer to tell an purpose of the critical bit is to allow the signer to tell an
evaluator that it would prefer a new, unknown feature to generate an evaluator that it would prefer a new, unknown feature to generate an
error rather than being ignored. error rather than being ignored.
The other bits of the encoded subpacket Type ID (i.e., bits 6-0) The other bits of the encoded Subpacket Type ID (i.e., bits 6-0)
contain the subpacket Type ID. contain the Subpacket Type ID.
The following signature subpackets are defined: The following signature subpackets are defined:
+=========+===========================+==================+ +=========+===========================+==================+
| ID | Description | Reference | | ID | Description | Reference |
+=========+===========================+==================+ +=========+===========================+==================+
| 0 | Reserved | | | 0 | Reserved | |
+---------+---------------------------+------------------+ +---------+---------------------------+------------------+
| 1 | Reserved | | | 1 | Reserved | |
+---------+---------------------------+------------------+ +---------+---------------------------+------------------+
skipping to change at line 2069 skipping to change at line 2067
signature. Subpackets that appear in a certification self-signature signature. Subpackets that appear in a certification self-signature
apply to the User ID, and subpackets that appear in the subkey self- apply to the User ID, and subpackets that appear in the subkey self-
signature apply to the subkey. Lastly, subpackets on the Direct Key signature apply to the subkey. Lastly, subpackets on the Direct Key
signature apply to the entire key. signature apply to the entire key.
An implementation should interpret a self-signature's preference An implementation 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 user names, Alice and Bob. Suppose that Alice prefers the AEAD two user names, Alice and Bob. Suppose that Alice prefers the AEAD
ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM.
If the implementation locates this key via Alice's name, then the If the implementation locates this key via Alice's name, then the
Preferred AEAD Ciphersuite is AES-256 with OCB; if the implementation preferred AEAD ciphersuite is AES-256 with OCB; if the implementation
locates the key via Bob's name, then the preferred algorithm is locates the key via Bob's name, then the preferred algorithm is
Camellia-256 with GCM. If the key is located by Key ID, the Camellia-256 with GCM. If the key is located by Key ID, the
algorithm of the Primary User ID of the key provides the Preferred algorithm of the Primary User ID of the key provides the preferred
AEAD Ciphersuite. AEAD ciphersuite.
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 self- 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 K", signature is a statement, "My name X is tied to my signing key K",
and it is corroborated by other users' certifications. If another and it 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.
Similarly, if the users themselves revoke their self-signature, then Similarly, if the users themselves revoke their self-signature, then
the users no longer go by that name, no longer have that email the users no longer go by that name, no longer have that email
skipping to change at line 2107 skipping to change at line 2105
offer to create new self-signatures that advertise the actual set of offer to create new self-signatures that advertise the actual set of
features and algorithms supported by the implementation. features and algorithms supported by the implementation.
An implementation that encounters multiple self-signatures on the An implementation that encounters multiple self-signatures on the
same object MUST select the most recent valid self-signature and same object MUST select the most recent valid self-signature and
ignore all other self-signatures. ignore all other self-signatures.
By convention, a version 4 key stores information about the primary By convention, a version 4 key stores information about the primary
Public Key (key flags, key expiration, etc.) and the Transferable Public Key (key flags, key expiration, etc.) and the Transferable
Public Key as a whole (features, algorithm preferences, etc.) in a Public Key as a whole (features, algorithm preferences, etc.) in a
User ID self-signature of type 0x10 or 0x13. To use a v4 key, some User ID self-signature of type 0x10 or 0x13. To use a version 4 key,
implementations require at least one User ID with a valid self- some implementations require at least one User ID with a valid self-
signature to be present. For this reason, it is RECOMMENDED to signature to be present. For this reason, it is RECOMMENDED to
include at least one User ID with a self-signature in v4 keys. include at least one User ID with a self-signature in version 4 keys.
For version 6 keys, it is RECOMMENDED to store information about the For version 6 keys, it is RECOMMENDED to store information about the
primary Public Key as well as the Transferable Public Key as a whole primary Public Key as well as the Transferable Public Key as a whole
(key flags, key expiration, features, algorithm preferences, etc.) in (key flags, key expiration, features, algorithm preferences, etc.) in
a Direct Key signature (Type ID 0x1F) over the Public Key, instead of a Direct Key signature (Type ID 0x1F) over the Public Key, instead of
placing that information in a User ID self-signature. An placing that information in a User ID self-signature. An
implementation MUST ensure that a valid Direct Key signature is implementation MUST ensure that a valid Direct Key signature is
present before using a v6 key. This prevents certain attacks where present before using a version 6 key. This prevents certain attacks
an adversary strips a self-signature specifying a Key Expiration Time where an adversary strips a self-signature specifying a Key
or certain preferences. Expiration Time or certain preferences.
An implementation SHOULD NOT require a User ID self-signature to be An implementation SHOULD NOT require a User ID self-signature to be
present in order to consume or use a key, unless the particular use present in order to consume or use a key, unless the particular use
is contingent on the keyholder identifying themselves with the is contingent on the keyholder identifying themselves with the
textual label in the User ID. For example, when refreshing a key to textual label in the User ID. For example, when refreshing a key to
learn about changes in expiration, advertised features, algorithm learn about changes in expiration, advertised features, algorithm
preferences, revocation, subkey rotation, and so forth, there is no preferences, revocation, subkey rotation, and so forth, there is no
need to require a User ID self-signature. On the other hand, when need to require a User ID self-signature. On the other hand, when
verifying a signature over an email message, an implementation MAY verifying a signature over an email message, an implementation MAY
choose to only accept a signature from a key that has a valid self- choose to only accept a signature from a key that has a valid self-
skipping to change at line 2175 skipping to change at line 2173
zero, the key never expires. This is found only on a self-signature. zero, the key never expires. This is found only on a self-signature.
When an implementation generates this subpacket, it SHOULD be marked When an implementation generates this subpacket, it SHOULD be marked
as critical. as critical.
5.2.3.14. Preferred Symmetric Ciphers for v1 SEIPD 5.2.3.14. Preferred Symmetric Ciphers for v1 SEIPD
(array of 1-octet values) (array of 1-octet values)
A series of Symmetric Cipher Algorithm IDs indicating how the A series of Symmetric Cipher Algorithm IDs indicating how the
keyholder prefers to receive Symmetrically Encrypted and Integrity keyholder prefers to receive the Version 1 Symmetrically Encrypted
Protected Data packet version 1 (Section 5.13.1). The subpacket body and Integrity Protected Data packet (Section 5.13.1). The subpacket
is an ordered list of octets with the most preferred listed first. body is an ordered list of octets with the most preferred listed
It is assumed that only the algorithms listed are supported by the first. It is assumed that only the algorithms listed are supported
recipient's implementation. Algorithm IDs are defined in by the recipient's implementation. Algorithm IDs are defined in
Section 9.3. This is only found on a self-signature. Section 9.3. This is only found on a self-signature.
When generating a v2 SEIPD packet, this preference list is not When generating a v2 SEIPD packet, this preference list is not
relevant. See Section 5.2.3.15 instead. relevant. See Section 5.2.3.15 instead.
5.2.3.15. Preferred AEAD Ciphersuites 5.2.3.15. Preferred AEAD Ciphersuites
(array of pairs of octets indicating Symmetric Cipher and AEAD (array of pairs of octets indicating Symmetric Cipher and AEAD
algorithms) algorithms)
A series of paired algorithm IDs indicating how the keyholder prefers A series of paired algorithm IDs indicating how the keyholder prefers
to receive Symmetrically Encrypted and Integrity Protected Data to receive the Version 2 Symmetrically Encrypted and Integrity
packet version 2 (Section 5.13.2). Each pair of octets indicates a Protected Data packet (Section 5.13.2). Each pair of octets
combination of a symmetric cipher and an AEAD mode that the keyholder indicates a combination of a symmetric cipher and an AEAD mode that
prefers to use. The Symmetric Cipher Algorithm ID precedes the AEAD the keyholder prefers to use. The Symmetric Cipher Algorithm ID
algorithm ID in each pair. The subpacket body is an ordered list of precedes the AEAD algorithm ID in each pair. The subpacket body is
pairs of octets with the most preferred algorithm combination listed an ordered list of pairs of octets with the most preferred algorithm
first. combination listed first.
It is assumed that only the combinations of algorithms listed are It is assumed that only the combinations of algorithms listed are
supported by the recipient's implementation, with the exception of supported by the recipient's implementation, with the exception of
the mandatory-to-implement combination of AES-128 and OCB. If the mandatory-to-implement combination of AES-128 and OCB. If
AES-128 and OCB are not found in the subpacket, it is implicitly AES-128 and OCB are not found in the subpacket, it is implicitly
listed at the end. listed at the end.
AEAD algorithm IDs are listed in Section 9.6. Symmetric Cipher AEAD algorithm IDs are listed in Section 9.6. Symmetric Cipher
Algorithm IDs are listed in Section 9.3. Algorithm IDs are listed in Section 9.3.
For example, a subpacket containing the six octets For example, a subpacket containing the six octets
09 02 09 03 13 02 09 02 09 03 13 02
indicates that the keyholder prefers to receive v2 SEIPD using indicates that the keyholder prefers to receive v2 SEIPD using
AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB,
and finally the implicit AES-128 with OCB. and finally the implicit AES-128 with OCB.
Note that support for the Symmetrically Encrypted and Integrity Note that support for the Version 2 Symmetrically Encrypted and
Protected Data packet version 2 (Section 5.13.2) in general is Integrity Protected Data packet (Section 5.13.2) in general is
indicated by a Features Flag (Section 5.2.3.32). indicated by a Features Flag (Section 5.2.3.32).
This subpacket is only found on a self-signature. This subpacket is only found on a self-signature.
When generating a v1 SEIPD packet, this preference list is not When generating a v1 SEIPD packet, this preference list is not
relevant. See Section 5.2.3.14 instead. relevant. See Section 5.2.3.14 instead.
5.2.3.16. Preferred Hash Algorithms 5.2.3.16. Preferred Hash Algorithms
(array of 1-octet values) (array of 1-octet values)
skipping to change at line 2347 skipping to change at line 2345
this octet; if it is not present, it MUST reject the subpacket (i.e., this octet; if it is not present, it MUST reject the subpacket (i.e.,
ignore the subpacket if it's non-critical and reject the signature if ignore the subpacket if it's non-critical and reject the signature if
it's critical). When an implementation generates a Regular it's critical). When an implementation generates a Regular
Expression subpacket, it MUST include the null terminator. Expression subpacket, it MUST include the null terminator.
When generating this subpacket, it SHOULD be marked as critical. When generating this subpacket, it SHOULD be marked as critical.
5.2.3.23. Revocation Key (Deprecated) 5.2.3.23. Revocation Key (Deprecated)
(1 octet of class, 1 octet of public key algorithm ID, 20 octets of (1 octet of class, 1 octet of public key algorithm ID, 20 octets of
v4 fingerprint) version 4 fingerprint)
This mechanism is deprecated. Applications MUST NOT generate such a This mechanism is deprecated. Applications MUST NOT generate such a
subpacket. subpacket.
An application that wants the functionality of delegating revocation An application that wants the functionality of delegating revocation
can use an escrowed Revocation Signature. See Section 13.9 for more can use an escrowed Revocation Signature. See Section 13.9 for more
details. details.
The remainder of this section describes how some implementations The remainder of this section describes how some implementations
attempt to interpret this deprecated subpacket. attempt to interpret this deprecated subpacket.
skipping to change at line 2508 skipping to change at line 2506
This subpacket contains a list of binary flags that hold information This subpacket contains a list of binary flags that hold information
about a key. It is a string of octets, and an implementation MUST about a key. It is a string of octets, and an implementation MUST
NOT assume a fixed size, so that it can grow over time. If a list is NOT assume a fixed size, so that it can grow over time. If a list is
shorter than an implementation expects, the unstated flags are shorter than an implementation expects, the unstated flags are
considered to be zero. The defined flags are as follows: considered to be zero. The defined flags are as follows:
+===========+======================================================+ +===========+======================================================+
| Flag | Definition | | Flag | Definition |
+===========+======================================================+ +===========+======================================================+
| 0x01... | This key may be used to make User ID certifications | | 0x01... | This key may be used to make User ID certifications |
| | (signature Type IDs 0x10-0x13) or Direct Key | | | (Signature Type IDs 0x10-0x13) or Direct Key |
| | signatures (signature Type ID 0x1F) over other keys. | | | signatures (Signature Type ID 0x1F) over other keys. |
+-----------+------------------------------------------------------+ +-----------+------------------------------------------------------+
| 0x02... | This key may be used to sign data. | | 0x02... | This key may be used to sign data. |
+-----------+------------------------------------------------------+ +-----------+------------------------------------------------------+
| 0x04... | This key may be used to encrypt communications. | | 0x04... | This key may be used to encrypt communications. |
+-----------+------------------------------------------------------+ +-----------+------------------------------------------------------+
| 0x08... | This key may be used to encrypt storage. | | 0x08... | This key may be used to encrypt storage. |
+-----------+------------------------------------------------------+ +-----------+------------------------------------------------------+
| 0x10... | The private component of this key may have been | | 0x10... | The private component of this key may have been |
| | split by a secret-sharing mechanism. | | | split by a secret-sharing mechanism. |
+-----------+------------------------------------------------------+ +-----------+------------------------------------------------------+
skipping to change at line 2579 skipping to change at line 2577
(1 octet of revocation code, N octets of reason string) (1 octet of revocation code, N octets of reason string)
This subpacket is used only in Key Revocation and Certification This subpacket is used only in Key Revocation and Certification
Revocation signatures. It describes the reason why the key or Revocation signatures. It describes the reason why the key or
certification was revoked. certification 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:
+=========+==================================+ +=========+========================================+
| Code | Reason | | Code | Reason |
+=========+==================================+ +=========+========================================+
| 0 | No reason specified (key | | 0 | No reason specified (Key Revocation or |
| | revocations or cert revocations) | | | Certificate Revocation signatures) |
+---------+----------------------------------+ +---------+----------------------------------------+
| 1 | Key is superseded (key | | 1 | Key is superseded (Key Revocation |
| | revocations) | | | signatures) |
+---------+----------------------------------+ +---------+----------------------------------------+
| 2 | Key material has been | | 2 | Key material has been compromised (Key |
| | compromised (key revocations) | | | Revocation signatures) |
+---------+----------------------------------+ +---------+----------------------------------------+
| 3 | Key is retired and no longer | | 3 | Key is retired and no longer used (Key |
| | used (key revocations) | | | Revocation signatures) |
+---------+----------------------------------+ +---------+----------------------------------------+
| 32 | User ID information is no longer | | 32 | User ID information is no longer valid |
| | valid (cert revocations) | | | (Certification Revocation signatures) |
+---------+----------------------------------+ +---------+----------------------------------------+
| 100-110 | Private Use | | 100-110 | Private Use |
+---------+----------------------------------+ +---------+----------------------------------------+
Table 10: OpenPGP Reason for Revocation Table 10: OpenPGP Reason for Revocation
(Revocation Octet) Registry (Revocation Octet) Registry
Following the revocation code is a string of octets that gives Following the revocation code is a string of octets that 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 (of zero length). The length of the (UTF-8). The string may be null (of zero length). The length of the
subpacket is the length of the reason string plus one. An subpacket is the length of the reason string plus one. An
implementation SHOULD implement this subpacket, include it in all implementation SHOULD implement this subpacket, include it in all
Revocation Signatures, and interpret revocations appropriately. Revocation Signatures, and interpret revocations appropriately.
skipping to change at line 2648 skipping to change at line 2646
An implementation SHOULD NOT use a feature listed when sending to a An implementation SHOULD NOT use a feature listed when sending to a
user who does not state that they can use it, unless the user who does not state that they can use it, unless the
implementation can infer support for the feature from another implementation can infer support for the feature from another
implementation-dependent mechanism. implementation-dependent mechanism.
Defined features are as follows: Defined features are as follows:
First octet: First octet:
+=========+=======================================+===========+ +=========+=====================================+===========+
| Feature | Definition | Reference | | Feature | Definition | Reference |
+=========+=======================================+===========+ +=========+=====================================+===========+
| 0x01... | Symmetrically Encrypted and Integrity | Section | | 0x01... | Version 1 Symmetrically Encrypted | Section |
| | Protected Data packet version 1 | 5.13.1 | | | and Integrity Protected Data packet | 5.13.1 |
+---------+---------------------------------------+-----------+ +---------+-------------------------------------+-----------+
| 0x02... | Reserved | | | 0x02... | Reserved | |
+---------+---------------------------------------+-----------+ +---------+-------------------------------------+-----------+
| 0x04... | Reserved | | | 0x04... | Reserved | |
+---------+---------------------------------------+-----------+ +---------+-------------------------------------+-----------+
| 0x08... | Symmetrically Encrypted and Integrity | Section | | 0x08... | Version 2 Symmetrically Encrypted | Section |
| | Protected Data packet version 2 | 5.13.2 | | | and Integrity Protected Data packet | 5.13.2 |
+---------+---------------------------------------+-----------+ +---------+-------------------------------------+-----------+
Table 11: OpenPGP Features Flags Registry Table 11: OpenPGP Features Flags Registry
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the Features subpacket, too. SHOULD implement the Features subpacket, too.
See Section 13.7 for details about how to use the Features subpacket See Section 13.7 for details about how to use the Features subpacket
when generating encryption data. when generating encryption data.
5.2.3.33. Signature Target 5.2.3.33. Signature Target
skipping to change at line 2700 skipping to change at line 2698
in Section 5.2. It is useful when one signature needs to refer to, in Section 5.2. It is useful when one signature needs to refer to,
or be incorporated in, another signature. or be incorporated in, another signature.
5.2.3.35. Issuer Fingerprint 5.2.3.35. Issuer Fingerprint
(1 octet key version number, N octets of fingerprint) (1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the key issuing the signature. This The OpenPGP Key fingerprint of the key issuing the signature. This
subpacket SHOULD be included in all signatures. If the version of subpacket SHOULD be included in all signatures. If the version of
the issuing key is 4 and an Issuer Key ID subpacket the issuing key is 4 and an Issuer Key ID subpacket
(Section 5.2.3.12) is also included in the signature, the key ID of (Section 5.2.3.12) is also included in the signature, the Key ID of
the Issuer Key ID subpacket MUST match the low 64 bits of the the Issuer Key ID subpacket MUST match the low 64 bits of the
fingerprint. fingerprint.
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 6 key, N is 32. Since the version of the octets; for a version 6 key, N is 32. Since the version of the
signature is bound to the version of the key, the version octet here signature is bound to the version of the key, the version octet here
MUST match the version of the signature. If the version octet does MUST match the version of the signature. If the version octet does
not match the signature version, the receiving implementation MUST not match the signature version, the receiving implementation MUST
treat it as a malformed signature (see Section 5.2.5). treat it as a malformed signature (see Section 5.2.5).
skipping to change at line 2728 skipping to change at line 2726
key it was encrypted to is one of the indicated primary keys or one key it was encrypted to is one of the indicated primary keys or one
of their subkeys. This can be used to prevent forwarding a signature of their subkeys. This can be used to prevent forwarding a signature
outside of its intended, encrypted context (see Section 13.12). outside of its intended, encrypted context (see Section 13.12).
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 6 key, N is 32. octets; for a version 6 key, N is 32.
An implementation SHOULD generate this subpacket when creating a An implementation SHOULD generate this subpacket when creating a
signed and encrypted message. signed and encrypted message.
When generating this subpacket in a v6 signature, it SHOULD be marked When generating this subpacket in a version 6 signature, it SHOULD be
as critical. marked as critical.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature data All signatures are formed by producing a hash over the signature data
and then using the resulting hash in the signature algorithm. and then using the resulting hash in the signature algorithm.
When creating or verifying a version 6 signature, the salt is fed When creating or verifying a version 6 signature, the salt is fed
into the hash context before any other data. into the hash context before any other data.
For binary document signatures (Type ID 0x00), the document data is For binary document signatures (Type ID 0x00), the document data is
skipping to change at line 2831 skipping to change at line 2829
5.2.4.1. Notes about Signature Computation 5.2.4.1. Notes about Signature Computation
The data actually hashed by OpenPGP varies depending on the signature The data actually hashed by OpenPGP varies depending on the signature
version, in order to ensure that a signature made using one version version, in order to ensure that a signature made using one version
cannot be repurposed as a signature with a different version over cannot be repurposed as a signature with a different version over
subtly different data. The hashed data streams differ based on their subtly different data. The hashed data streams differ based on their
trailer, most critically in the fifth and sixth octets from the end trailer, most critically in the fifth and sixth octets from the end
of the stream. In particular: of the stream. In particular:
* A version 3 signature uses the fifth octet from the end to store * A version 3 signature uses the fifth octet from the end to store
its signature Type ID. This MUST NOT be signature Type ID 0xFF. its Signature Type ID. This MUST NOT be Signature Type ID 0xFF.
* All signature versions later than version 3 always use a literal * All signature versions later than version 3 always use a literal
0xFF in the fifth octet from the end. For these later signature 0xFF in the fifth octet from the end. For these later signature
versions, the sixth octet from the end (the octet before the 0xFF) versions, the sixth octet from the end (the octet before the 0xFF)
stores the signature version number. stores the signature version number.
5.2.5. Malformed and Unknown Signatures 5.2.5. Malformed and Unknown Signatures
In some cases, a Signature packet (or its corresponding One-Pass In some cases, a Signature packet (or its corresponding One-Pass
Signature packet; see Section 5.4) may be malformed or unknown. For Signature packet; see Section 5.4) may be malformed or unknown. For
skipping to change at line 2867 skipping to change at line 2865
Signature packet itself Signature packet itself
* A hash algorithm known to be weak (e.g., MD5) * A hash algorithm known to be weak (e.g., MD5)
* A mismatch between the expected salt length of the hash algorithm * A mismatch between the expected salt length of the hash algorithm
and the actual salt length and the actual salt length
* A mismatch between the One-Pass Signature version and the * A mismatch between the One-Pass Signature version and the
Signature version (see Section 10.3.2.2) Signature version (see Section 10.3.2.2)
* A signature with a version other than 6, made by a v6 key * A signature with a version other than 6, made by a version 6 key
When an implementation encounters such a malformed or unknown When an implementation encounters such a malformed or unknown
signature, it MUST ignore the signature for validation purposes. It signature, it MUST ignore the signature for validation purposes. It
MUST NOT indicate a successful signature validation for such a MUST NOT indicate a successful signature validation for such a
signature. At the same time, it MUST NOT halt processing on the signature. At the same time, it MUST NOT halt processing on the
packet stream or reject other signatures in the same packet stream packet stream or reject other signatures in the same packet stream
just because an unknown or invalid signature exists. just because an unknown or invalid signature exists.
This requirement is necessary for forward compatibility. Producing This requirement is necessary for forward compatibility. Producing
an output that indicates that no successful signatures were found is an output that indicates that no successful signatures were found is
skipping to change at line 2910 skipping to change at line 2908
are 4 and 6. The remainder of the packet depends on the version. are 4 and 6. The remainder of the packet depends on the version.
The versions differ in how they encrypt the session key with the The versions differ in how they encrypt the session key with the
passphrase and in what they encode. The version of the SKESK packet passphrase and in what they encode. The version of the SKESK packet
must align with the version of the SEIPD packet (see must align with the version of the SEIPD packet (see
Section 10.3.2.1). Any new version of the SKESK packet should be Section 10.3.2.1). Any new version of the SKESK packet should be
registered in the registry established in Section 10.3.2.1. registered in the registry established in Section 10.3.2.1.
5.3.1. Version 4 Symmetric Key Encrypted Session Key Packet Format 5.3.1. Version 4 Symmetric Key Encrypted Session Key Packet Format
A version 4 SKESK packet precedes a v1 SEIPD (see Section 5.13.1). A v4 SKESK packet precedes a v1 SEIPD (see Section 5.13.1). In
In historic data, it is sometimes found preceding a deprecated SED historic data, it is sometimes found preceding a deprecated SED
packet (see Section 5.7). A v4 SKESK packet MUST NOT precede a v2 packet (see Section 5.7). A v4 SKESK packet MUST NOT precede a v2
SEIPD packet (see Section 10.3.2.1). SEIPD packet (see Section 10.3.2.1).
A version 4 Symmetric Key Encrypted Session Key packet consists of: A version 4 Symmetric Key Encrypted Session Key packet consists of:
* A 1-octet version number with value 4. * A 1-octet version number with value 4.
* A 1-octet number describing the symmetric algorithm used. * A 1-octet number describing the symmetric algorithm used.
* An S2K Specifier Type. The length of the S2K Specifier Type * An S2K Specifier. The length of the S2K Specifier depends on its
depends on its type (see Section 3.7.1). type (see Section 3.7.1).
* Optionally, the encrypted session key itself, which is decrypted * Optionally, the encrypted session key itself, which is decrypted
with the S2K object. with the S2K object.
If the encrypted session key is not present (which can be detected on If the encrypted session key is not present (which can be detected on
the basis of packet length and S2K Specifier Type size), then the S2K the basis of packet length and S2K Specifier size), then the S2K
algorithm applied to the passphrase produces the session key for algorithm applied to the passphrase produces the session key for
decrypting the message, using the Symmetric Cipher Algorithm ID from decrypting the message, using the Symmetric Cipher Algorithm ID from
the Symmetric Key Encrypted Session Key packet. the Symmetric Key Encrypted Session Key packet.
If the encrypted session key is present, the result of applying the If the encrypted session key is present, the result of applying the
S2K algorithm to the passphrase is used to decrypt just that S2K algorithm to the passphrase is used to decrypt just that
encrypted session key field, using CFB mode with an IV of all zeros. encrypted session key field, using CFB mode with an IV of all zeros.
The decryption result consists of a 1-octet algorithm identifier that The decryption result consists of a 1-octet algorithm identifier that
specifies the symmetric key encryption algorithm used to encrypt the specifies the symmetric key encryption algorithm used to encrypt the
following encryption container, followed by the session key octets following encryption container, followed by the session key octets
themselves. themselves.
Note: because an all-zero IV is used for this decryption, the S2K Note: because an all-zero IV is used for this decryption, the S2K
Specifier Type MUST use a salt value, a Salted S2K, an Iterated and Specifier MUST use a salt value, a Salted S2K, an Iterated and Salted
Salted S2K, or Argon2. The salt value will ensure that the S2K, or Argon2. The salt value will ensure that the decryption key
decryption key is not repeated even if the passphrase is reused. is not repeated even if the passphrase is reused.
5.3.2. Version 6 Symmetric Key Encrypted Session Key Packet Format 5.3.2. Version 6 Symmetric Key Encrypted Session Key Packet Format
A version 6 SKESK packet precedes a v2 SEIPD packet (see A v6 SKESK packet precedes a v2 SEIPD packet (see Section 5.13.2). A
Section 5.13.2). A v6 SKESK packet MUST NOT precede a v1 SEIPD v6 SKESK packet MUST NOT precede a v1 SEIPD packet or a deprecated
packet or a deprecated Symmetrically Encrypted Data packet (see Symmetrically Encrypted Data packet (see Section 10.3.2.1).
Section 10.3.2.1).
A version 6 Symmetric Key Encrypted Session Key packet consists of: A version 6 Symmetric Key Encrypted Session Key packet consists of:
* A 1-octet version number with value 6. * A 1-octet version number with value 6.
* A 1-octet scalar octet count for the 5 fields following this * A 1-octet scalar octet count for the 5 fields following this
octet. octet.
* A 1-octet Symmetric Cipher Algorithm ID (from Table 21). * A 1-octet Symmetric Cipher Algorithm ID (from Table 21).
* A 1-octet AEAD algorithm identifier (from Table 25). * A 1-octet AEAD algorithm identifier (from Table 25).
* A 1-octet scalar octet count of the following field. * A 1-octet scalar octet count of the following field.
* An S2K Specifier Type. The length of the S2K Specifier Type * An S2K Specifier. The length of the S2K Specifier depends on its
depends on its type (see Section 3.7.1). type (see Section 3.7.1).
* A starting IV of the size specified by the AEAD algorithm. * A starting IV of the size specified by the AEAD algorithm.
* The encrypted session key itself. * The encrypted session key itself.
* An authentication tag for the AEAD mode. * An authentication tag for the AEAD mode.
A key-encryption key (KEK) is derived using HKDF [RFC5869] with A key-encryption key (KEK) is derived using HKDF [RFC5869] with
SHA256 [RFC6234] as the hash algorithm. The Initial Keying Material SHA256 [RFC6234] as the hash algorithm. The Initial Keying Material
(IKM) for HKDF is the key derived from S2K. No salt is used. The (IKM) for HKDF is the key derived from S2K. No salt is used. The
info parameter is comprised of the Packet Type ID in OpenPGP format info parameter is comprised of the Packet Type ID in OpenPGP format
encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type
ID), the packet version, and the cipher-algo and AEAD-mode used to ID), the packet version, and the cipher-algo and AEAD-mode used to
encrypt the key material. encrypt the key material.
Then, the session key is encrypted using the resulting key, with the Then, the session key is encrypted using the resulting key, with the
AEAD algorithm specified for the Symmetrically Encrypted and AEAD algorithm specified for the Version 2 Symmetrically Encrypted
Integrity Protected Data packet version 2. Note that no chunks are and Integrity Protected Data packet. Note that no chunks are used
used and that there is only one authentication tag. The Packet Type and that there is only one authentication tag. The Packet Type ID
ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry
carry the Packet Type ID), the packet version number, the cipher the Packet Type ID), the packet version number, the cipher algorithm
algorithm ID, and the AEAD algorithm ID are given as additional data. ID, and the AEAD algorithm ID are given as additional data. For
For example, the additional data used with AES-128 with OCB consists example, the additional data used with AES-128 with OCB consists of
of the octets 0xC3, 0x06, 0x07, and 0x02. the octets 0xC3, 0x06, 0x07, and 0x02.
5.4. One-Pass Signature Packet (Type ID 4) 5.4. One-Pass Signature Packet (Type ID 4)
The One-Pass Signature packet precedes the signed data and contains The One-Pass Signature packet precedes the signed data and contains
enough information to allow the receiver to begin calculating any enough information to allow the receiver to begin calculating any
hashes needed to verify the signature. It allows the Signature hashes needed to verify the signature. It allows the Signature
packet to be placed at the end of the message so that the signer can packet to be placed at the end of the message so that the signer can
compute the entire signed message in one pass. compute the entire signed message in one pass.
The body of this packet consists of: The body of this packet consists of:
* A 1-octet version number. The currently defined versions are 3 * A 1-octet version number. The currently defined versions are 3
and 6. Any new One-Pass Signature packet version should be and 6. Any new One-Pass Signature packet version should be
registered in the registry established in Section 10.3.2.2. registered in the registry established in Section 10.3.2.2.
* A 1-octet signature Type ID. Signature types are described in * A 1-octet Signature Type ID. Signature types are described in
Section 5.2.1. Section 5.2.1.
* A 1-octet number describing the hash algorithm used. * A 1-octet number describing the hash algorithm used.
* A 1-octet number describing the public key algorithm used. * A 1-octet number describing the public key algorithm used.
* Only for v6 packets, a variable-length field containing: * Only for version 6 packets, a variable-length field containing:
- A 1-octet salt size. The value MUST match the value defined - A 1-octet salt size. The value MUST match the value defined
for the hash algorithm as specified in Table 23. for the hash algorithm as specified in Table 23.
- The salt; a random value of the specified size. The value MUST - The salt; a random value of the specified size. The value MUST
match the salt field of the corresponding Signature packet. match the salt field of the corresponding Signature packet.
* Only for v3 packets, an 8-octet number holding the Key ID of the * Only for v3 packets, an 8-octet number holding the Key ID of the
signing key. signing key.
* Only for v6 packets, 32 octets of the fingerprint of the signing * Only for version 6 packets, 32 octets of the fingerprint of the
key. Since a v6 signature can only be made by a v6 key, the signing key. Since a version 6 signature can only be made by a
length of the fingerprint is fixed. version 6 key, the length of the fingerprint is fixed.
* A 1-octet number holding a flag showing whether the signature is * A 1-octet number holding a flag showing whether the signature is
nested. A zero value indicates that the next packet is another nested. A zero value indicates that the next packet is another
One-Pass Signature packet that describes another signature to be One-Pass Signature packet that describes another signature to be
applied to the same message data. applied to the same message data.
When generating a one-pass signature, the OPS packet version MUST When generating a one-pass signature, the OPS packet version MUST
correspond to the version of the associated Signature packet, except correspond to the version of the associated Signature packet, except
for the historical accident that v4 keys use a v3 One-Pass Signature for the historical accident that version 4 keys use a version 3 One-
packet (there is no v4 OPS). See Section 10.3.2.2 for the full Pass Signature packet (there is no version 4 OPS). See
correspondence of versions between Keys, Signatures, and One-Pass Section 10.3.2.2 for the full correspondence of versions between
Signatures. Keys, Signatures, and One-Pass Signatures.
Note that if a message contains more than one one-pass signature, Note that if a message contains more than one one-pass signature,
then the Signature packets bracket the message; that is, the first then the Signature packets bracket the message; that is, the first
Signature packet after the message corresponds to the last One-Pass Signature packet after the message corresponds to the last One-Pass
Signature packet and the final Signature packet corresponds to the Signature packet and the final Signature packet corresponds to the
first One-Pass Signature packet. first One-Pass Signature packet.
5.5. Key Material Packets 5.5. Key Material Packets
A key material packet contains all the information about a public or A key material packet contains all the information about a public or
skipping to change at line 3186 skipping to change at line 3183
specific secret key data appended, usually in encrypted form. specific secret key data appended, usually in encrypted form.
The packet contains: The packet contains:
* The fields of a Public Key or Public Subkey packet, as described * The fields of a Public Key or Public Subkey packet, as described
above. above.
* One octet (the "S2K usage octet") indicating whether and how the * One octet (the "S2K usage octet") indicating whether and how the
secret key material is protected by a passphrase. Zero indicates secret key material is protected by a passphrase. Zero indicates
that the secret key data is not encrypted. 253 (AEAD), 254 (CFB), that the secret key data is not encrypted. 253 (AEAD), 254 (CFB),
or 255 (MalleableCFB) indicates that an S2K Specifier Type and or 255 (MalleableCFB) indicates that an S2K Specifier and other
other parameters will follow. Any other value is a symmetric key parameters will follow. Any other value is a symmetric key
encryption algorithm identifier. A version 6 packet MUST NOT use encryption algorithm identifier. A version 6 packet MUST NOT use
the value 255 (MalleableCFB). the value 255 (MalleableCFB).
* Only for a version 6 packet where the secret key material is * Only for a version 6 packet where the secret key material is
encrypted (that is, where the previous octet is not zero), a encrypted (that is, where the previous octet is not zero), a
1-octet scalar octet count of the cumulative length of all the 1-octet scalar octet count of the cumulative length of all the
following conditionally included S2K parameter fields. following conditionally included S2K parameter fields.
* Conditionally included S2K parameter fields: * Conditionally included S2K parameter fields:
- If the S2K usage octet was 253, 254, or 255, a 1-octet - If the S2K usage octet was 253, 254, or 255, a 1-octet
symmetric key encryption algorithm. symmetric key encryption algorithm.
- If the S2K usage octet was 253 (AEAD), a 1-octet AEAD - If the S2K usage octet was 253 (AEAD), a 1-octet AEAD
algorithm. algorithm.
- Only for a version 6 packet, and if the S2K usage octet was 253 - Only for a version 6 packet, and if the S2K usage octet was 253
or 254, a 1-octet count of the size of the one field following or 254, a 1-octet count of the size of the one field following
this octet. this octet.
- If the S2K usage octet was 253, 254, or 255, an S2K Specifier - If the S2K usage octet was 253, 254, or 255, an S2K Specifier.
Type. The length of the S2K Specifier Type depends on its type The length of the S2K Specifier depends on its type (see
(see Section 3.7.1). Section 3.7.1).
- If the S2K usage octet was 253 (AEAD), an IV of a size - If the S2K usage octet was 253 (AEAD), an IV of a size
specified by the AEAD algorithm (see Section 5.13.2), which is specified by the AEAD algorithm (see Section 5.13.2), which is
used as the nonce for the AEAD algorithm. used as the nonce for the AEAD algorithm.
- If the S2K usage octet was 254, 255, or a cipher algorithm ID - If the S2K usage octet was 254, 255, or a cipher algorithm ID
(that is, the secret data uses some form of CFB encryption), an (that is, the secret data uses some form of CFB encryption), an
IV of the same length as the cipher's block size. IV of the same length as the cipher's block size.
* Plain or encrypted multiprecision integers comprising the secret * Plain or encrypted multiprecision integers comprising the secret
skipping to change at line 3244 skipping to change at line 3241
zero, a 2-octet checksum of the algorithm-specific portion (sum of zero, a 2-octet checksum of the algorithm-specific portion (sum of
all octets, mod 65536). all octets, mod 65536).
The details about storing algorithm-specific secrets above are The details about storing algorithm-specific secrets above are
summarized in Table 2. summarized in Table 2.
Note that the version 6 packet format adds two count values to help Note that the version 6 packet format adds two count values to help
parsing packets with unknown S2K or public key algorithms. parsing packets with unknown S2K or public key algorithms.
Secret MPI values can be encrypted using a passphrase. If an S2K Secret MPI values can be encrypted using a passphrase. If an S2K
Specifier Type is given, it describes the algorithm for converting Specifier is given, it describes the algorithm for converting the
the passphrase to a key; otherwise, a simple MD5 hash of the passphrase to a key; otherwise, a simple MD5 hash of the passphrase
passphrase is used. An implementation producing a passphrase- is used. An implementation producing a passphrase-protected Secret
protected Secret Key packet MUST use an S2K Specifier Type; the Key packet MUST use an S2K Specifier; the simple hash is for read-
simple hash is for read-only backward compatibility, though only backward compatibility, though implementations MAY continue to
implementations MAY continue to use existing private keys in the old use existing private keys in the old format. The cipher for
format. The cipher for encrypting the MPIs is specified in the encrypting the MPIs is specified in the Secret Key packet.
Secret Key packet.
Encryption/decryption of the secret data is done using the key Encryption/decryption of the secret data is done using the key
created from the passphrase and the IV from the packet. If the S2K created from the passphrase and the IV from the packet. If the S2K
usage octet is not 253, CFB mode is used. A different mode is used usage octet is not 253, CFB mode is used. A different mode is used
with v3 keys (which are only RSA) than with other key formats. With with version 3 keys (which are only RSA) than with other key formats.
v3 keys, the MPI bit count prefix (that is, the first two octets) is With version 3 keys, the MPI bit count prefix (that is, the first two
not encrypted. Only the MPI non-prefix data is encrypted. octets) is not encrypted. Only the MPI non-prefix data is encrypted.
Furthermore, the CFB state is resynchronized at the beginning of each Furthermore, the CFB state is resynchronized at the beginning of each
new MPI value so that the CFB block boundary is aligned with the new MPI value so that the CFB block boundary is aligned with the
start of the MPI data. start of the MPI data.
With v4 and v6 keys, a simpler method is used. All secret MPI values With version 4 and version 6 keys, a simpler method is used. All
are encrypted, including the MPI bit count prefix. secret MPI values are encrypted, including the MPI bit count prefix.
If the S2K usage octet is 253, the KEK is derived using HKDF If the S2K usage octet is 253, the KEK is derived using HKDF
[RFC5869] to provide key separation. SHA256 [RFC6234] is used as the [RFC5869] to provide key separation. SHA256 [RFC6234] is used as the
hash algorithm for HKDF. IKM for HKDF is the key derived from S2K. hash algorithm for HKDF. IKM for HKDF is the key derived from S2K.
No salt is used. The info parameter is comprised of the Packet Type No salt is used. The info parameter is comprised of the Packet Type
ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0
carry the Packet Type ID), the packet version, and the cipher-algo carry the Packet Type ID), the packet version, and the cipher-algo
and AEAD-mode used to encrypt the key material. and AEAD-mode used to encrypt the key material.
Then, the encrypted MPI values are encrypted as one combined Then, the encrypted MPI values are encrypted as one combined
plaintext using one of the AEAD algorithms specified for the plaintext using one of the AEAD algorithms specified for the Version
Symmetrically Encrypted and Integrity Protected Data packet version 2 Symmetrically Encrypted and Integrity Protected Data packet. Note
2. Note that no chunks are used and that there is only one that no chunks are used and that there is only one authentication
authentication tag. As additional data, the Packet Type ID in tag. As additional data, the Packet Type ID in OpenPGP format
OpenPGP format encoding (bits 7 and 6 are set, and bits 5-0 carry the encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type
Packet Type ID), followed by the Public Key packet fields, starting ID), followed by the Public Key packet fields, starting with the
with the packet version number, are passed to the AEAD algorithm. packet version number, are passed to the AEAD algorithm. For
For example, the additional data used with a Secret Key packet of example, the additional data used with a Secret Key packet of version
version 4 consists of the octets 0xC5, 0x04, followed by four octets 4 consists of the octets 0xC5, 0x04, followed by four octets of
of creation time, one octet denoting the public key algorithm, and creation time, one octet denoting the public key algorithm, and the
the algorithm-specific public key parameters. For a Secret Subkey algorithm-specific public key parameters. For a Secret Subkey
packet, the first octet would be 0xC7. For a version 6 key packet, packet, the first octet would be 0xC7. For a version 6 key packet,
the second octet would be 0x06, and the 4-octet octet count of the the second octet would be 0x06, and the 4-octet octet count of the
public key material would be included as well (see Section 5.5.2). public key material would be included as well (see Section 5.5.2).
The 2-octet checksum that follows the algorithm-specific portion is The 2-octet checksum that follows the algorithm-specific portion is
the algebraic sum, mod 65536, of the plaintext of all the algorithm- the algebraic sum, mod 65536, of the plaintext of all the algorithm-
specific octets (including the MPI prefix and data). With v3 keys, specific octets (including the MPI prefix and data). With version 3
the checksum is stored in the clear. With v4 keys, the checksum is keys, the checksum is stored in the clear. With version 4 keys, the
encrypted like the algorithm-specific data. This value is used to checksum is encrypted like the algorithm-specific data. This value
check that the passphrase was correct. However, this checksum is is used to check that the passphrase was correct. However, this
deprecated, and an implementation SHOULD NOT use it; instead, an checksum is deprecated, and an implementation SHOULD NOT use it;
implementation should use the SHA-1 hash denoted with a usage octet instead, an implementation should use the SHA-1 hash denoted with a
of 254. The reason for this is that there are some attacks that usage octet of 254. The reason for this is that there are some
involve modifying the secret key undetected. If the S2K usage octet attacks that involve modifying the secret key undetected. If the S2K
is 253, no checksum or SHA-1 hash is used, but the authentication tag usage octet is 253, no checksum or SHA-1 hash is used, but the
of the AEAD algorithm follows. authentication tag of the AEAD algorithm follows.
When decrypting the secret key material using any of these schemes When decrypting the secret key material using any of these schemes
(that is, where the usage octet is non-zero), the resulting cleartext (that is, where the usage octet is non-zero), the resulting cleartext
octet stream must be well formed. In particular, an implementation octet stream must be well formed. In particular, an implementation
MUST NOT interpret octets beyond the unwrapped cleartext octet stream MUST NOT interpret octets beyond the unwrapped cleartext octet stream
as part of any of the unwrapped MPI objects. Furthermore, an as part of any of the unwrapped MPI objects. Furthermore, an
implementation MUST reject any secret key material whose cleartext implementation MUST reject any secret key material whose cleartext
length does not align with the lengths of the unwrapped MPI objects length does not align with the lengths of the unwrapped MPI objects
as unusable. as unusable.
5.5.4. Key IDs and Fingerprints 5.5.4. Key IDs and Fingerprints
Every OpenPGP Key has a fingerprint and a key ID. The computation of Every OpenPGP Key has a fingerprint and a Key ID. The computation of
these values differs based on the key version. The fingerprint these values differs based on the key version. The fingerprint
length varies with the key version, but the key ID (which is only length varies with the key version, but the Key ID (which is only
used in v3 PKESK packets; see Section 5.1.1) is always 64 bits. The used in v3 PKESK packets; see Section 5.1.1) is always 64 bits. The
following registry represents the subsections below: following registry represents the subsections below:
+=======+===================+===============+=============+=========+ +=======+===================+===============+=============+=========+
|Key | Fingerprint | Fingerprint | Key ID |Reference| |Key | Fingerprint | Fingerprint | Key ID |Reference|
|Version| | Length | | | |Version| | Length | | |
| | | (Bits) | | | | | | (Bits) | | |
+=======+===================+===============+=============+=========+ +=======+===================+===============+=============+=========+
|3 | MD5(MPIs without | 128 | low 64 bits |Section | |3 | MD5(MPIs without | 128 | low 64 bits |Section |
| | length octets) | | of RSA |5.5.4.1 | | | length octets) | | of RSA |5.5.4.1 |
skipping to change at line 3342 skipping to change at line 3338
+-------+-------------------+---------------+-------------+---------+ +-------+-------------------+---------------+-------------+---------+
|6 | SHA256(normalized | 256 | first 64 |Section | |6 | SHA256(normalized | 256 | first 64 |Section |
| | pubkey packet) | | bits of |5.5.4.3 | | | pubkey packet) | | bits of |5.5.4.3 |
| | | | fingerprint | | | | | | fingerprint | |
+-------+-------------------+---------------+-------------+---------+ +-------+-------------------+---------------+-------------+---------+
Table 12: OpenPGP Key IDs and Fingerprints Registry Table 12: OpenPGP Key IDs and Fingerprints Registry
5.5.4.1. Version 3 Key ID and Fingerprint 5.5.4.1. Version 3 Key ID and Fingerprint
For a v3 key, the 8-octet Key ID consists of the low 64 bits of the For a version 3 key, the 8-octet Key ID consists of the low 64 bits
public modulus of the RSA key. of 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 version 3 key is formed by hashing the body (but
the 2-octet length) of the MPIs that form the key material (public not the 2-octet length) of the MPIs that form the key material
modulus n, followed by exponent e) with MD5. Note that both v3 keys (public modulus n, followed by exponent e) with MD5. Note that both
and MD5 are deprecated. version 3 keys and MD5 are deprecated.
5.5.4.2. Version 4 Key ID and Fingerprint 5.5.4.2. Version 4 Key ID and Fingerprint
A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A version 4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the 2-octet packet length, followed by the entire Public followed by the 2-octet packet length, followed by the entire Public
Key packet starting with the version field. The Key ID is the low- 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 hash order 64 bits of the fingerprint. Here are the fields of the hash
material, including an example of an Ed25519 key: material, including an example of an Ed25519 key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) 2-octet, big-endian scalar octet count of (b)-(e) a.2) 2-octet, big-endian scalar octet count of (b)-(e)
b) version number = 4 (1 octet) b) version number = 4 (1 octet)
skipping to change at line 3376 skipping to change at line 3372
d) algorithm (1 octet): 27 = Ed25519 (example) d) algorithm (1 octet): 27 = Ed25519 (example)
e) algorithm-specific fields e) algorithm-specific fields
Algorithm-specific fields for Ed25519 keys (example): Algorithm-specific fields for Ed25519 keys (example):
e.1) 32 octets representing the public key e.1) 32 octets representing the public key
5.5.4.3. Version 6 Key ID and Fingerprint 5.5.4.3. Version 6 Key ID and Fingerprint
A v6 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9B, A version 6 fingerprint is the 256-bit SHA2-256 hash of the octet
followed by the 4-octet packet length, followed by the entire Public 0x9B, followed by the 4-octet packet length, followed by the entire
Key packet starting with the version field. The Key ID is the high- Public Key packet starting with the version field. The Key ID is the
order 64 bits of the fingerprint. Here are the fields of the hash high-order 64 bits of the fingerprint. Here are the fields of the
material, including an example of an Ed25519 key: hash material, including an example of an Ed25519 key:
a.1) 0x9B (1 octet) a.1) 0x9B (1 octet)
a.2) 4-octet scalar octet count of (b)-(f) a.2) 4-octet scalar octet count of (b)-(f)
b) version number = 6 (1 octet) b) version number = 6 (1 octet)
c) timestamp of key creation (4 octets) c) timestamp of key creation (4 octets)
d) algorithm (1 octet): 27 = Ed25519 (example) d) algorithm (1 octet): 27 = Ed25519 (example)
skipping to change at line 3406 skipping to change at line 3402
Algorithm-specific fields for Ed25519 keys (example): Algorithm-specific fields for Ed25519 keys (example):
f.1) 32 octets representing the public key f.1) 32 octets representing the public key
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 --
that is, two different keys with the same Key ID. Note that there is that is, two different keys with the same Key ID. Note that there is
a much smaller, but still non-zero, probability that two different a much smaller, but still non-zero, probability that two different
keys have the same fingerprint. keys have the same fingerprint.
Also note that if v3, v4, and v6 format keys share the same RSA key Also note that if version 3, version 4, and version 6 format keys
material, they will have different Key IDs as well as different share the same RSA key material, they will have different Key IDs as
fingerprints. well as different fingerprints.
Finally, the Key ID and fingerprint of a subkey are calculated in the Finally, the Key ID and fingerprint of a subkey are calculated in the
same way as for a primary key, including the 0x99 (v4 key) or 0x9B same way as for a primary key, including the 0x99 (version 4 key) or
(v6 key) as the first octet (even though this is not a valid Packet 0x9B (version 6 key) as the first octet (even though this is not a
Type ID for a public subkey). valid Packet Type ID for a public subkey).
5.5.5. Algorithm-Specific Parts of Keys 5.5.5. Algorithm-Specific Parts of Keys
The public and secret key formats specify algorithm-specific parts of The public and secret key formats specify algorithm-specific parts of
a key. The following sections describe them in detail. a key. The following sections describe them in detail.
5.5.5.1. Algorithm-Specific Part for RSA Keys 5.5.5.1. Algorithm-Specific Part for RSA Keys
For RSA keys, the public key consists of this series of For RSA keys, the public key consists of this series of
multiprecision integers: multiprecision integers:
skipping to change at line 3679 skipping to change at line 3675
A ZLIB-compressed series of packets is compressed with raw ZLIB-style A ZLIB-compressed series of packets is compressed with raw ZLIB-style
blocks [RFC1950]. blocks [RFC1950].
A BZip2-compressed series of packets is compressed using the BZip2 A BZip2-compressed series of packets is compressed using the BZip2
[BZ2] algorithm. [BZ2] algorithm.
An implementation that generates a Compressed Data packet MUST use An implementation that generates a Compressed Data packet MUST use
the OpenPGP format for packet framing (see Section 4.2.1). It MUST the OpenPGP format for packet framing (see Section 4.2.1). It MUST
NOT generate a Compressed Data packet with Legacy format NOT generate a Compressed Data packet with Legacy format
(Section 4.2.2) (Section 4.2.2).
An implementation that deals with either historic data or data An implementation that deals with either historic data or data
generated by legacy implementations predating support for [RFC2440] generated by legacy implementations predating support for [RFC2440]
MAY interpret Compressed Data packets that use the Legacy format for MAY interpret Compressed Data packets that use the Legacy format for
packet framing. packet framing.
5.7. Symmetrically Encrypted Data Packet (Type ID 9) 5.7. Symmetrically Encrypted Data Packet (Type ID 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric key algorithm. When it has been decrypted, it contains a symmetric key algorithm. When it has been decrypted, it contains
other packets (usually a Literal Data packet or compressed data other packets (usually a Literal Data packet or compressed data
packet, but in theory, it could be another sequence of packets that packet, but in theory, it could be another sequence of packets that
forms a valid OpenPGP Message. forms a valid OpenPGP Message).
This packet is obsolete. An implementation MUST NOT create this This packet is obsolete. An implementation MUST NOT create this
packet. An implementation SHOULD reject such a packet and stop packet. An implementation SHOULD reject such a packet and stop
processing the message. If an implementation chooses to process the processing the message. If an implementation chooses to process the
packet anyway, it MUST return a clear warning that a non-integrity- packet anyway, it MUST return a clear warning that a non-integrity-
protected packet has been processed. protected packet has been processed.
This packet format is impossible to handle safely in general because This packet format is impossible to handle safely in general because
the ciphertext it provides is malleable. See Section 13.7 about the ciphertext it provides is malleable. See Section 13.7 about
selecting a better OpenPGP encryption container that does not have selecting a better OpenPGP encryption container that does not have
skipping to change at line 3893 skipping to change at line 3889
User Attribute packet. A simple way to do this is by treating the User Attribute packet. A simple way to do this is by treating the
User Attribute packet as a User ID packet with opaque contents, but User Attribute packet as a User ID packet with opaque contents, but
an implementation may use any method desired. an implementation may use any method desired.
The User Attribute packet is made up of one or more attribute The User Attribute packet is made up of one or more attribute
subpackets. Each subpacket consists of a subpacket header and a subpackets. Each subpacket consists of a subpacket header and a
body. The header consists of: body. The header consists of:
* the subpacket length (1, 2, or 5 octets) * the subpacket length (1, 2, or 5 octets)
* the subpacket Type ID (1 octet) * the Subpacket Type ID (1 octet)
and is followed by the subpacket specific data. and is followed by the subpacket specific data.
The following table lists the currently known subpackets: The following table lists the currently known subpackets:
+=========+=============================+================+ +=========+=============================+================+
| ID | Attribute Subpacket | Reference | | ID | Attribute Subpacket | Reference |
+=========+=============================+================+ +=========+=============================+================+
| 0 | Reserved | | | 0 | Reserved | |
+---------+-----------------------------+----------------+ +---------+-----------------------------+----------------+
skipping to change at line 3991 skipping to change at line 3987
and offers some protections against ciphertext malleability. and offers some protections against ciphertext malleability.
Version 2 of this packet contains data encrypted with an AEAD Version 2 of this packet contains data encrypted with an AEAD
construction. This offers a more cryptographically rigorous defense construction. This offers a more cryptographically rigorous defense
against ciphertext malleability. See Section 13.7 for more details against ciphertext malleability. See Section 13.7 for more details
on choosing between these formats. on choosing between these formats.
Any new version of the SEIPD packet should be registered in the Any new version of the SEIPD packet should be registered in the
registry established in Section 10.3.2.1. registry established in Section 10.3.2.1.
5.13.1. Symmetrically Encrypted and Integrity Protected Data Packet 5.13.1. Version 1 Symmetrically Encrypted and Integrity Protected Data
Version 1 Format Packet Format
A Symmetrically Encrypted and Integrity Protected Data packet version A Version 1 Symmetrically Encrypted and Integrity Protected Data
1 consists of: packet consists of:
* A 1-octet version number with value 1. * A 1-octet version number with value 1.
* Encrypted data -- the output of the selected symmetric key cipher * Encrypted data -- the output of the selected symmetric key cipher
operating in CFB mode. operating in CFB mode.
The symmetric cipher used MUST be specified in a Public Key or The symmetric cipher used MUST be specified in a Public Key or
Symmetric Key Encrypted Session Key packet that precedes the Symmetric Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted and Integrity Protected Data packet. In Symmetrically Encrypted and Integrity Protected Data packet. In
either case, the cipher algorithm ID is prefixed to the session key either case, the cipher algorithm ID is prefixed to the session key
skipping to change at line 4048 skipping to change at line 4044
including the prefix data as well as the trailing constant octets including the prefix data as well as the trailing constant octets
0xD3, 0x14, but excluding the last 20 octets containing the SHA-1 0xD3, 0x14, but excluding the last 20 octets containing the SHA-1
hash. The computed SHA-1 hash is then compared with the last 20 hash. The computed SHA-1 hash is then compared with the last 20
octets of plaintext. A mismatch of the hash indicates that the octets of plaintext. A mismatch of the hash indicates that the
message has been modified and MUST be treated as a security problem. message has been modified and MUST be treated as a security problem.
Any failure SHOULD be reported to the user. Any failure SHOULD be reported to the user.
NON-NORMATIVE EXPLANATION NON-NORMATIVE EXPLANATION
The MDC system, as the integrity protection mechanism of the The MDC system, as the integrity protection mechanism of the
Symmetrically Encrypted and Integrity Protected Data packet Version 1 Symmetrically Encrypted and Integrity Protected Data
version 1 is called, was created to provide an integrity mechanism packet is called, was created to provide an integrity mechanism
that is less strong than a signature, yet stronger than bare CFB that is less strong than a signature, yet stronger than bare CFB
encryption. encryption.
CFB encryption has a limitation as damage to the ciphertext will CFB encryption has a limitation as damage to the ciphertext will
corrupt the affected cipher blocks and the block following. corrupt the affected cipher blocks and the block following.
Additionally, if data is removed from the end of a CFB-encrypted Additionally, if data is removed from the end of a CFB-encrypted
block, that removal is undetectable. (Note also that CBC mode has block, that removal is undetectable. (Note also that CBC mode has
a similar limitation, but data removed from the front of the block a similar limitation, but data removed from the front of the block
is undetectable.) is undetectable.)
skipping to change at line 4101 skipping to change at line 4097
hash function. This is not an accident. It is an intentional hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack is an attack that would simple, fast system. (A downgrade attack is an attack that would
replace SHA2-256 with SHA-1, for example. A cross-grade attack replace SHA2-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as RIPEMD-160, would replace SHA-1 with another 160-bit hash, such as RIPEMD-160,
for example.) for example.)
However, no update will be needed because the MDC has been However, no update will be needed because the MDC has been
replaced by the AEAD encryption described in this document. replaced by the AEAD encryption described in this document.
5.13.2. Symmetrically Encrypted and Integrity Protected Data Packet 5.13.2. Version 2 Symmetrically Encrypted and Integrity Protected Data
Version 2 Format Packet Format
A Symmetrically Encrypted and Integrity Protected Data packet version A Version 2 Symmetrically Encrypted and Integrity Protected Data
2 consists of: packet consists of:
* A 1-octet version number with value 2. * A 1-octet version number with value 2.
* A 1-octet cipher algorithm ID. * A 1-octet cipher algorithm ID.
* A 1-octet AEAD algorithm identifier. * A 1-octet AEAD algorithm identifier.
* A 1-octet chunk size. * A 1-octet chunk size.
* 32 octets of salt. The salt is used to derive the message key and * 32 octets of salt. The salt is used to derive the message key and
skipping to change at line 4219 skipping to change at line 4215
(see Section 5.13.2) and Transferable Public Keys (see Section 10.1). (see Section 5.13.2) and Transferable Public Keys (see Section 10.1).
Such a packet MUST be ignored when received. Such a packet MUST be ignored when received.
Its contents SHOULD be random octets to make the length obfuscation Its contents SHOULD be random octets to make the length obfuscation
it provides more robust even when compressed. it provides more robust even when compressed.
An implementation adding padding to an OpenPGP stream SHOULD place An implementation adding padding to an OpenPGP stream SHOULD place
such a packet: such a packet:
* At the end of a v6 Transferable Public Key that is transferred * At the end of a version 6 Transferable Public Key that is
over an encrypted channel (see Section 10.1). transferred over an encrypted channel (see Section 10.1).
* As the last packet of an Optionally Padded Message within a * As the last packet of an Optionally Padded Message within a
Symmetrically Encrypted and Integrity Protected Data packet Version 2 Symmetrically Encrypted and Integrity Protected Data
version 2 (see Section 10.3.1). packet (see Section 10.3.1).
An implementation MUST be able to process Padding packets anywhere An implementation MUST be able to process Padding packets anywhere
else in an OpenPGP stream so that future revisions of this document else in an OpenPGP stream so that future revisions of this document
may specify further locations for padding. may specify further locations for padding.
Policy about how large to make such a packet to defend against Policy about how large to make such a packet to defend against
traffic analysis is beyond the scope of this document. traffic analysis is beyond the scope of this document.
6. Base64 Conversions 6. Base64 Conversions
skipping to change at line 4282 skipping to change at line 4278
The CRC24 footer MUST NOT be generated if it can be determined by the The CRC24 footer MUST NOT be generated if it can be determined by the
context or by the OpenPGP object being encoded that the consuming context or by the OpenPGP object being encoded that the consuming
implementation accepts base64-encoded blocks without a CRC24 footer. implementation accepts base64-encoded blocks without a CRC24 footer.
Notably: Notably:
* An ASCII-armored Encrypted Message packet sequence that ends in a * An ASCII-armored Encrypted Message packet sequence that ends in a
v2 SEIPD packet MUST NOT contain a CRC24 footer. v2 SEIPD packet MUST NOT contain a CRC24 footer.
* An ASCII-armored sequence of Signature packets that only includes * An ASCII-armored sequence of Signature packets that only includes
v6 Signature packets MUST NOT contain a CRC24 footer. version 6 Signature packets MUST NOT contain a CRC24 footer.
* An ASCII-armored Transferable Public Key packet sequence of a v6 * An ASCII-armored Transferable Public Key packet sequence of a
key MUST NOT contain a CRC24 footer. version 6 key MUST NOT contain a CRC24 footer.
* An ASCII-armored keyring consisting of only v6 keys MUST NOT * An ASCII-armored keyring consisting of only version 6 keys MUST
contain a CRC24 footer. NOT contain a CRC24 footer.
Rationale: Previous draft versions of this document stated that the Rationale: Previous draft versions of this document stated that the
CRC24 footer is optional, but the text was ambiguous. In practice, CRC24 footer is optional, but the text was ambiguous. In practice,
very few implementations require the CRC24 footer to be present. very few implementations require the CRC24 footer to be present.
Computing the CRC24 incurs a significant cost, while providing no Computing the CRC24 incurs a significant cost, while providing no
meaningful integrity protection. Therefore, generating it is now meaningful integrity protection. Therefore, generating it is now
discouraged. discouraged.
6.1.1. An Implementation of the CRC24 in "C" 6.1.1. An Implementation of the CRC24 in "C"
skipping to change at line 4443 skipping to change at line 4439
6.2.2.3. "Hash" Armor Header 6.2.2.3. "Hash" Armor Header
The Armor Header Key Hash is deprecated, but some older The Armor Header Key Hash is deprecated, but some older
implementations expect it in messages using the Cleartext Signature implementations expect it in messages using the Cleartext Signature
Framework (Section 7). When present, this Armor Header Key contains Framework (Section 7). When present, this Armor Header Key contains
a comma-separated list of hash algorithms used in the signatures on a comma-separated list of hash algorithms used in the signatures on
message, with digest names as specified in the "Text Name" column in message, with digest names as specified in the "Text Name" column in
Table 23. These headers SHOULD NOT be emitted unless: Table 23. These headers SHOULD NOT be emitted unless:
* the cleartext signed message contains a v4 signature made using a * the cleartext signed message contains a version 4 signature made
SHA2-based digest (SHA224, SHA256, SHA384, or SHA512), and using a SHA2-based digest (SHA224, SHA256, SHA384, or SHA512), and
* the cleartext signed message might be verified by a legacy OpenPGP * the cleartext signed message might be verified by a legacy OpenPGP
implementation that requires this header. implementation that requires this header.
A verifying application MUST decline to validate any signature in a A verifying application MUST decline to validate any signature in a
message with a non-conformant Hash header (that is, a Hash header message with a non-conformant Hash header (that is, a Hash header
that contains anything other than a comma-separated list of hash that contains anything other than a comma-separated list of hash
algorithms). When a conformant Hash header is present, a verifying algorithms). When a conformant Hash header is present, a verifying
application MUST ignore its contents, deferring to the hash algorithm application MUST ignore its contents, deferring to the hash algorithm
indicated in the Embedded Signature. indicated in the Embedded Signature.
skipping to change at line 4859 skipping to change at line 4855
encoded Object Identifier. The first omitted field is 1 octet encoded Object Identifier. The first omitted field is 1 octet
representing the Object Identifier tag, and the second omitted field representing the Object Identifier tag, and the second omitted field
is the length of the Object Identifier body. For example, the is the length of the Object Identifier body. For example, the
complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A
86 48 CE 3D 03 01 07", from which the first entry in the table above 86 48 CE 3D 03 01 07", from which the first entry in the table above
is constructed by omitting the first two octets. Only the truncated is constructed by omitting the first two octets. Only the truncated
sequence of octets is the valid representation of a curve OID. sequence of octets is the valid representation of a curve OID.
The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used
only in version 4 keys and signatures. Implementations MAY implement only in version 4 keys and signatures. Implementations MAY implement
these variants for compatibility with existing v4 key material and these variants for compatibility with existing version 4 key material
signatures. Implementations MUST NOT accept or generate v6 key and signatures. Implementations MUST NOT accept or generate version
material using the deprecated OIDs. 6 key material using the deprecated OIDs.
9.2.1. Curve-Specific Wire Formats 9.2.1. Curve-Specific Wire Formats
Some elliptic curve public key algorithms use different conventions Some elliptic curve public key algorithms use different conventions
for specific fields depending on the curve in use. Each field is for specific fields depending on the curve in use. Each field is
always formatted as an MPI, but with a curve-specific framing. This always formatted as an MPI, but with a curve-specific framing. This
table summarizes those distinctions. table summarizes those distinctions.
+================+========+============+=======+=========+==========+ +================+========+============+=======+=========+==========+
|Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA | |Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA |
skipping to change at line 5094 skipping to change at line 5090
| | | 0x00, 0x04, 0x40 | | | | 0x00, 0x04, 0x40 |
+------------+-------------------------+-------------------------+ +------------+-------------------------+-------------------------+
Table 24: OpenPGP Hash Algorithm Identifiers for RSA Table 24: OpenPGP Hash Algorithm Identifiers for RSA
Signatures' Use of EMSA-PKCS1-v1_5 Padding Registry Signatures' Use of EMSA-PKCS1-v1_5 Padding Registry
Implementations MUST implement SHA2-256. Implementations SHOULD Implementations MUST implement SHA2-256. Implementations SHOULD
implement SHA2-384 and SHA2-512. Implementations MAY implement other implement SHA2-384 and SHA2-512. Implementations MAY implement other
algorithms. Implementations SHOULD NOT create messages that require algorithms. Implementations SHOULD NOT create messages that require
the use of SHA-1, with the exception of computing version 4 key the use of SHA-1, with the exception of computing version 4 key
fingerprints for purposes of the MDC in Symmetrically Encrypted and fingerprints for purposes of the MDC in Version 1 Symmetrically
Integrity Protected Data packets version 1. Implementations MUST NOT Encrypted and Integrity Protected Data packets. Implementations MUST
generate signatures with MD5, SHA-1, or RIPEMD-160. Implementations NOT generate signatures with MD5, SHA-1, or RIPEMD-160.
MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH Implementations MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash
KDF. Implementations MUST NOT generate packets using MD5, SHA-1, or function in an ECDH KDF. Implementations MUST NOT generate packets
RIPEMD-160 as a hash function in an S2K KDF. Implementations MUST using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF.
NOT decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash Implementations MUST NOT decrypt a secret using MD5, SHA-1, or
function in an S2K KDF in a version 6 (or later) packet. RIPEMD-160 as a hash function in an S2K KDF in a version 6 (or later)
Implementations MUST NOT validate any recent signature that depends packet. Implementations MUST NOT validate any recent signature that
on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT validate depends on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT
any old signature that depends on MD5, SHA-1, or RIPEMD-160 unless validate any old signature that depends on MD5, SHA-1, or RIPEMD-160
the signature's creation date predates known weakness of the unless the signature's creation date predates known weakness of the
algorithm used, and the implementation is confident that the message algorithm used, and the implementation is confident that the message
has been in the secure custody of the user the whole time. has been in the secure custody of the user the whole time.
9.6. AEAD Algorithms 9.6. AEAD Algorithms
+=========+==================+==============+====================+ +=========+==================+==============+====================+
| ID | Name | Nonce Length | Authentication Tag | | ID | Name | Nonce Length | Authentication Tag |
| | | (Octets) | Length (Octets) | | | | (Octets) | Length (Octets) |
+=========+==================+==============+====================+ +=========+==================+==============+====================+
| 0 | Reserved | | | | 0 | Reserved | | |
skipping to change at line 5188 skipping to change at line 5184
OpenPGP users may transfer public keys. This section describes the OpenPGP users may transfer public keys. This section describes the
structure of public keys in transit to ensure interoperability. An structure of public keys in transit to ensure interoperability. An
OpenPGP Transferable Public Key is also known as an OpenPGP OpenPGP Transferable Public Key is also known as an OpenPGP
certificate, in order to distinguish it from both its constituent certificate, in order to distinguish it from both its constituent
Public Key packets (Sections 5.5.1.1 and 5.5.1.2) and the underlying Public Key packets (Sections 5.5.1.1 and 5.5.1.2) and the underlying
cryptographic key material. cryptographic key material.
10.1.1. OpenPGP Version 6 Certificate Structure 10.1.1. OpenPGP Version 6 Certificate Structure
The format of an OpenPGP v6 certificate is as follows. Entries in The format of an OpenPGP version 6 certificate is as follows.
square brackets are optional and ellipses indicate repetition. Entries in square brackets are optional and ellipses indicate
repetition.
Primary Key Primary Key
[Revocation Signature...] [Revocation Signature...]
Direct Key Signature... Direct Key Signature...
[User ID or User Attribute [User ID or User Attribute
[Certification Revocation Signature...] [Certification Revocation Signature...]
[Certification Signature...]]... [Certification Signature...]]...
[Subkey [Subkey Revocation Signature...] [Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]... Subkey Binding Signature...]...
[Padding] [Padding]
skipping to change at line 5397 skipping to change at line 5394
Padding Packet. Padding Packet.
In addition to these rules, a Marker packet (Section 5.8) can appear In addition to these rules, a Marker packet (Section 5.8) can appear
anywhere in the sequence. anywhere in the sequence.
10.3.1. Unwrapping Encrypted and Compressed Messages 10.3.1. Unwrapping Encrypted and Compressed Messages
In addition to the above grammar, certain messages can be "unwrapped" In addition to the above grammar, certain messages can be "unwrapped"
to yield new messages. In particular: to yield new messages. In particular:
* Decrypting a Symmetrically Encrypted and Integrity Protected Data * Decrypting a Version 2 Symmetrically Encrypted and Integrity
packet version 2 MUST yield a valid Optionally Padded Message. Protected Data packet MUST yield a valid Optionally Padded
Message.
* Decrypting a Symmetrically Encrypted and Integrity Protected Data * Decrypting a Version 1 Symmetrically Encrypted and Integrity
packet version 1 or -- for historic data -- a Symmetrically Protected Data packet or -- for historic data -- a Symmetrically
Encrypted Data packet MUST yield a valid OpenPGP Message. Encrypted Data packet MUST yield a valid OpenPGP Message.
* Decompressing a Compressed Data packet MUST also yield a valid * Decompressing a Compressed Data packet MUST also yield a valid
OpenPGP Message. OpenPGP Message.
When any unwrapping is performed, the resulting stream of octets is When any unwrapping is performed, the resulting stream of octets is
parsed into a series of OpenPGP packets like any other stream of parsed into a series of OpenPGP packets like any other stream of
octets. The packet boundaries found in the series of octets are octets. The packet boundaries found in the series of octets are
expected to align with the length of the unwrapped octet stream. An expected to align with the length of the unwrapped octet stream. An
implementation MUST NOT interpret octets beyond the boundaries of the implementation MUST NOT interpret octets beyond the boundaries of the
skipping to change at line 5488 skipping to change at line 5486
Table 26: OpenPGP Encrypted Message Packet Versions Registry Table 26: OpenPGP Encrypted Message Packet Versions Registry
An implementation processing an Encrypted Message MUST discard any An implementation processing an Encrypted Message MUST discard any
preceding ESK packet with a version that does not align with the preceding ESK packet with a version that does not align with the
version of the payload. version of the payload.
10.3.2.2. Packet Versions in Signatures 10.3.2.2. Packet Versions in Signatures
OpenPGP Key packets and Signature packets are also versioned. The OpenPGP Key packets and Signature packets are also versioned. The
version of a Signature typically matches the version of the signing version of a Signature typically matches the version of the signing
key. When a v6 key produces a Signature packet, it MUST produce a key. When a version 6 key produces a Signature packet, it MUST
version 6 Signature packet, regardless of the Signature packet type. produce a version 6 Signature packet, regardless of the Signature
When a message is signed or verified using the one-pass construction, packet type. When a message is signed or verified using the one-pass
the version of the One-Pass Signature packet (Section 5.4) should construction, the version of the One-Pass Signature packet
also be aligned to the other versions. (Section 5.4) should also be aligned to the other versions.
Some legacy implementations have produced unaligned signature Some legacy implementations have produced unaligned signature
versions for older key material, which are also described in the versions for older key material, which are also described in the
table below for the purpose of historic interoperability. A table below for the purpose of historic interoperability. A
conforming implementation MUST only generate Signature packets with conforming implementation MUST only generate Signature packets with
version numbers matching rows with "Yes" in the "Generate?" column. version numbers matching rows with "Yes" in the "Generate?" column.
+=====================+================+============+===========+ +=====================+================+============+===========+
| Signing Key Version | Signature | OPS Packet | Generate? | | Signing Key Version | Signature | OPS Packet | Generate? |
| | Packet Version | Version | | | | Packet Version | Version | |
skipping to change at line 5792 skipping to change at line 5790
* 20 octets representing the UTF-8 encoding of the string "Anonymous * 20 octets representing the UTF-8 encoding of the string "Anonymous
Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73
20 53 65 6E 64 65 72 20 20 20 20. 20 53 65 6E 64 65 72 20 20 20 20.
* A variable-length field containing the fingerprint of the * A variable-length field containing the fingerprint of the
recipient encryption subkey identifying the key material that is recipient encryption subkey identifying the key material that is
needed for decryption. For version 4 keys, this field is 20 needed for decryption. For version 4 keys, this field is 20
octets. For version 6 keys, this field is 32 octets. octets. For version 6 keys, this field is 32 octets.
The size in octets of the KDF parameters sequence, as defined above, The size in octets of the KDF parameters sequence, as defined above,
for encrypting to a v4 key is 54 for curve NIST P-256; 51 for curves for encrypting to a version 4 key is 54 for curve NIST P-256; 51 for
NIST P-384 and NIST P-521; 55 for curves brainpoolP256r1, curves NIST P-384 and NIST P-521; 55 for curves brainpoolP256r1,
brainpoolP384r1, and brainpoolP512r1; or 56 for Curve25519Legacy. brainpoolP384r1, and brainpoolP512r1; or 56 for Curve25519Legacy.
For encrypting to a v6 key, the size of the sequence is 66 for curve For encrypting to a version 6 key, the size of the sequence is 66 for
NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67 for curves curve NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67 for
brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1. curves brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1.
The key wrapping method is described in [RFC3394]. The KDF produces The key wrapping method is described in [RFC3394]. The KDF produces
a symmetric key that is used as a KEK as specified in [RFC3394]. a symmetric key that is used as a KEK as specified in [RFC3394].
Refer to Section 11.5.1 for the details regarding the choice of the Refer to Section 11.5.1 for the details regarding the choice of the
KEK algorithm, which SHOULD be one of the three AES algorithms. Key KEK algorithm, which SHOULD be one of the three AES algorithms. Key
wrapping and unwrapping is performed with the default initial value wrapping and unwrapping is performed with the default initial value
of [RFC3394]. of [RFC3394].
To produce the input to the key wrapping method, first concatenate To produce the input to the key wrapping method, first concatenate
the following values: the following values:
skipping to change at line 5820 skipping to change at line 5818
a v3 PKESK packet). a v3 PKESK packet).
* The session key. * The session key.
* A 2-octet checksum of the session key, equal to the sum of the * A 2-octet checksum of the session key, equal to the sum of the
session key octets, modulo 65536. session key octets, modulo 65536.
Then, the above values are padded to an 8-octet granularity using the Then, the above values are padded to an 8-octet granularity using the
method described in [RFC2898]. method described in [RFC2898].
For example, in a v3 Public Key Encrypted Session Key packet, an For example, in a version 3 Public Key Encrypted Session Key packet,
AES-256 session key is encoded as follows, forming a 40-octet an AES-256 session key is encoded as follows, forming a 40-octet
sequence: sequence:
09 k0 k1 ... k31 s0 s1 05 05 05 05 05 09 k0 k1 ... k31 s0 s1 05 05 05 05 05
The octets k0 to k31 above denote the session key, and the octets s0 The octets k0 to k31 above denote the session key, and the octets s0
and s1 denote the checksum of the session key octets. This encoding and s1 denote the checksum of the session key octets. This encoding
allows the sender to obfuscate the size of the symmetric encryption allows the sender to obfuscate the size of the symmetric encryption
key used to encrypt the data. For example, assuming that an AES key used to encrypt the data. For example, assuming that an AES
algorithm is used for the session key, the sender MAY use 21, 13, and algorithm is used for the session key, the sender MAY use 21, 13, and
5 octets of padding for AES-128, AES-192, and AES-256, respectively, 5 octets of padding for AES-128, AES-192, and AES-256, respectively,
to provide the same number of octets, 40 total, as an input to the to provide the same number of octets, 40 total, as an input to the
key wrapping method. key wrapping method.
In a v6 Public Key Encrypted Session Key packet, the symmetric In a version 6 Public Key Encrypted Session Key packet, the symmetric
algorithm is not included, as described in Section 5.1. For example, algorithm is not included, as described in Section 5.1. For example,
an AES-256 session key would be composed as follows: an AES-256 session key would be composed as follows:
k0 k1 ... k31 s0 s1 06 06 06 06 06 06 k0 k1 ... k31 s0 s1 06 06 06 06 06 06
The octets k0 to k31 above again denote the session key, and the The octets k0 to k31 above again denote the session key, and the
octets s0 and s1 denote the checksum. In this case, assuming that an octets s0 and s1 denote the checksum. In this case, assuming that an
AES algorithm is used for the session key, the sender MAY use 22, 14, AES algorithm is used for the session key, the sender MAY use 22, 14,
and 6 octets of padding for AES-128, AES-192, and AES-256, and 6 octets of padding for AES-128, AES-192, and AES-256,
respectively, to provide the same number of octets, 40 total, as an respectively, to provide the same number of octets, 40 total, as an
skipping to change at line 6011 skipping to change at line 6009
stop. See also Section 13.5 regarding differences in reporting stop. See also Section 13.5 regarding differences in reporting
between a decryption error and a padding error. between a decryption error and a padding error.
12.1.3. EMSA-PKCS1-v1_5 12.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding This encoding method is deterministic and only has an encoding
operation. operation.
Input: Input:
Hash = a hash function to be used.
M = message to be encoded. M = message to be encoded.
emLen = intended length of the encoded message in octets, at least emLen = intended length of the encoded message in octets, at least
tLen + 11, where tLen is the octet length of the DER encoding T of tLen + 11, where tLen is the octet length of the DER encoding T of
a certain value computed during the encoding operation. a certain value computed during the encoding operation.
Output: Output:
EM = encoded message; an octet string of length emLen. EM = encoded message; an octet string of length emLen.
skipping to change at line 6034 skipping to change at line 6034
Steps: Steps:
1. Apply the hash function to the message M to produce hash value H: 1. Apply the hash function to the message M to produce hash value H:
H = Hash(M). H = Hash(M).
If the hash function outputs "message too long," output "message If the hash function outputs "message too long," output "message
too long" and stop. too long" and stop.
2. Using the list in Section 9.5, produce an ASN.1 DER value for the 2. Using the list in Section 9.5, produce an ASN.1 DER value for the
hash function used. Let T be the full hash prefix from the list, hash function used. Let T be the Full Hash Prefix from Table 24
concatenated with the hash digest H, and let tLen be the length for the given hash function, concatenated with the hash digest H,
in octets of T. and let tLen be the length in octets of T.
3. If emLen < tLen + 11, output "intended encoded message length too 3. If emLen < tLen + 11, output "intended encoded message length too
short" and stop. short" and stop.
4. Generate an octet string PS consisting of emLen - tLen - 3 octets 4. Generate an octet string PS consisting of emLen - tLen - 3 octets
with hexadecimal value 0xFF. The length of PS will be at least 8 with hexadecimal value 0xFF. The length of PS will be at least 8
octets. octets.
5. Concatenate PS, the hash prefix T, and other padding to form the 5. Concatenate PS, the hash prefix T, and other padding to form the
encoded message EM as encoded message EM as
skipping to change at line 6224 skipping to change at line 6224
12.9. CFB Mode 12.9. CFB Mode
The Cipher Feedback (CFB) mode used in this document is defined in The Cipher Feedback (CFB) mode used in this document is defined in
Section 6.3 of [SP800-38A]. Section 6.3 of [SP800-38A].
The CFB segment size s is equal to the block size of the cipher The CFB segment size s is equal to the block size of the cipher
(i.e., n-bit CFB mode, where n is the block size used). (i.e., n-bit CFB mode, where n is the block size used).
12.10. Private or Experimental Parameters 12.10. Private or Experimental Parameters
S2K Specifier Types, Signature subpacket Type IDs, User Attribute S2K Specifiers, Signature Subpacket Type IDs, User Attribute
subpacket Type IDs, image format IDs, and the various algorithm IDs Subpacket Type IDs, image format IDs, and the various algorithm IDs
described in Section 9 all reserve the range 100 to 110 for Private described in Section 9 all reserve the range 100 to 110 for Private
and Experimental Use. Packet Type IDs reserve the range 60 to 63 for and Experimental Use. Packet Type IDs reserve the range 60 to 63 for
Private and Experimental Use. These are intentionally managed by the Private and Experimental Use. These are intentionally managed by the
Private Use and Experimental Use policies, as described in [RFC8126]. Private Use and Experimental Use policies, as described in [RFC8126].
However, implementations need to be careful with these and promote However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the them to full IANA-managed parameters when they grow beyond the
original, limited system. original, limited system.
12.11. Meta Considerations for Expansion 12.11. Meta Considerations for Expansion
skipping to change at line 6274 skipping to change at line 6274
is assumed that the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties. pair is controlled and secured by the proper party or parties.
* The MD5 and SHA-1 hash algorithms have been found to have * The MD5 and SHA-1 hash algorithms have been found to have
weaknesses, with collisions found in a number of cases. MD5 and weaknesses, with collisions found in a number of cases. MD5 and
SHA-1 are deprecated for use in OpenPGP (see Section 9.5). SHA-1 are deprecated for use in OpenPGP (see Section 9.5).
* 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 version 4 key format with separate signature and
keys. Using a single key for encrypting and signing is encryption keys. Using a single key for encrypting and signing is
discouraged. discouraged.
* The DSA algorithm will work with any hash, but it is sensitive to * The DSA algorithm will work with any hash, but it is sensitive to
the quality of the hash algorithm. Verifiers should be aware that the quality of the hash algorithm. Verifiers should be aware that
even if the signer used a strong hash, an attacker could have even if the signer used a strong hash, an attacker could have
modified the signature to use a weak one. Only signatures using modified the signature to use a weak one. Only signatures using
acceptably strong hash algorithms should be accepted as valid. acceptably strong hash algorithms should be accepted as valid.
* As OpenPGP combines many different asymmetric, symmetric, and hash * As OpenPGP combines many different asymmetric, symmetric, and hash
algorithms, each with different measures of strength, care should algorithms, each with different measures of strength, care should
skipping to change at line 6352 skipping to change at line 6352
should convert an uncertain breakage (where it is unclear what the should convert an uncertain breakage (where it is unclear what the
effect of a collision will be) to an explicit breakage, which is more effect of a collision will be) to an explicit breakage, which is more
desirable for a robust implementation. desirable for a robust implementation.
[STEVENS2013] describes a method for detecting indicators of well- [STEVENS2013] describes a method for detecting indicators of well-
known SHA-1 collision attacks. Some example C code implementing this known SHA-1 collision attacks. Some example C code implementing this
technique can be found at [SHA1CD]. technique can be found at [SHA1CD].
13.2. Advantages of Salted Signatures 13.2. Advantages of Salted Signatures
V6 signatures include a salt that is hashed first, and it's size Version 6 signatures include a salt that is hashed first, and it's
depends on the hashing algorithm. This makes v6 OpenPGP signatures size depends on the hashing algorithm. This makes version 6 OpenPGP
non-deterministic and protects against a broad class of attacks that signatures non-deterministic and protects against a broad class of
depend on creating a signature over a predictable message. By attacks that depend on creating a signature over a predictable
selecting a new random salt for each signature made, the signed message. By selecting a new random salt for each signature made, the
hashes and the signatures are not predictable. signed hashes and the signatures are not predictable.
While the material to be signed could be attacker controlled, hashing While the material to be signed could be attacker controlled, hashing
the salt first means that there is no attacker-controlled hashed the salt first means that there is no attacker-controlled hashed
prefix. An example of this kind of attack is described in the paper prefix. An example of this kind of attack is described in the paper
"SHA-1 is a Shambles" [SHAMBLES], which leverages a chosen prefix "SHA-1 is a Shambles" [SHAMBLES], which leverages a chosen prefix
collision attack against SHA-1. This means that an adversary collision attack against SHA-1. This means that an adversary
carrying out a chosen-message attack will not be able to control the carrying out a chosen-message attack will not be able to control the
hash that is being signed and will need to break second-preimage hash that is being signed and will need to break second-preimage
resistance instead of the simpler collision resistance to create two resistance instead of the simpler collision resistance to create two
messages having the same signature. The size of the salt is bound to messages having the same signature. The size of the salt is bound to
skipping to change at line 6411 skipping to change at line 6411
check. check.
There is a danger when using the quick check if timing or error There is a danger when using the quick check if timing or error
information about the check can be exposed to an attacker, information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated particularly via an automated service that allows rapidly repeated
queries. queries.
Disabling the quick check prevents the attack. Disabling the quick check prevents the attack.
For very large encrypted data whose session key is protected by a For very large encrypted data whose session key is protected by a
passphrase using a version 4 SKESK, the quick check may be convenient passphrase using a v4 SKESK, the quick check may be convenient to the
to the user by informing them early that they typed the wrong user by informing them early that they typed the wrong passphrase.
passphrase. But the implementation should use the quick check with But the implementation should use the quick check with care. The
care. The recommended approach for secure and early detection of recommended approach for secure and early detection of decryption
decryption failure is to encrypt data using v2 SEIPD. If the session failure is to encrypt data using v2 SEIPD. If the session key is
key is public key encrypted, the quick check is not useful as the public key encrypted, the quick check is not useful as the public key
public key encryption of the session key should guarantee that it is encryption of the session key should guarantee that it is the right
the right session key. session key.
The quick check oracle attack is a particular type of attack that The quick check oracle attack is a particular type of attack that
exploits ciphertext malleability. For information about other exploits ciphertext malleability. For information about other
similar attacks, see Section 13.7. similar attacks, see Section 13.7.
13.5. Avoiding Leaks from PKCS#1 Errors 13.5. Avoiding Leaks from PKCS#1 Errors
The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted
PKESK) has been found to be vulnerable to attacks in which a system PKESK) has been found to be vulnerable to attacks in which a system
that allows distinguishing padding errors from other decryption that allows distinguishing padding errors from other decryption
skipping to change at line 6470 skipping to change at line 6470
fingerprint represented as 40 hexadecimal digits, often broken into fingerprint represented as 40 hexadecimal digits, often broken into
groups of four digits with whitespace between each group. groups of four digits with whitespace between each group.
When a human is actively involved, the result of such a verification When a human is actively involved, the result of such a verification
is dubious. There is little evidence that most humans are good at is dubious. There is little evidence that most humans are good at
precise comparison of high-entropy data, particularly when that data precise comparison of high-entropy data, particularly when that data
is represented in compact textual form like a hexadecimal is represented in compact textual form like a hexadecimal
[USENIX-STUDY]. [USENIX-STUDY].
The version 6 fingerprint makes the challenge for a human verifier The version 6 fingerprint makes the challenge for a human verifier
even worse. At 256 bits (compared to v4's 160-bit fingerprint), a v6 even worse. At 256 bits (compared to version 4's 160-bit
fingerprint is even harder for a human to successfully compare. fingerprint), a version 6 fingerprint is even harder for a human to
successfully compare.
An OpenPGP implementation should prioritize mechanical fingerprint An OpenPGP implementation should prioritize mechanical fingerprint
transfer and comparison where possible and SHOULD NOT promote manual transfer and comparison where possible and SHOULD NOT promote manual
transfer or comparison of full fingerprints by a human unless there transfer or comparison of full fingerprints by a human unless there
is no other way to achieve the desired result. is no other way to achieve the desired result.
While this subsection acknowledges existing practice for human- While this subsection acknowledges existing practice for human-
representable v4 fingerprints, this document does not attempt to representable version 4 fingerprints, this document does not attempt
standardize any specific human-readable form of v6 fingerprint for to standardize any specific human-readable form of version 6
this discouraged use case. fingerprint for this discouraged use case.
NOTE: the topic of interoperable human-in-the-loop key verification NOTE: the topic of interoperable human-in-the-loop key verification
needs more work, which will be done in a separate document. needs more work, which will be done in a separate document.
13.7. Avoiding Ciphertext Malleability 13.7. Avoiding Ciphertext Malleability
If ciphertext can be modified by an attacker but still subsequently If ciphertext can be modified by an attacker but still subsequently
decrypted to some new plaintext, it is considered "malleable". A decrypted to some new plaintext, it is considered "malleable". A
number of attacks can arise in any cryptosystem that uses malleable number of attacks can arise in any cryptosystem that uses malleable
encryption, so [RFC4880] and later versions of OpenPGP offer encryption, so [RFC4880] and later versions of OpenPGP offer
skipping to change at line 6529 skipping to change at line 6530
clear error message as soon as the truncation is detected. clear error message as soon as the truncation is detected.
Any of the following OpenPGP data elements indicate that malleable Any of the following OpenPGP data elements indicate that malleable
ciphertext is present: ciphertext is present:
* All Symmetrically Encrypted Data packets (Section 5.7). * All Symmetrically Encrypted Data packets (Section 5.7).
* Within any encrypted container, any Compressed Data packet * Within any encrypted container, any Compressed Data packet
(Section 5.6) where there is a decompression failure. (Section 5.6) where there is a decompression failure.
* Any Symmetrically Encrypted and Integrity Protected Data packet * Any Version 1 Symmetrically Encrypted and Integrity Protected Data
version 1 (Section 5.13.1) where the internal Modification packet (Section 5.13.1) where the internal Modification Detection
Detection Code does not validate. Code does not validate.
* Any Symmetrically Encrypted and Integrity Protected Data packet * Any Version 2 Symmetrically Encrypted and Integrity Protected Data
version 2 (Section 5.13.2) where the authentication tag of any packet (Section 5.13.2) where the authentication tag of any chunk
chunk fails or where there is no final zero-octet chunk. fails or where there is no final zero-octet chunk.
* Any Secret-Key packet with encrypted secret key material * Any Secret-Key packet with encrypted secret key material
(Section 3.7.2.1) where there is an integrity failure, based on (Section 3.7.2.1) where there is an integrity failure, based on
the value of the secret key protection octet: the value of the secret key protection octet:
- Value 253 (AEAD): where the AEAD authentication tag is invalid. - Value 253 (AEAD): where the AEAD authentication tag is invalid.
- Value 254 (CFB): where the SHA1 checksum is mismatched. - Value 254 (CFB): where the SHA1 checksum is mismatched.
- Value 255 (MalleableCFB) or raw cipher algorithm: where the - Value 255 (MalleableCFB) or raw cipher algorithm: where the
skipping to change at line 6557 skipping to change at line 6558
To avoid these circumstances, an implementation that generates To avoid these circumstances, an implementation that generates
OpenPGP encrypted data SHOULD select the encrypted container format OpenPGP encrypted data SHOULD select the encrypted container format
with the most robust protections that can be handled by the intended with the most robust protections that can be handled by the intended
recipients. In particular: recipients. In particular:
* The SED packet is deprecated and MUST NOT be generated. * The SED packet is deprecated and MUST NOT be generated.
* When encrypting to one or more public keys: * When encrypting to one or more public keys:
- If all recipient keys indicate support for Symmetrically - If all recipient keys indicate support for a Version 2
Encrypted and Integrity Protected Data packet version 2 in Symmetrically Encrypted and Integrity Protected Data packet in
their Features subpacket (Section 5.2.3.32), if all recipient their Features signature subpacket (Section 5.2.3.32), if all
keys are version 6 keys without a Features subpacket, or the recipient keys are version 6 keys without a Features signature
implementation can otherwise infer that all recipients support subpacket, or the implementation can otherwise infer that all
v2 SEIPD packets, the implementation SHOULD encrypt using a v2 recipients support v2 SEIPD packets, the implementation SHOULD
SEIPD packet. encrypt using a v2 SEIPD packet.
- If one of the recipients does not support v2 SEIPD packets, - If one of the recipients does not support v2 SEIPD packets,
then the message generator MAY use a v1 SEIPD packet instead. then the message generator MAY use a v1 SEIPD packet instead.
* Passphrase-protected secret key material in a version 6 Secret Key * Passphrase-protected secret key material in a version 6 Secret Key
or version 6 Secret Subkey packet SHOULD be protected with AEAD or version 6 Secret Subkey packet SHOULD be protected with AEAD
encryption (S2K usage octet 253) unless it will be transferred to encryption (S2K usage octet 253) unless it will be transferred to
an implementation that is known to not support AEAD. An an implementation that is known to not support AEAD. An
implementation should be aware that, in scenarios where an implementation should be aware that, in scenarios where an
attacker has write access to encrypted private keys, CFB-encrypted attacker has write access to encrypted private keys, CFB-encrypted
skipping to change at line 6671 skipping to change at line 6672
keys for any specific context. An implementer that intends to make keys for any specific context. An implementer that intends to make
use of this feature should publish their own proposed guidance for use of this feature should publish their own proposed guidance for
others to review. others to review.
13.9. Escrowed Revocation Signatures 13.9. Escrowed Revocation Signatures
A keyholder, Alice, may wish to designate a third party to be able to A keyholder, Alice, may wish to designate a third party to be able to
revoke her own key. revoke her own key.
The preferred way for Alice to do this is to produce a specific The preferred way for Alice to do this is to produce a specific
Revocation Signature (signature Type IDs 0x20, 0x28, or 0x30) and Revocation Signature (Signature Type ID 0x20, 0x28, or 0x30) and
distribute it securely to a preferred revoker who can hold it in distribute it securely to a preferred revoker who can hold it in
escrow. The preferred revoker can then publish the escrowed escrow. The preferred revoker can then publish the escrowed
Revocation Signature at whatever time is deemed appropriate rather Revocation Signature at whatever time is deemed appropriate rather
than generating the Revocation Signature themselves. than generating the Revocation Signature themselves.
There are multiple advantages of using an escrowed Revocation There are multiple advantages of using an escrowed Revocation
Signature over the deprecated Revocation Key subpacket Signature over the deprecated Revocation Key subpacket
(Section 5.2.3.23): (Section 5.2.3.23):
* The keyholder can constrain what types of revocation the preferred * The keyholder can constrain what types of revocation the preferred
skipping to change at line 6819 skipping to change at line 6820
This section is a collection of comments to help an implementer who This section is a collection of comments to help an implementer who
has a particular interest in backward compatibility. Often the has a particular interest in backward compatibility. 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
to achieve backward compatibility. to achieve backward compatibility.
* There are many possible ways for two keys to have the same key * There are many possible ways for two keys to have the same key
material but different fingerprints (and thus different Key IDs). material but different fingerprints (and thus different Key IDs).
For example, since a v4 fingerprint is constructed by hashing the For example, since a version 4 fingerprint is constructed by
key creation time along with other things, two v4 keys created at hashing the key creation time along with other things, two version
different times yet with the same key material will have different 4 keys created at different times yet with the same key material
fingerprints. will have different fingerprints.
* OpenPGP does not put limits on the size of public keys. However, * OpenPGP does not put limits on the size of public keys. However,
larger keys are not necessarily better keys. Larger keys take larger keys are not necessarily better keys. Larger keys take
more computation time to use, and this can quickly become more computation time to use, and this can quickly become
impractical. Different OpenPGP implementations may also use impractical. Different OpenPGP implementations may also use
different upper bounds for public key sizes, so care should be different upper bounds for public key sizes, so care should be
taken when choosing sizes to maintain interoperability. taken when choosing sizes to maintain interoperability.
* ASCII Armor is an optional feature of OpenPGP. The OpenPGP * ASCII Armor is an optional feature of OpenPGP. The OpenPGP
Working Group strives for a minimal set of mandatory-to-implement Working Group strives for a minimal set of mandatory-to-implement
skipping to change at line 6855 skipping to change at line 6856
necessarily have support. necessarily have support.
* What this document calls the "Legacy packet format" * What this document calls the "Legacy packet format"
(Section 4.2.2) is what older documents called the "old packet (Section 4.2.2) is what older documents called the "old packet
format". It is the packet format used by implementations format". It is the packet format used by implementations
predating [RFC2440]. The current "OpenPGP packet format" predating [RFC2440]. The current "OpenPGP packet format"
(Section 4.2.1) was called the "new packet format" by older RFCs. (Section 4.2.1) was called the "new packet format" by older RFCs.
This is the format introduced in [RFC2440] and maintained through This is the format introduced in [RFC2440] and maintained through
[RFC4880] to this document. [RFC4880] to this document.
14.1. Constrained Legacy Fingerprint Storage for v6 Keys 14.1. Constrained Legacy Fingerprint Storage for Version 6 Keys
Some OpenPGP implementations have fixed length constraints for key Some OpenPGP implementations have fixed length constraints for key
fingerprint storage that will not fit all 32 octets of a version 6 fingerprint storage that will not fit all 32 octets of a version 6
fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each
stored fingerprint. stored fingerprint.
An OpenPGP implementation MUST NOT attempt to map any part of a An OpenPGP implementation MUST NOT attempt to map any part of a
version 6 fingerprint to such a constrained field unless the relevant version 6 fingerprint to such a constrained field unless the relevant
specification for the constrained environment has explicit guidance specification for the constrained environment has explicit guidance
for storing a version 6 fingerprint that distinguishes it from a for storing a version 6 fingerprint that distinguishes it from a
skipping to change at line 7639 skipping to change at line 7640
-----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S
ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE
-----END PGP SIGNATURE----- -----END PGP SIGNATURE-----
A.3. Sample v6 Certificate (Transferable Public Key) A.3. Sample v6 Certificate (Transferable Public Key)
Here is a Transferable Public Key consisting of: Here is a Transferable Public Key consisting of:
* A v6 Ed25519 Public Key packet * A version 6 Ed25519 Public Key packet
* A v6 Direct Key self-signature * A version 6 Direct Key self-signature
* A v6 X25519 Public Subkey packet * A version 6 X25519 Public Subkey packet
* A v6 Subkey Binding signature * A version 6 Subkey Binding signature
The primary key has the following fingerprint: The primary key has the following fingerprint:
CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9 CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9
The subkey has the following fingerprint: The subkey has the following fingerprint:
12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885 12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885
-----BEGIN PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK-----
skipping to change at line 7741 skipping to change at line 7742
0x0063 0a 0e Hashes: [SHA2-512 SHA3-512 0x0063 0a 0e Hashes: [SHA2-512 SHA3-512
0x0065 08 0c SHA2-256 SHA3-256] 0x0065 08 0c SHA2-256 SHA3-256]
0x0067 02 subpkt length 0x0067 02 subpkt length
0x0068 16 subpkt type: Pref. Compression 0x0068 16 subpkt type: Pref. Compression
0x0069 00 Compression: [none] 0x0069 00 Compression: [none]
0x006a 02 subpkt length 0x006a 02 subpkt length
0x006b 9b critical subpkt: Key Flags 0x006b 9b critical subpkt: Key Flags
0x006c 03 Key Flags: {certify, sign} 0x006c 03 Key Flags: {certify, sign}
0x006d 02 subpkt length 0x006d 02 subpkt length
0x006e 1e subpkt type: Features 0x006e 1e subpkt type: Features
0x006f 09 Features: {SEIPDv1, SEIPDv2} 0x006f 09 Features: {v1SEIPD, v2SEIPD}
0x0070 22 subpkt length 0x0070 22 subpkt length
0x0071 21 subpkt type: Issuer Fingerprint 0x0071 21 subpkt type: Issuer Fingerprint
0x0072 06 Fingerprint version 6 0x0072 06 Fingerprint version 6
0x0073 cb 18 6c 4f 06 Fingerprint 0x0073 cb 18 6c 4f 06 Fingerprint
0x0078 09 a6 97 e4 d5 2d fa 6c 0x0078 09 a6 97 e4 d5 2d fa 6c
0x0080 72 2b 0c 1f 1e 27 c1 8a 0x0080 72 2b 0c 1f 1e 27 c1 8a
0x0088 56 70 8f 65 25 ec 27 ba 0x0088 56 70 8f 65 25 ec 27 ba
0x0090 d9 ac c9 0x0090 d9 ac c9
0x0093 05 subpkt length 0x0093 05 subpkt length
0x0094 27 subpkt type: Pref. AEAD Ciphersuites 0x0094 27 subpkt type: Pref. AEAD Ciphersuites
skipping to change at line 7845 skipping to change at line 7846
0x00a8 70 8f 65 25 ec 27 ba d9 0x00a8 70 8f 65 25 ec 27 ba d9
0x00b0 ac c9 0x00b0 ac c9
0x00b2 06 sig version 0x00b2 06 sig version
0x00b3 ff sentinel octet 0x00b3 ff sentinel octet
0x00b4 00 00 00 34 trailer length 0x00b4 00 00 00 34 trailer length
A.4. Sample v6 Secret Key (Transferable Secret Key) A.4. Sample v6 Secret Key (Transferable Secret Key)
Here is a Transferable Secret Key consisting of: Here is a Transferable Secret Key consisting of:
* A v6 Ed25519 Secret Key packet * A version 6 Ed25519 Secret Key packet
* A v6 Direct Key self-signature * A version 6 Direct Key self-signature
* A v6 X25519 Secret Subkey packet * A version 6 X25519 Secret Subkey packet
* A v6 Subkey Binding signature * A version 6 Subkey Binding signature
-----BEGIN PGP PRIVATE KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB
exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ
BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6 BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh 2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh
RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe
7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/ 7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/
LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG
skipping to change at line 8811 skipping to change at line 8812
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
A.12. Sample Messages Encrypted Using Argon2 A.12. Sample Messages Encrypted Using Argon2
These messages are the literal data Hello, world! encrypted using v1 These messages are the literal data Hello, world! encrypted using v1
SEIPD, with Argon2 and the passphrase "password", using different SEIPD, with Argon2 and the passphrase "password", using different
session key sizes. In each example, the choice of symmetric cipher session key sizes. In each example, the choice of symmetric cipher
is the same in both the v4 SKESK packet and v1 SEIPD packet. In all is the same in both the v4 SKESK packet and v1 SEIPD packet. In all
cases, the Argon2 parameters are t = 1, p = 4, and m = 21. cases, the Argon2 parameters are t = 1, p = 4, and m = 21.
A.12.1. Version 4 SKESK Using Argon2 with AES-128 A.12.1. v4 SKESK Using Argon2 with AES-128
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 128-bit key Comment: Encrypted using AES with 128-bit key
Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F
wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+ wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+
YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH
XfA3pqV4mTzF XfA3pqV4mTzF
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
A.12.2. Version 4 SKESK Using Argon2 with AES-192 A.12.2. v4 SKESK Using Argon2 with AES-192
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 192-bit key Comment: Encrypted using AES with 192-bit key
Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955... Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955...
Comment: Session key: ...AF8DFE194 Comment: Session key: ...AF8DFE194
wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw
F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys
LVg77Mwwfgl2n/d572WciAM= LVg77Mwwfgl2n/d572WciAM=
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
A.12.3. Version 4 SKESK Using Argon2 with AES-256 A.12.3. v4 SKESK Using Argon2 with AES-256
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 256-bit key Comment: Encrypted using AES with 256-bit key
Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF... Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF...
Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0 Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0
wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu
623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K 623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K
95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ== 95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ==
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
skipping to change at line 8892 skipping to change at line 8893
o OCB mode (Section 5.13.4) -- MTI o OCB mode (Section 5.13.4) -- MTI
o EAX mode (Section 5.13.3) o EAX mode (Section 5.13.3)
o GCM mode (Section 5.13.5) o GCM mode (Section 5.13.5)
- Version 6 PKESK (Section 5.1.2) - Version 6 PKESK (Section 5.1.2)
- Version 6 SKESK (Section 5.3.2) - Version 6 SKESK (Section 5.3.2)
- Features subpacket: add flag for SEIPDv2 (Section 5.2.3.32) - Features signature subpacket: add flag for v2 SEIPD
(Section 5.2.3.32)
- Subpacket: Preferred AEAD Ciphersuites (Section 5.2.3.15) - Signature Subpacket: Preferred AEAD Ciphersuites
(Section 5.2.3.15)
- Secret key encryption: AEAD "S2K usage octet" (Sections 3.7.2 - Secret key encryption: AEAD "S2K usage octet" (Sections 3.7.2
and 5.5.3) and 5.5.3)
* Version 6 Keys and Signatures: * Version 6 Keys and Signatures:
- Version 6 Public Keys (Section 5.5.2.3) - Version 6 Public Keys (Section 5.5.2.3)
- Version 6 Fingerprint and Key ID (Section 5.5.4.3) - Version 6 Fingerprint and Key ID (Section 5.5.4.3)
skipping to change at line 8951 skipping to change at line 8954
Curve25519Legacy (Section 9.2) Curve25519Legacy (Section 9.2)
- Digest Algorithms: - Digest Algorithms:
o Avoid MD5, SHA1, and RIPEMD160 (Section 9.5) o Avoid MD5, SHA1, and RIPEMD160 (Section 9.5)
- Symmetric Key Algorithms: - Symmetric Key Algorithms:
o Avoid IDEA, TripleDES, and CAST5 (Section 9.3) o Avoid IDEA, TripleDES, and CAST5 (Section 9.3)
- S2K Specifier Type: - S2K Specifier:
o Avoid Simple S2K (Section 3.7.1.1) o Avoid Simple S2K (Section 3.7.1.1)
- Secret Key Protections (a.k.a. S2K Usage): - Secret Key Protections (a.k.a. S2K Usage):
o Avoid MalleableCFB (Section 3.7.2.1) o Avoid MalleableCFB (Section 3.7.2.1)
- Packet Types: - Packet Types:
o Avoid Symmetrically Encrypted Data (Sections 5.7 and 13.7) o Avoid Symmetrically Encrypted Data (Sections 5.7 and 13.7)
skipping to change at line 9027 skipping to change at line 9030
* "Certificate" was used ambiguously to mean multiple things. In * "Certificate" was used ambiguously to mean multiple things. In
this document, it means "Transferable Public Key" exclusively. this document, it means "Transferable Public Key" exclusively.
* "Preferred Symmetric Algorithms" was the old name for the * "Preferred Symmetric Algorithms" was the old name for the
"Preferred Symmetric Ciphers for v1 SEIPD" subpacket "Preferred Symmetric Ciphers for v1 SEIPD" subpacket
(Section 5.2.3.14). (Section 5.2.3.14).
* "Modification Detection Code" or "MDC" was originally described as * "Modification Detection Code" or "MDC" was originally described as
a distinct packet (Packet Type ID 19), and its corresponding flag a distinct packet (Packet Type ID 19), and its corresponding flag
in the Features subpacket (Section 5.2.3.32) was known as in the Features signature subpacket (Section 5.2.3.32) was known
"Modification Detection". It is now described as an intrinsic as "Modification Detection". It is now described as an intrinsic
part of v1 SEIPD (Section 5.13.1), and the same corresponding flag part of v1 SEIPD (Section 5.13.1), and the same corresponding flag
is known as "Symmetrically Encrypted and Integrity Protected Data is known as "Version 1 Symmetrically Encrypted and Integrity
packet version 1". Protected Data packet".
* "Packet Tag" was used to refer to the Packet Type ID (Section 5) * "Packet Tag" was used to refer to the Packet Type ID (Section 5)
or sometimes to the encoded Packet Type ID (Section 4.2). or sometimes to the encoded Packet Type ID (Section 4.2).
Appendix C. Errata Addressed by This Document Appendix C. Errata Addressed by This Document
The following verified errata have been incorporated or are otherwise The following verified errata have been incorporated or are otherwise
resolved by this document: resolved by this document:
* [Errata-2199] - S2K hash/cipher octet correction * [Errata-2199] - S2K hash/cipher octet correction
 End of changes. 128 change blocks. 
342 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.48.