OpenPGP Message Format
obsoleted by
- rfc-4880 — OpenPGP Message Format
Extracted elements (30)
A Key ID of zero MAY be used as a 'wild card' or 'speculative' Key ID in a PKESK packet, causing the receiver to try all available private keys to find a valid session key. This design reduces traffic analysis by concealing which recipient's key was targeted.
The four PGP certification types (0x10 generic, 0x11 persona, 0x12 casual, 0x13 positive) are intentionally vague. Because PGP places final validity authority on the receiver, one authority's casual certification may be more rigorous than another's positive certification; the classifications enable fine-grained trust claims without dictating interpretation.
The Iterated-and-Salted S2K type encodes the iteration count in a single octet using the formula count = (16 + (c & 15)) << ((c >> 4) + 6), providing a wide range of hash-work levels in minimal space. This compactly represents counts large enough to significantly impede dictionary attacks.
PGP 2.6.x only accepts V3 signatures and old-format packet headers, and will not accept key-material packets with version numbers greater than 3. One-Pass Signature packets (Tag 4) do not interoperate with PGP 2.6.x or earlier; software targeting that version must avoid them.
ZIP-compressed packets use raw RFC 1951 DEFLATE blocks. PGP V2.6 uses 13-bit compression; implementations using more bits produce output that PGP V2.6 cannot decompress. ZLIB-compressed packets (RFC 1950) and BZip2 are not compatible with PGP V2.6.
DSA signatures MUST use hash algorithms producing 160-bit output, matching q, the order of the group generated by the DSA key's generator. The hash result is used directly as a 160-bit number in the DSA algorithm.
If an evaluating implementation encounters a critical subpacket (bit 7 of type octet set) that it does not recognize, it SHOULD consider the signature to be in error. Unknown non-critical subpackets SHOULD be silently ignored.
Implementations MUST accept V3 signatures and SHOULD generate V4 signatures. Implementations MAY generate V3 signatures for backward compatibility with PGP 2.6.x.
Implementations SHOULD use salted or iterated-and-salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks.
Marker packets (Tag 10, body = the three octets 0x50 0x47 0x50 spelling 'PGP') MUST be ignored when received. They may be placed at the beginning of a message using features unavailable in PGP 2.6.x to trigger a 'newer software required' message from that implementation.
Partial Body Length headers MUST NOT be used for packet types other than literal, compressed, or encrypted data packets. The first partial body length MUST be at least 512 octets. The last length header in any packet MUST NOT be a Partial Body Length header.
Trust packets (Tag 12) SHOULD NOT be emitted to output streams transferred to other users, and SHOULD be ignored on any input other than local keyring files, as they contain local-only trust state.
V2 key packets MUST NOT be generated. An implementation MUST NOT create a V3 key with a public key algorithm other than RSA. Implementations SHOULD create version 4 keys, which correct security deficiencies present in V3 keys.
When a Symmetric-Key ESK packet's session key field is encrypted with CFB using an all-zero IV, the S2K specifier used MUST include a salt value (Salted or Iterated-Salted S2K) to ensure the derived key is not repeated when the passphrase is reused.
When forming multiple PKESK packets that share one session key (for multiple recipients), an implementation MUST generate new PKCS-1 block type 02 padding for each key individually.
The Literal Data Packet (Tag 11) supports a special file name '_CONSOLE', indicating the data is 'for your eyes only' and should be handled with extra care, such as avoiding writing the data to disk. This is a convention for marking unusually sensitive message content.
Three S2K specifier types convert passphrases to symmetric keys: Simple (type 0x00, direct hash of passphrase), Salted (type 0x01, 8-octet salt prepended before hashing), and Iterated-and-Salted (type 0x03, 8-octet salt plus an exponentially-encoded octet count for repeated hashing). All are used to encrypt private key material and symmetric-key ESK packets.
V4 signature subpackets include: signature creation time (type 2, MUST appear in hashed area), issuer key ID (type 16), key expiration time (type 9), preferred symmetric/hash/compression algorithm lists (types 11/21/22), trust signature (type 5), revocation key (type 12), key flags (type 27), and reason for revocation (type 29). Bit 7 of the subpacket type byte is the 'critical' flag.
Algorithm identifier constants defined: Public Key (1=RSA enc+sign, 2=RSA enc-only, 3=RSA sign-only, 16=Elgamal, 17=DSA); Symmetric Key (1=IDEA, 2=3DES, 3=CAST5, 4=Blowfish, 7=AES-128, 8=AES-192, 9=AES-256, 10=Twofish-256); Hash (1=MD5, 2=SHA-1, 3=RIPEMD-160, 8=SHA-256); Compression (0=uncompressed, 1=ZIP, 2=ZLIB). New tag values require IESG Security Area review.
Packet tags 0–14 are defined: 0=Reserved, 1=Public-Key ESK, 2=Signature, 3=Symmetric-Key ESK, 4=One-Pass Signature, 5=Secret Key, 6=Public Key, 7=Secret Subkey, 8=Compressed Data, 9=Symmetrically Encrypted Data, 10=Marker, 11=Literal Data, 12=Trust, 13=User ID, 14=Public Subkey; tags 60–63 are private or experimental. Tag 0 MUST NOT appear.
The 10-octet random prefix prepended before CFB encryption, where octets 9 and 10 repeat octets 7 and 8, allows the receiver to immediately detect an incorrect session key. The repetition of 16 bits in 80 random bits acts as a fast integrity check without requiring full decryption.
V3 keys have three weaknesses relative to V4: (1) the Key ID is the low 64 bits of the RSA modulus, making collision construction feasible; (2) the fingerprint hashes key material but not its length, increasing collision risk; (3) V3 keys always use MD5, which has known weaknesses. V4 keys correct all three deficiencies.
Each OpenPGP packet begins with a Packet Tag octet: bit 7 must always be 1; bit 6 selects old (0) or new (1) format. Old format encodes content tag in bits 5–2 and length-type in bits 1–0; new format encodes content tag in bits 5–0 with body length following separately.
Multi-Precision Integers (MPIs) encode large integers as a two-octet bit-length scalar followed by big-endian integer octets. Total size is ((MPI.length + 7) / 8) + 2 octets. The length counts from the most significant non-zero bit; leading zero bits are not permitted.
New-format packet body lengths use four encodings: one-octet for 0–191, two-octet for 192–8383 (bodyLen = ((1st - 192) << 8) + 2nd + 192), five-octet for up to 0xFFFFFFFF (first octet 0xFF then four-octet scalar), and partial body lengths (first octet 224–254, body portion = 1 << (octet & 0x1F)) for indeterminate-length streaming.
Secret Key Packet appends to Public Key data: S2K usage octet (0=unencrypted, 255=S2K specifier follows, other=legacy cipher alg implying MD5 hash), optional algorithm ID and S2K specifier, optional 8-octet IV, encrypted secret MPIs, and a 2-octet mod-65536 checksum of the plaintext MPI data.
The Symmetrically Encrypted Data Packet (Tag 9) uses OpenPGP CFB mode with IV of all zeros. A 10-octet prefix is encrypted first: 8 random octets, then two more octets that repeat octets 7 and 8. After encrypting these 10 octets, the CFB state is resynchronized if the block size is 8 octets or less.
Version 3 Signature Packet body: version (1 octet = 3), hashed-material length (1 octet, MUST be 5), signature type (1 octet), creation time (4 octets), signer key ID (8 octets), public key algorithm (1 octet), hash algorithm (1 octet), left 16 bits of hash (2 octets), then algorithm-specific MPIs (RSA: m**d; DSA: r and s).
Version 4 Public Key Packet: version (1 octet = 4), creation time (4 octets), public key algorithm (1 octet), then algorithm-specific MPIs — RSA: n, e; DSA: p, q, g, y; Elgamal: p, g, y. Version 3 additionally includes a two-octet validity period in days; V4 moves expiry to the signature packet.
Version 4 Signature Packet body: version (1 octet = 4), signature type (1 octet), public key algorithm (1 octet), hash algorithm (1 octet), hashed subpacket length (2 octets), hashed subpackets, unhashed subpacket length (2 octets), unhashed subpackets, left 16 bits of hash (2 octets), algorithm-specific MPIs. Only hashed subpackets are cryptographically protected.