OpenPGP
obsoletes
Extracted elements (34)
Argon2 is preferred over Iterated and Salted S2K because it provides memory hardness, making dictionary attacks on passphrases significantly more expensive. Iterated and Salted S2K increases computational cost only and offers no memory-hardness guarantee.
The vagueness of OpenPGP certification signature types (0x10–0x13) is intentional: because the system places final authority for validity upon the receiver, a signer's casual Generic Certification may be treated as more rigorous than another authority's Positive Certification.
Version 6 signatures add a mandatory random salt to the hash input to prevent chosen-prefix collision attacks: an attacker who can craft a SHA-x collision would also need to predict or control the salt, making collision-based signature forgeries impractical.
EdDSALegacy (the Ed25519/Ed448 encoding inherited from RFC 4880/6637) is deprecated and MUST NOT be used in version 6 or later Signature or Key packets. New implementations should use the native Ed25519 (algorithm ID 27) and Ed448 (algorithm ID 28) types defined in this document.
A Subkey Binding Signature (Type ID 0x18) that binds a signing subkey MUST have an Embedded Signature subpacket containing a Primary Key Binding Signature (Type ID 0x19) made by the signing subkey on the primary key and subkey.
A v3 PKESK packet MUST NOT precede a v2 SEIPD packet, and a v6 PKESK packet MUST NOT precede a v1 SEIPD packet or a deprecated SED packet. PKESK packet version must align with the SEIPD packet version.
An Ed25519 signature MUST use a hash algorithm with a digest size of at least 256 bits; Ed448 MUST use at least 512 bits. An ECDSA signature MUST use a hash algorithm whose digest size is at least the curve's fsize value. Verifying implementations MUST reject signatures that violate these constraints.
An implementation MUST generate a version 6 signature when signing with a version 6 key, and MUST generate a version 4 signature when signing with a version 4 key. Implementations MUST NOT create version 3 signatures; they MAY accept version 3 signatures for backward compatibility.
An implementation MUST NOT create 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. Argon2 is only valid in combination with AEAD-protected secret keys.
An implementation MUST NOT generate a Legacy format packet with indeterminate length (length-type 3). The Legacy packet format SHOULD NOT be used to generate new data; it is permitted only for consuming historical data.
If an implementation encounters a critical packet (Type ID 0–39) with an unknown type in a packet sequence, it MUST reject the whole packet sequence. Unknown non-critical packets (Type IDs 40–63) MUST be ignored.
When emitting a secret key, an implementation MUST only produce data from S2K usage rows marked 'Generate? Yes'. Rows for LegacyCFB and MalleableCFB are read-only for backward compatibility, MUST NOT be generated, and MUST be rejected in version 6 keys.
When forming multiple PKESK packets for one session key (multi-recipient message), the implementation MUST make a new PKCS#1 EME-PKCS1-v1_5 encoding for each recipient key, defending against Hastad's broadcast attack.
When generating an S2K Specifier, an implementation MUST NOT use Simple S2K. Implementations SHOULD NOT generate Salted S2K unless the input is known to be high entropy. It is RECOMMENDED that implementations use Argon2; if unavailable, Iterated and Salted S2K MAY be used with a high octet count.
When parsing an MPI in a version 6 Key, Signature, or PKESK packet, the implementation MUST check that the encoded bit-length matches the length starting from the most significant non-zero bit; if it does not match, reject the packet as malformed. Unused bits of an MPI MUST be zero.
A v6 PKESK packet MAY omit the key fingerprint (zero-size field) to create an 'anonymous recipient'. The receiver tries all available private keys, hiding the intended decryption key from traffic analysis. Similarly, a v3 PKESK MAY use an all-zeros Key ID.
OpenPGP defines 15 Signature Type IDs including Binary (0x00), Text (0x01), Generic/Persona/Casual/Positive Certification (0x10–0x13), Subkey Binding (0x18), Primary Key Binding (0x19), Key Revocation (0x20), and Subkey Revocation (0x28). Type ID 0xFF is reserved and MUST NOT be created or validated.
The Padding Packet (Type ID 21) is a new non-data packet containing random octets. It allows implementations to obscure the size of OpenPGP messages as a traffic analysis countermeasure.
The Signature packet (Type ID 2) supports versions 3, 4, and 6. Versions 4 and 6 use an extensible subpacket system divided into hashed (cryptographically protected) and unhashed (advisory) sections. Version 6 adds a mandatory random salt and wider subpacket length fields (4-octet vs 2-octet).
The Symmetrically Encrypted and Integrity Protected Data packet (Type ID 18, SEIPD) has two versions: v1 uses CFB mode with SHA-1 Modification Detection Code; v2 uses AEAD (EAX, OCB, or GCM). v2 SEIPD is paired exclusively with v6 PKESK/SKESK packets and provides authenticated encryption.
IANA maintains the 'OpenPGP Packet Types' registry (formerly 'PGP Packet Types') with Type IDs 0–63. IDs 0–39 are critical; 40–63 are non-critical. This document defines packet types including the new Padding Packet (ID 21) and reserves IDs 20 and 22–39.
IANA maintains the 'OpenPGP Signature Types' registry with 15 defined type IDs from 0x00 to 0xFF, and the 'OpenPGP Secret Key Encryption (S2K Usage Octet)' registry defining values 0 (Unprotected), 253 (AEAD), 254 (CFB), and 255 (MalleableCFB). Both registries were renamed and updated from RFC 4880 predecessors.
IANA maintains the 'OpenPGP String-to-Key (S2K) Types' registry with types 0 (Simple), 1 (Salted), 3 (Iterated and Salted), and 4 (Argon2, new in this document). IDs 100–110 are reserved for Private or Experimental Use. Generation of types 0 and 1 is prohibited for new output.
Compressed data packets can cause resource exhaustion ('zip bomb') attacks. Implementations should impose limits on decompressed data size and abort on pathological compression ratios.
Implementations must avoid leaking information from PKCS#1 decoding errors during RSA session key decryption. Timing or error-type side channels create a Bleichenbacher-style oracle that enables plaintext recovery of the session key.
Only subpackets in the hashed section of a Signature packet are cryptographically protected. Unhashed subpackets such as Issuer Key ID can be modified by any third party and must be treated as advisory information only; implementations should not rely on them for security decisions.
SHA-1 is vulnerable to collision attacks; implementations should apply collision-detection techniques when verifying SHA-1-based signatures. OpenPGP version 6 salted signatures mitigate chosen-prefix collision attacks for new signatures.
Surreptitious forwarding: a recipient of an encrypted-and-signed message can strip the signature and re-encrypt to a different recipient, who may incorrectly believe the original signer intended them as the recipient. The Intended Recipient Fingerprint subpacket (when verified) mitigates this attack.
A Multiprecision Integer (MPI) encodes large integers as a 2-octet big-endian bit-length field followed by the minimal octet string representing the value. Total wire size is ((MPI.length + 7) / 8) + 2 octets. MPIs also encode EC points and fixed-length octet strings in some contexts.
The Argon2 S2K specifier (type 0x04) is 20 octets: 1 octet type ID, 16 octets of salt, 1 octet number of passes t, 1 octet degree of parallelism p, and 1 octet encoded_m where memory size m = 2^(encoded_m) KiB. Argon2id variant with version 0x13 is always used.
The Version 6 PKESK packet identifies the recipient by a 1-octet key version number and variable-length fingerprint (32 octets for v6 keys, 20 for v4 keys), preceded by a 1-octet size field. This replaces the 8-octet Key ID used in v3 PKESK.
Version 6 key fingerprint is computed as SHA-256 of a specific octet sequence and is 32 octets long. Version 4 fingerprints are SHA-1 (20 octets). Version 3 fingerprints use MD5 (16 octets). Implementations SHOULD NOT assume Key IDs (8-octet truncations of fingerprints) are unique.
Version 6 signatures include a salt field immediately before the signature MPIs: a 1-octet salt size (defined per hash algorithm in Table 23) followed by a random salt of that size. This field is absent in version 4 signatures.
X25519 encryption fields: 32 octets ephemeral public key, 1-octet size, optional 1-octet symmetric algorithm ID (v3 PKESK only), encrypted session key. Key derivation uses HKDF-SHA256 with info 'OpenPGP X25519' over the concatenation of ephemeral key, recipient key, and shared secret; output wraps session key with AES-128 key wrap.