OpenPGP Message Format

1.1. Terms

• OpenPGP - This is a term for security software that uses PGP 5 as a basis, formalized in this document.¶
• PGP - Pretty Good Privacy. PGP is a family of software systems developed by Philip R. Zimmermann from which OpenPGP is based.¶
• PGP 2 - This version of PGP has many variants; where necessary a more detailed version number is used here. PGP 2 uses only RSA, MD5, and IDEA for its cryptographic transforms. An informational RFC, RFC 1991, was written describing this version of PGP.¶
• PGP 5 - This version of PGP is formerly known as "PGP 3" in the community. It has new formats and corrects a number of problems in the PGP 2 design. It is referred to here as PGP 5 because that software was the first release of the "PGP 3" code base.¶
• GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP implementation that avoids all encumbered algorithms. Consequently, early versions of GnuPG did not include RSA public keys.¶

"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation and are used with permission. The term "OpenPGP" refers to the protocol described in this and related documents.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The key words "PRIVATE USE", "SPECIFICATION REQUIRED", and "RFC REQUIRED" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].¶

2.1. Confidentiality via Encryption

OpenPGP combines symmetric-key encryption and public-key encryption to provide confidentiality. When made confidential, first the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once, for a single object. A new "session key" is generated as a random number for each object (sometimes referred to as a session). Since it is used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows:¶

1. The sender creates a message.¶
2. The sending OpenPGP generates a random number to be used as a session key for this message only.¶
3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message.¶
4. The sending OpenPGP encrypts the message using the session key, which forms the remainder of the message.¶
5. The receiving OpenPGP decrypts the session key using the recipient's private key.¶
6. The receiving OpenPGP decrypts the message using the session key. If the message was compressed, it will be decompressed.¶

With symmetric-key encryption, an object may be encrypted with a symmetric key derived from a passphrase (or other shared secret), or a two-stage mechanism similar to the public-key method described above in which a session key is itself encrypted with a symmetric algorithm keyed from a shared secret.¶

Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached to the message. Then the message plus signature is encrypted using a symmetric session key. Finally, the session key is encrypted using public-key encryption and prefixed to the encrypted block.¶

2.2. Authentication via Digital Signature

The digital signature uses a hash code or message digest algorithm, and a public-key signature algorithm. The sequence is as follows:¶

1. The sender creates a message.¶
2. The sending software generates a hash code of the message.¶
3. The sending software generates a signature from the hash code using the sender's private key.¶
4. The binary signature is attached to the message.¶
5. The receiving software keeps a copy of the message signature.¶
6. The receiving software generates a new hash code for the received message and verifies it using the message's signature. If the verification is successful, the message is accepted as authentic.¶

2.3. Compression

If an implementation does not implement compression, its authors should be aware that most OpenPGP messages in the world are compressed. Thus, it may even be wise for a space-constrained implementation to implement decompression, but not compression.¶

2.4. Conversion to Radix-64

OpenPGP's underlying native representation for encrypted messages, signature certificates, and keys is a stream of arbitrary octets. Some systems only permit the use of blocks consisting of seven-bit, printable text. For transporting OpenPGP's native raw binary octets through channels that are not safe to raw binary data, a printable encoding of these binary octets is needed. OpenPGP provides the service of converting the raw 8-bit binary octet stream to a stream of printable ASCII characters, called Radix-64 encoding or ASCII Armor.¶

Implementations SHOULD provide Radix-64 conversions.¶

2.5. Signature-Only Applications

OpenPGP is designed for applications that use both encryption and signatures, but there are a number of problems that are solved by a signature-only implementation. Although this specification requires both encryption and signatures, it is reasonable for there to be subset implementations that are non-conformant only in that they omit encryption.¶

3.1. Scalar Numbers

Scalar numbers are unsigned and are always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).¶

3.2. Multiprecision Integers

Multiprecision integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.¶

An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer.¶

These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.¶

Examples:¶

(all numbers are in hexadecimal)¶

The string of octets [00 00] forms an MPI with the value 0. The string of octets [00 01 01] forms an MPI with the value 1. The string [00 09 01 FF] forms an MPI with the value of 511.¶

Additional rules:¶

The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.¶

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 formed correctly. It should be [00 01 01]. When parsing an MPI in a v5 Key, Signature, or Public-Key Encrypted Session Key packet, the implementation MUST check that the encoded length matches the length starting from the most significant non-zero bit, and reject the packet as malformed if not.¶

Unused bits of an MPI MUST be zero.¶

Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext.¶

3.3. Key IDs

A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. Section 5.5.4 describes how Key IDs are formed.¶

3.4. Text

Unless otherwise specified, the character set for text is the UTF-8 [RFC3629] encoding of Unicode [ISO10646].¶

3.5. Time Fields

A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.¶

3.6. Keyrings

A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases.¶

3.7. String-to-Key (S2K) Specifiers

A string-to-key (S2K) specifier is used to convert a passphrase string into a symmetric-key encryption/decryption key. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert passphrases to encryption keys for symmetrically encrypted messages.¶

  Octet 0:        0x00
  Octet 1:        hash algorithm

  Octet 0:        0x01
  Octet 1:        hash algorithm
  Octets 2-9:     8-octet salt value

  Octet  0:        0x03
  Octet  1:        hash algorithm
  Octets 2-9:      8-octet salt value
  Octet  10:       count, a one-octet, coded value

  #define EXPBIAS 6
      count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

  Octet  0:        0x04
  Octets 1-16:     16-octet salt value
  Octet  17:       one-octet number of passes t
  Octet  18:       one-octet degree of parallelism p
  Octet  19:       one-octet exponent indicating the memory size m

  04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
  XX 01 04 15

4.1. Overview

An OpenPGP message is constructed from a number of records that are traditionally called packets. A packet is a chunk of data that has a tag specifying its meaning. An OpenPGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other OpenPGP packets (for example, a compressed data packet, when uncompressed, contains OpenPGP packets).¶

Each packet consists of a packet header, followed by the packet body. The packet header is of variable length.¶

When handling a stream of packets, the length information in each packet header is the canonical source of packet boundaries. An implementation handling a packet stream that wants to find the next packet MUST look for it at the precise offset indicated in the previous packet header.¶

Additionally, some packets contain internal length indicators (for example, a subfield within the packet). In the event that a subfield length indicator within a packet implies inclusion of octets outside the range indicated in the packet header, a parser MUST truncate the subfield at the octet boundary indicated in the packet header. Such a truncation renders the packet malformed and unusable. An implementation MUST NOT interpret octets outside the range indicated in the packet header as part of the contents of the packet.¶

4.2. Packet Headers

The first octet of the packet header is called the "Packet Tag". It determines the format of the header and denotes the packet contents. The remainder of the packet header is the length of the packet.¶

There are two packet formats, the (current) OpenPGP packet format specified by this document and its predecessors and the Legacy packet format as used by PGP 2.x implementations.¶

Note that the most significant bit is the leftmost bit, called bit 7. A mask for this bit is 0x80 in hexadecimal.¶

       ┌───────────────┐
  PTag │7 6 5 4 3 2 1 0│
       └───────────────┘
  Bit 7 -- Always one
  Bit 6 -- Always one (except for Legacy packet format)

The Legacy packet format MAY be used when consuming packets to facilitate interoperability with legacy implementations and accessing archived data. The Legacy packet format SHOULD NOT be used to generate new data, unless the recipient is known to only support the Legacy packet format.¶

An implementation that consumes and re-distributes pre-existing OpenPGP data (such as Transferable Public Keys) may encounter packets framed with the Legacy packet format. Such an implementation MAY either re-distribute these packets in their Legacy format, or transform them to the current OpenPGP packet format before re-distribution.¶

The current OpenPGP packet format packets contain:¶

  Bits 5 to 0 -- packet tag

Legacy packet format packets contain:¶

  Bits 5 to 2 -- packet tag
  Bits 1 to 0 -- length-type

  bodyLen = 1st_octet;

  bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

  bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
            (4th_octet << 8)  | 5th_octet

  partialBodyLen = 1 << (1st_octet & 0x1F);

4.3. Packet Tags

The packet tag denotes what type of packet the body holds. Note that Legacy format headers can only have tags less than 16, whereas OpenPGP format headers can have tags as great as 63. The defined tags (in decimal) are as follows:¶

5.1. Public-Key Encrypted Session Key Packets (Tag 1)

Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or Symmetric-Key Encrypted Session Key packets (Section 5.3) may precede an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data packet or --- for historic data --- a Symmetrically Encrypted Data packet), which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The encryption container is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.¶

The body of this packet starts with a one-octet number giving the version number of the packet type. The currently defined versions are 3 and 5. The remainder of the packet depends on the version.¶

The versions differ in how they identify the recipient key, and in what they encode. The version of the PKESK packet must align with the version of the SEIPD packet (see Section 11.3.2.1).¶

5.2. Signature Packet (Tag 2)

A Signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a User ID.¶

Three versions of Signature packets are defined. Version 3 provides basic signature information, while versions 4 and 5 provide an expandable format with subpackets that can specify more information about the signature.¶

An implementation MUST generate a version 5 signature when signing with a version 5 key. An implementation 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.¶

if the 1st octet <  192, then
    lengthOfLength = 1
    subpacketLen = 1st_octet

if the 1st octet >= 192 and < 255, then
    lengthOfLength = 2
    subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

if the 1st octet = 255, then
    lengthOfLength = 5
    subpacket length = [four-octet scalar starting at 2nd_octet]

09 02 09 03 13 02

5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3)

The Symmetric-Key Encrypted Session Key (SKESK) packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets (Section 5.1) and/or Symmetric-Key Encrypted Session Key packets may precede a an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data packet or --- for historic data --- a Symmetrically Encrypted Data packet) that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s).¶

If the encryption container is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases.¶

The body of this packet starts with a one-octet number giving the version number of the packet type. The currently defined versions are 4 and 5. The remainder of the packet depends on the version.¶

The versions differ in how they encrypt the session key with the password, and in what they encode. The version of the SKESK packet must align with the version of the SEIPD packet (see Section 11.3.2.1).¶

5.4. One-Pass Signature Packets (Tag 4)

The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any 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 compute the entire signed message in one pass.¶

The body of this packet consists of:¶

• A one-octet version number. The currently defined versions are 3 and 5.¶
• A one-octet signature type. Signature types are described in Section 5.2.1.¶
• A one-octet number describing the hash algorithm used.¶
• A one-octet number describing the public-key algorithm used.¶
• Only for v5 packets, a 16 octet field containing random values used as salt. The value must match the salt field of the corresponding Signature packet.¶
• Only for v3 packets, an eight-octet number holding the Key ID of the signing key.¶
• Only for v5 packets, a one octet key version number and N octets of the fingerprint of the signing key. Note that the length N of the fingerprint for a version 5 key is 32. Since a v5 signature can only be made by a v5 key, the key version number MUST be 5. An application that encounters a v5 One-Pass Signature packet where the key version number is not 5 MUST treat the signature as invalid (see Section 5.2.5).¶
• A one-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another One-Pass Signature packet that describes another signature to be applied to the same message data.¶

When generating a one-pass signature, the OPS packet version MUST correspond to the version of the associated signature packet, except for the historical accident that v4 keys use a v3 one-pass signature packet (there is no v4 OPS):¶

Note that if a message contains more than one one-pass signature, then the Signature packets bracket the message; that is, the first Signature packet after the message corresponds to the last one-pass packet and the final Signature packet corresponds to the first one-pass packet.¶

5.5. Key Material Packet

A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex.¶

def curve25519_MPI_from_random(octet_list):
    octet_list[0] &= 248
    octet_list[31] &= 127
    octet_list[31] |= 64
    mpi_header = [ 0x00, 0xff ]
    return mpi_header || reversed(octet_list)

def X448_MPI_from_random(octet_list):
    prefixed_header = [ 0x01, 0xc7, 0x40 ]
    return prefixed_header || octet_list

5.6. Compressed Data Packet (Tag 8)

The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet.¶

The body of this packet consists of:¶

• One octet that gives the algorithm used to compress the packet.¶
• Compressed data, which makes up the remainder of the packet.¶

A Compressed Data Packet's body contains an block that compresses some set of packets. See Section 11 for details on how messages are formed.¶

ZIP-compressed packets are compressed with raw [RFC1951] DEFLATE blocks.¶

ZLIB-compressed packets are compressed with [RFC1950] ZLIB-style blocks.¶

BZip2-compressed packets are compressed using the BZip2 [BZ2] algorithm.¶

An implementation that generates a Compressed Data packet MUST use the non-legacy format for packet framing (see Section 4.2.1). It MUST NOT generate a Compressed Data packet with Legacy format (Section 4.2.2)¶

An implementation that deals with either historic data or data generated by legacy implementations MAY interpret Compressed Data packets that use the Legacy format for packet framing.¶

5.7. Symmetrically Encrypted Data Packet (Tag 9)

The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages).¶

This packet is obsolete. An implementation MUST NOT create this packet. An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. The implementation SHOULD also return an error in this case and stop processing.¶

This packet format is impossible to handle safely in general because the ciphertext it provides is malleable. See Section 14.7 about selecting a better OpenPGP encryption container that does not have this flaw.¶

The body of this packet consists of:¶

• Encrypted data, the output of the selected symmetric-key cipher operating in OpenPGP's variant of Cipher Feedback (CFB) mode.¶

The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.¶

The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a string of length equal to the block size of the cipher plus two to the data before it is encrypted. The first block-size octets (for example, 8 octets for a 64-bit block length) are random, and the following two octets are copies of the last two octets of the IV. For example, in an 8-octet block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 and octet 18 is a repeat of octet 16. As a pedantic clarification, in both these examples, we consider the first octet to be numbered 1.¶

After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset.¶

The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. See Section 14.4 for hints on the proper use of this "quick check".¶

5.8. Marker Packet (Tag 10)

The body of this packet consists of:¶

• The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).¶

Such a packet MUST be ignored when received.¶

5.9. Literal Data Packet (Tag 11)

A Literal Data packet contains the body of a message; data that is not to be further interpreted.¶

The body of this packet consists of:¶

• A one-octet field that describes how the data is formatted.¶

  If it is a b (0x62), then the Literal packet contains binary data. If it is a u (0x75), then the Literal packet contains UTF-8-encoded text data, and thus may need line ends converted to local form, or other text mode changes.¶

  Older versions of OpenPGP used t (0x74) to indicate textual data, but did not specify the character encoding. Implementations SHOULD NOT emit this value. An implementation that receives a literal data packet with this value in the format field SHOULD interpret the packet data as UTF-8 encoded text, unless reliable (not attacker-controlled) context indicates a specific alternate text encoding. This mode is deprecated due to its ambiguity.¶

  Early versions of PGP also defined a value of l as a 'local' mode for machine-local conversions. [RFC1991] incorrectly stated this local mode flag as 1 (ASCII numeral one). Both of these local modes are deprecated.¶

• File name as a string (one-octet length, followed by a file name). This may be a zero-length string. Commonly, if the source of the encrypted data is a file, this will be the name of the encrypted file. An implementation MAY consider the file name in the Literal packet to be a more authoritative name than the actual file name.¶
• A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time.¶

• The remainder of the packet is literal data.¶

  Text data MUST be encoded with UTF-8 (see [RFC3629]), and stored with <CR><LF> text endings (that is, network-normal line endings). These should be converted to native line endings by the receiving software.¶

Note that OpenPGP signatures do not include the formatting octet, the file name, and the date field of the literal packet in a signature hash and thus those fields are not protected against tampering in a signed document. A receiving implementation MUST NOT treat those fields as though they were cryptographically secured by the surrounding signature either when representing them to the user or acting on them.¶

Due to their inherent malleability, an implementation that generates a literal data packet SHOULD avoid storing any significant data in these fields. If the implementation is certain that the data is textual and is encoded with UTF-8 (for example, if it will follow this literal data packet with a signature packet of type 0x01 (see Section 5.2.1), it MAY set the format octet to u. Otherwise, it SHOULD set the format octet to b. It SHOULD set the filename to the empty string (encoded as a single zero octet), and the timestamp to zero (encoded as four zero octets).¶

An application that wishes to include such filesystem metadata within a signature is advised to sign an encapsulated archive (for example, [PAX]).¶

An implementation that generates a Literal Data packet MUST use the OpenPGP format for packet framing (see Section 4.2.1). It MUST NOT generate a Literal Data packet with Legacy format (Section 4.2.2)¶

An implementation that deals with either historic data or data generated by legacy implementations MAY interpret Literal Data packets that use the Legacy format for packet framing.¶

5.10. Trust Packet (Tag 12)

The Trust packet is used only within keyrings and is not normally exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers, along with other information that implementing software uses for trust information. The format of Trust packets is defined by a given implementation.¶

Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files.¶

5.11. User ID Packet (Tag 13)

A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.¶

5.12. User Attribute Packet (Tag 17)

The User Attribute packet is a variation of the User ID packet. It is capable of storing more types of data than the User ID packet, which is limited to text. Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it. Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used.¶

While User Attribute packets are not a required part of the OpenPGP standard, implementations SHOULD provide at least enough compatibility to properly handle a certification signature on 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 an implementation may use any method desired.¶

The User Attribute packet is made up of one or more attribute subpackets. Each subpacket consists of a subpacket header and a body. The header consists of:¶

• the subpacket length (1, 2, or 5 octets)¶
• the subpacket type (1 octet)¶

and is followed by the subpacket specific data.¶

The following table lists the currently known subpackets:¶

An implementation SHOULD ignore any subpacket of a type that it does not recognize.¶

5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)

This packet contains integrity protected and encrypted data. When it has been decrypted, it will contain other packets forming an OpenPGP Message (see Section 11.3).¶

The first octet of this packet is always used to indicate the version number, but different versions contain differently-structured ciphertext. Version 1 of this packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. This is a legacy OpenPGP mechanism that offers some protections against ciphertext malleability.¶

Version 2 of this packet contains data encrypted with an authenticated encryption and additional data (AEAD) construction. This offers a more cryptographically rigorous defense against ciphertext malleability, but may not be as widely supported yet. See Section 14.7 for more details on choosing between these formats.¶

  chunk_size = ((uint64_t)1 << (c + 6))

5.14. Padding Packet (Tag 21)

The Padding packet contains random data, and can be used to defend against traffic analysis (see Section 14.10) on version 2 SEIPD messages (see Section 5.13.2) and Transferable Public Keys (see Section 11.1).¶

Such a packet MUST be ignored when received.¶

Its contents SHOULD be random octets to make the length obfuscation it provides more robust even when compressed.¶

An implementation adding padding to an OpenPGP stream SHOULD place such a packet:¶

• At the end of a v5 Transferable Public Key that is transferred over an encrypted channel (see Section 11.1).¶
• As the last packet of an Optionally Padded Message within a version 2 Symmetrically Encrypted Integrity Protected Data Packet (see Section 11.3.1).¶

An implementation MUST be able to process padding packets anywhere else in an OpenPGP stream, so that future revisions of this document may specify further locations for padding.¶

Policy about how large to make such a packet to defend against traffic analysis is beyond the scope of this document.¶

6.1. Optional checksum

The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of radix-64 encoding by the same MIME base64 transformation, preceded by an equal sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to radix-64, rather than on the converted data. A sample implementation of this algorithm is in Section 6.1.1.¶

If present, the checksum with its leading equal sign MUST appear on the next line after the base64 encoded data.¶

An implementation MUST NOT reject an OpenPGP object when the CRC24 footer is present, missing, malformed, or disagrees with the computed CRC24 sum. When forming ASCII Armor, the CRC24 footer SHOULD NOT be generated, unless interoperability with implementations that require the CRC24 footer to be present is a concern.¶

The CRC24 footer MUST NOT be generated if it can be determined by context or by the OpenPGP object being encoded that the consuming implementation accepts Radix-64 encoded blocks without CRC24 footer. Notably:¶

• An ASCII-armored Encrypted Message packet sequence that ends in an v2 SEIPD packet MUST NOT contain a CRC24 footer.¶
• An ASCII-armored sequence of Signature packets that only includes v5 Signature packets MUST NOT contain a CRC24 footer.¶
• An ASCII-armored Transferable Public Key packet sequence of a v5 key MUST NOT contain a CRC24 footer.¶
• An ASCII-armored keyring consisting of only v5 keys MUST NOT contain a CRC24 footer.¶

Rationale: Previous versions of this document state that the CRC24 footer is optional, but the text was ambiguous. In practice, very few implementations require the CRC24 footer to be present. Computing the CRC24 incurs a significant cost, while providing no meaningful integrity protection. Therefore, generating it is now discouraged.¶

#define CRC24_INIT 0xB704CEL
#define CRC24_GENERATOR 0x864CFBL

typedef unsigned long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
    crc24 crc = CRC24_INIT;
    int i;
    while (len--) {
        crc ^= (*octets++) << 16;
        for (i = 0; i < 8; i++) {
            crc <<= 1;
            if (crc & 0x1000000) {
                crc &= 0xffffff; /* Clear bit 25 to avoid overflow */
                crc ^= CRC24_GENERATOR;
            }
        }
    }
    return crc & 0xFFFFFFL;
}

6.2. Forming ASCII Armor

When OpenPGP encodes data into ASCII Armor, it puts specific headers around the Radix-64 encoded data, so OpenPGP can reconstruct the data later. An OpenPGP implementation MAY use ASCII armor to protect raw binary data. OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.¶

Concatenating the following data creates ASCII Armor:¶

• An Armor Header Line, appropriate for the type of data¶
• Armor Headers¶
• A blank (zero-length, or containing only whitespace) line¶
• The ASCII-Armored data¶
• An optional Armor Checksum (discouraged, see Section 6.1)¶
• The Armor Tail, which depends on the Armor Header Line¶

An Armor Header Line consists of the appropriate header line text surrounded by five (5) dashes (-, 0x2D) on either side of the header line text. The header line text is chosen based upon the type of data that is being encoded in Armor, and how it is being encoded. Header line texts include the following strings:¶

BEGIN PGP MESSAGE

Used for signed, encrypted, or compressed files.¶

BEGIN PGP PUBLIC KEY BLOCK

Used for armoring public keys.¶

BEGIN PGP PRIVATE KEY BLOCK

Used for armoring private keys.¶

BEGIN PGP SIGNATURE

Used for detached signatures, OpenPGP/MIME signatures, and cleartext signatures.¶

Note that all these Armor Header Lines are to consist of a complete line. The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text other than whitespace following them on the same line. These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see Section 7).¶

The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence are not protected by any signatures applied to the message.¶

The format of an Armor Header is that of a key-value pair. A colon (: 0x38) and a single space (0x20) separate the key and value. An OpenPGP implementation may consider improperly formatted Armor Headers to be corruption of the ASCII Armor, but SHOULD make an effort to recover. Unknown keys should be silently ignored, and an OpenPGP implementation SHOULD continue to process the message.¶

Note that some transport methods are sensitive to line length. While there is a limit of 76 characters for the Radix-64 data (Section 6.3), there is no limit to the length of Armor Headers. Care should be taken that the Armor Headers are short enough to survive transport. One way to do this is to repeat an Armor Header Key multiple times with different values for each so that no one line is overly long.¶

Currently defined Armor Header Keys are as follows:¶

• "Version", which states the OpenPGP implementation and version used to encode the message. To minimize metadata, implementations SHOULD NOT emit this key and its corresponding value except for debugging purposes with explicit user consent.¶
• "Comment", a user-defined comment. OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8 string. However, the whole point of armoring is to provide seven-bit-clean data. Consequently, if a comment has characters that are outside the US-ASCII range of UTF, they may very well not survive transport.¶
• "Hash", a comma-separated list of hash algorithms used in this message. This is used only in cleartext signed messages.¶
• "SaltedHash", a salt and hash algorithm used in this message. This is used only in cleartext signed messages that are followed by a v5 Signature.¶
• "Charset", a description of the character set that the plaintext is in. Please note that OpenPGP defines text to be in UTF-8. An implementation will get best results by translating into and out of UTF-8. However, there are many instances where this is easier said than done. Also, there are communities of users who have no need for UTF-8 because they are all happy with a character set like ISO Latin-5 or a Japanese character set. In such instances, an implementation MAY override the UTF-8 default by using this header key. An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8.¶

The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END".¶

6.3. Encoding Binary in Radix-64

The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Radix-64 alphabet. When encoding a bit stream with the Radix-64 encoding, the bit stream must be presumed to be ordered with the most significant bit first. That is, the first bit in the stream will be the high-order bit in the first 8-bit octet, and the eighth bit will be the low-order bit in the first 8-bit octet, and so on.¶

┌──first octet──┬─second octet──┬──third octet──┐
│7 6 5 4 3 2 1 0│7 6 5 4 3 2 1 0│7 6 5 4 3 2 1 0│
├───────────┬───┴───────┬───────┴───┬───────────┤
│5 4 3 2 1 0│5 4 3 2 1 0│5 4 3 2 1 0│5 4 3 2 1 0│
└──1.index──┴──2.index──┴──3.index──┴──4.index──┘

Each 6-bit group is used as an index into an array of 64 printable characters from the table below. The character referenced by the index is placed in the output string.¶

The encoded output stream must be represented in lines of no more than 76 characters each.¶

Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. There are three possibilities:¶

1. The last data group has 24 bits (3 octets). No special processing is needed.¶
2. The last data group has 16 bits (2 octets). The first two 6-bit groups are processed as above. The third (incomplete) data group has two zero-value bits added to it, and is processed as above. A pad character (=) is added to the output.¶
3. The last data group has 8 bits (1 octet). The first 6-bit group is processed as above. The second (incomplete) data group has four zero-value bits added to it, and is processed as above. Two pad characters (=) are added to the output.¶

6.4. Decoding Radix-64

In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. Decoding software must ignore all white space.¶

Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.¶

6.5. Examples of Radix-64

Input data:  0x14FB9C03D97E
Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
Decimal: 5      15     46     28       0      61     37     62
Output:  F      P      u      c        A      9      l      +
Input data:  0x14FB9C03D9
Hex:     1   4    F   B    9   C     | 0   3    D   9
8-bit:   00010100 11111011 10011100  | 00000011 11011001
                                                pad with 00
6-bit:   000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5      15     46     28       0      61     36
                                                   pad with =
Output:  F      P      u      c        A      9      k      =
Input data:  0x14FB9C03
Hex:     1   4    F   B    9   C     | 0   3
8-bit:   00010100 11111011 10011100  | 00000011
                                       pad with 0000
6-bit:   000101 001111 101110 011100 | 000000 110000
Decimal: 5      15     46     28       0      48
                                            pad with =      =
Output:  F      P      u      c        A      w      =      =

6.6. Example of an ASCII Armored Message

-----BEGIN PGP MESSAGE-----

yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
-----END PGP MESSAGE-----

Note that this example has extra indenting; an actual armored message would have no leading whitespace.¶

7.1. Dash-Escaped Text

The cleartext content of the message must also be dash-escaped.¶

Dash-escaped cleartext is the ordinary cleartext where every line starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020). This prevents the parser from recognizing armor headers of the cleartext itself. An implementation MAY dash-escape any line, SHOULD dash-escape lines commencing "From" followed by a space, and MUST dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.¶

As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical <CR><LF> line endings. The line ending (that is, the <CR><LF>) before the -----BEGIN PGP SIGNATURE----- line that terminates the signed text is not considered part of the signed text.¶

When reversing dash-escaping, an implementation MUST strip the string - if it occurs at the beginning of a line, and SHOULD warn on - and any character other than a space at the beginning of a line.¶

Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the end of any line is removed when the cleartext signature is generated.¶

9.1. Public-Key Algorithms

Implementations MUST implement EdDSA (19) for signatures, and ECDH (18) for encryption.¶

RSA (1) keys are deprecated and SHOULD NOT be generated, but may be interpreted. RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and MUST NOT be generated. See Section 13.4. Elgamal (16) keys are deprecated and MUST NOT be generated (see Section 13.6). DSA (17) keys are deprecated and MUST NOT be generated (see Section 13.5). See Section 13.8 for notes on Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm.¶

Note that an implementation conforming to the previous version of this standard ([RFC4880]) have only DSA (17) and Elgamal (16) as its MUST-implement algorithms.¶

A compatible specification of ECDSA is given in [RFC6090] as "KT-I Signatures" and in [SEC1]; ECDH is defined in Section 12.5 of this document.¶

9.2. ECC Curves for OpenPGP

The parameter curve OID is an array of octets that define a named curve.¶

The table below specifies the exact sequence of octets for each named curve referenced in this document. It also specifies which public key algorithms the curve can be used with, as well as the size of expected elements in octets:¶

The "Field Size (fsize)" column represents the field size of the group in number of octets, rounded up, such that x or y coordinates for a point on the curve, native point representations, or scalars with high enough entropy for the curve can be represented in that many octets.¶

The sequence of octets in the third column is the result of applying the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field 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 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 sequence of octets is the valid representation of a curve OID.¶

Implementations MUST implement Ed25519 for use with EdDSA, and Curve25519 for use with ECDH. Implementations SHOULD implement Ed448 for use with EdDSA, and X448 for use with ECDH.¶

9.3. Symmetric-Key Algorithms

Implementations MUST implement AES-128. Implementations SHOULD implement AES-256. Implementations MUST NOT encrypt data with IDEA, TripleDES, or CAST5. Implementations MAY decrypt data that uses IDEA, TripleDES, or CAST5 for the sake of reading older messages or new messages from legacy clients. An Implementation that decrypts data using IDEA, TripleDES, or CAST5 SHOULD generate a deprecation warning about the symmetric algorithm, indicating that message confidentiality is suspect. Implementations MAY implement any other algorithm.¶

9.4. Compression Algorithms

Implementations MUST implement uncompressed data. Implementations SHOULD implement ZLIB. For interoperability reasons implementations SHOULD be able to decompress using ZIP. Implementations MAY implement any other algorithm.¶

9.5. Hash Algorithms

Implementations MUST implement SHA2-256. Implementations SHOULD implement SHA2-384 and SHA2-512. Implementations MAY implement other algorithms. Implementations SHOULD NOT create messages which require the use of SHA-1 with the exception of computing version 4 key fingerprints and for purposes of the Modification Detection Code (MDC) in version 1 Symmetrically Encrypted Integrity Protected Data packets. Implementations MUST NOT generate signatures with MD5, SHA-1, or RIPEMD-160. Implementations MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH KDF. Implementations MUST NOT validate any recent signature that depends on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT validate any old signature that depends on MD5, SHA-1, or RIPEMD-160 unless the signature's creation date predates known weakness of the algorithm used, and the implementation is confident that the message has been in the secure custody of the user the whole time.¶

9.6. AEAD Algorithms

Implementations MUST implement OCB. Implementations MAY implement EAX, GCM and other algorithms.¶

10.1. New String-to-Key Specifier Types

OpenPGP S2K specifiers contain a mechanism for new algorithms to turn a string into a key. This specification creates a registry of S2K specifier types. The registry includes the S2K type, the name of the S2K, and a reference to the defining specification. The initial values for this registry can be found in Section 3.7.1. Adding a new S2K specifier MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126].¶

IANA should add a column "Generate?" to the S2K type registry, with initial values taken from Section 3.7.1.¶

10.2. New Packets

Major new features of OpenPGP are defined through new packet types. This specification creates a registry of packet types. The registry includes the packet type, the name of the packet, and a reference to the defining specification. The initial values for this registry can be found in Section 4.3. Adding a new packet type MUST be done through the RFC REQUIRED method, as described in [RFC8126].¶

10.3. New Algorithms

Section 9 lists the core algorithms that OpenPGP uses. Adding in a new algorithm is usually simple. For example, adding in a new symmetric cipher usually would not need anything more than allocating a constant for that cipher. If that cipher had other than a 64-bit or 128-bit block size, there might need to be additional documentation describing how OpenPGP-CFB mode would be adjusted. Similarly, when DSA was expanded from a maximum of 1024-bit public keys to 3072-bit public keys, the revision of FIPS 186 contained enough information itself to allow implementation. Changes to this document were made mainly for emphasis.¶

10.4. Elliptic Curve Point and Scalar Wire Formats

This document requests IANA add a registry of wire formats that represent elliptic curve points. The table's initial headings and values can be found in Section 12.2. Adding a new EC point wire format MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126].¶

This document also requests IANA add a registry of wire formats that represent scalars for use with elliptic curve cryptography. The table's initial headings and values can be found in Section 12.3. Adding a new EC scalar wire format MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126].¶

This document also requests that IANA add a registry mapping curve-specific MPI octet-string encoding conventions for ECDH and EdDSA. The table's initial headings and values can be found in Section 9.2.1. Adding a new elliptic curve algorithm to OpenPGP MUST be done through the SPECIFICATION REQUIRED method, as described in [RFC8126], and requires adding an entry to this table if the curve is to be used with either EdDSA or ECDH.¶

10.5. Changes to existing registries

This document requests IANA add the following wire format columns to the OpenPGP public-key algorithm registry:¶

• Public Key Format¶
• Secret Key Format¶
• Signature Format¶
• PKESK Format¶

And populate them with the values found in Section 9.1.¶

11.1. Transferable Public Keys

OpenPGP users may transfer public keys. This section describes the structure of public keys in transit to ensure interoperability.¶

Primary Key
   [Revocation Signature...]
    Direct-Key Signature...
   [User ID or User Attribute
           [Certification Revocation Signature...]
           [Certification Signature...]]...
   [Subkey [Subkey Revocation Signature...]
           Subkey Binding Signature...]...
   [Padding]

Primary Key
    Revocation Signature

Primary Key
   [Revocation Signature]
   [Direct-Key Signature...]
   [User ID or User Attribute [Signature...]]...
   [Subkey [Subkey Revocation Signature...]
           Subkey Binding Signature...]...

RSA Public Key
   [Revocation Signature]
    User ID [Signature...]
   [User ID [Signature...]]...

11.2. Transferable Secret Keys

OpenPGP users may transfer secret keys. The format of a transferable secret key is the same as a transferable public key except that secret-key and secret-subkey packets can be used in addition to the public key and public-subkey packets. If a single secret-key or secret-subkey packet is included in a packet sequence, it is a transferable secret key and should be handled and marked as such (see Section 6.2). Implementations SHOULD include self-signatures on any User IDs and subkeys, as this allows for a complete public key to be automatically extracted from the transferable secret key. Implementations MAY choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.¶

11.3. OpenPGP Messages

An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives):¶

OpenPGP Message :-

Encrypted Message | Signed Message | Compressed Message | Literal Message.¶

Compressed Message :-

Compressed Data Packet.¶

Literal Message :-

Literal Data Packet.¶

ESK :-

Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet.¶

ESK Sequence :-

ESK | ESK Sequence, ESK.¶

Encrypted Data :-

Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity Protected Data Packet¶

Encrypted Message :-

Encrypted Data | ESK Sequence, Encrypted Data.¶

One-Pass Signed Message :-

One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet.¶

Signed Message :-

Signature Packet, OpenPGP Message | One-Pass Signed Message.¶

Optionally Padded Message :-

OpenPGP Message | OpenPGP Message, Padding Packet.¶

In addition to these rules, a marker packet (Section 5.8) can appear anywhere in the sequence.¶

11.4. Detached Signatures

Some OpenPGP applications use so-called "detached signatures". For example, a program bundle may contain a file, and with it a second file that is a detached signature of the first file. These detached signatures are simply one or more Signature packets stored separately from the data for which they are a signature.¶

In addition, a marker packet (Section 5.8) and a padding packet (Section 5.14) can appear anywhere in the sequence.¶

12.1. Supported ECC Curves

This document references three named prime field curves defined in [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521"; and three named prime field curves defined in [RFC5639] as "brainpoolP256r1", "brainpoolP384r1", and "brainpoolP512r1". These three [FIPS186] curves and the three [RFC5639] curves can be used with ECDSA and ECDH public key algorithms. Additionally, curve "Curve25519" and "Curve448" are referenced for use with Ed25519 and Ed448 (EdDSA signing, see [RFC8032]); and X25519 and X448 (ECDH encryption, see [RFC7748]).¶

The named curves are referenced as a sequence of octets in this document, called throughout, curve OID. Section 9.2 describes in detail how this sequence of octets is formed.¶

12.2. EC Point Wire Formats

A point on an elliptic curve will always be represented on the wire as an MPI. Each curve uses a specific point format for the data within the MPI itself. Each format uses a designated prefix octet to ensure that the high octet has at least one bit set to make the MPI a constant size.¶

B = 04 || x || y

B = 40 || p

12.3. EC Scalar Wire Formats

Some non-curve values in elliptic curve cryptography (for example, secret keys and signature components) are not points on a curve, but are also encoded on the wire in OpenPGP as an MPI.¶

Because of different patterns of deployment, some curves treat these values as opaque bit strings with the high bit set, while others are treated as actual integers, encoded in the standard OpenPGP big-endian form. The choice of encoding is specific to the public key algorithm in use.¶

12.4. Key Derivation Function

A key derivation function (KDF) is necessary to implement EC encryption. The Concatenation Key Derivation Function (Approved Alternative 1) [SP800-56A] with the KDF hash function that is SHA2-256 [FIPS180] or stronger is REQUIRED.¶

For convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document. However, [SP800-56A] is the normative source of the definition.¶

//   Implements KDF( X, oBits, Param );
//   Input: point X = (x,y)
//   oBits - the desired size of output
//   hBits - the size of output of hash function Hash
//   Param - octets representing the parameters
//   Assumes that oBits <= hBits
// Convert the point X to the octet string:
//   ZB' = 04 || x || y
// and extract the x portion from ZB'
ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB.

Note that ZB in the KDF description above is the compact representation of X as defined in Section 4.2 of [RFC6090].¶

12.5. EC DH Algorithm (ECDH)

The method is a combination of an ECC Diffie-Hellman method to establish a shared secret, a key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message.¶

The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [SP800-56A] MUST be implemented with the following restrictions: the ECC CDH primitive employed by this method is modified to always assume the cofactor is 1, the KDF specified in Section 12.4 is used, and the KDF parameters specified below are used.¶

The KDF parameters are encoded as a concatenation of the following 5 variable-length and fixed-length fields, which are compatible with the definition of the OtherInfo bitstring [SP800-56A]:¶

• A variable-length field containing a curve OID, which is formatted as follows:¶

  • A one-octet size of the following field,¶
  • The octets representing a curve OID defined in Section 9.2;¶
• A one-octet public key algorithm ID defined in Section 9.1;¶

• A variable-length field containing KDF parameters, which are identical to the corresponding field in the ECDH public key, and are formatted as follows:¶

  • A one-octet size of the following fields; values 0 and 0xFF are reserved for future extensions,¶
  • A one-octet value 0x01, reserved for future extensions,¶
  • A one-octet hash function ID used with the KDF,¶
  • A one-octet algorithm ID for the symmetric algorithm used to wrap the symmetric key for message encryption; see Section 12.5 for details;¶
• 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 20 53 65 6E 64 65 72 20 20 20 20;¶
• A variable-length field containing the fingerprint of the recipient encryption subkey identifying the key material that is needed for decryption. For version 4 keys, this field is 20 octets. For version 5 keys, this field is 32 octets.¶

The size in octets of the KDF parameters sequence, defined above, for encrypting to a v4 key is either 54 for curve NIST P-256, 51 for curves NIST P-384 and NIST P-521, 55 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1, 56 for Curve25519, or 49 for X448. For encrypting to a v5 key, the size of the sequence is either 66 for curve NIST P-256, 63 for curves NIST P-384 and NIST P-521, 67 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1, 68 for Curve25519, or 61 for X448.¶

The key wrapping method is described in [RFC3394]. The KDF produces a symmetric key that is used as a key-encryption key (KEK) as specified in [RFC3394]. Refer to Section 12.5.1 for the details regarding the choice of the KEK algorithm, which SHOULD be one of three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394].¶

The input to the key wrapping method is the plaintext described in Section 5.1, "Public-Key Encrypted Session Key Packets (Tag 1)", padded using the method described in [PKCS5] to an 8-octet granularity.¶

For example, in a v4 Public-Key Encrypted Session Key packet, the following AES-256 session key, in which 32 octets are denoted from k0 to k31, is composed to form the following 40 octet sequence:¶

09 k0 k1 ... k31 s0 s1 05 05 05 05 05

The octets s0 and s1 above denote the checksum of the session key octets. This encoding allows the sender to obfuscate the size of the symmetric encryption 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 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 key wrapping method.¶

In a v5 Public-Key Encrypted Session Key packet, the symmetric algorithm is not included, as described in Section 5.1. For example, an AES-256 session key would be composed as follows:¶

k0 k1 ... k31 s0 s1 06 06 06 06 06 06

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 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, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.¶

The output of the method consists of two fields. The first field is the MPI containing the ephemeral key used to establish the shared secret. The second field is composed of the following two subfields:¶

• One octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions;¶
• Up to 254 octets representing the result of the key wrapping method, applied to the 8-octet padded session key, as described above.¶

Note that for session key sizes 128, 192, and 256 bits, the size of the result of the key wrapping method is, respectively, 32, 40, and 48 octets, unless size obfuscation is used.¶

For convenience, the synopsis of the encoding method is given below; however, this section, [SP800-56A], and [RFC3394] are the normative sources of the definition.¶

• Obtain the authenticated recipient public key R¶
• Generate an ephemeral key pair {v, V=vG}¶
• Compute the shared point S = vR;¶
• m = symm_alg_ID || session key || checksum || pkcs5_padding;¶
• curve_OID_len = (octet)len(curve_OID);¶
• Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || Anonymous Sender     || recipient_fingerprint;¶
• Z_len = the key size for the KEK_alg_ID used with AESKeyWrap¶
• Compute Z = KDF( S, Z_len, Param );¶
• Compute C = AESKeyWrap( Z, m ) as per [RFC3394]¶
• VB = convert point V to the octet string¶
• Output (MPI(VB) || len(C) || C).¶

The decryption is the inverse of the method given. Note that the recipient obtains the shared secret by calculating¶

S = rV = rvG, where (r,R) is the recipient's key pair.

13.1. PKCS#1 Encoding in OpenPGP

This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions has changed in the past. To avoid potential confusion and interoperability problems, we are including local copies in this document, adapted from those in PKCS#1 v2.1 [RFC8017]. [RFC8017] should be treated as the ultimate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is value in having a self-contained document that avoids problems in the future with needed changes in the conventions.¶

  EM = 0x00 || 0x02 || PS || 0x00 || M.

13.2. Symmetric Algorithm Preferences

The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts. Since it is found on a self-signature, it is possible that a keyholder may have multiple, different preferences. For example, Alice may have AES-128 only specified for "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for "alice@home.org". Note that it is also possible for preferences to be in a subkey's binding signature.¶

Since AES-128 is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly an AES-128-only implementation. Note further that implementations conforming to previous versions of this standard [RFC4880] have TripleDES as its only MUST-implement algorithm.¶

An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, AES-128, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection.¶

If an implementation can decrypt a message that a keyholder doesn't have in their preferences, the implementation SHOULD decrypt the message anyway, but MUST warn the keyholder that the protocol has been violated. For example, suppose that Alice, above, has software that implements all algorithms in this specification. Nonetheless, she prefers subsets for work or home. If she is sent a message encrypted with IDEA, which is not in her preferences, the software warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway.¶

13.3. Other Algorithm Preferences

Other algorithm preferences work similarly to the symmetric algorithm preference, in that they specify which algorithms the keyholder accepts. There are two interesting cases that other comments need to be made about, though, the compression preferences and the hash preferences.¶

13.4. RSA

The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in this document, is no longer recommended, and its use is deprecated by [SP800-131A]. Therefore, an implementation SHOULD NOT generate RSA keys.¶

There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation MUST NOT create such a key, but MAY interpret it.¶

An implementation MUST NOT generate RSA keys of size less than 3072 bits. An implementation SHOULD NOT encrypt, sign or verify using RSA keys of size less than 3072 bits. An implementation MUST NOT encrypt, sign or verify using RSA keys of size less than 2048 bits. An implementation that decrypts a message using an RSA secret key of size less than 3072 bits SHOULD generate a deprecation warning that the key is too weak for modern use.¶

13.5. DSA

DSA is expected to be deprecated in [FIPS186-5]. Therefore, an implementation MUST NOT generate DSA keys.¶

An implementation MUST NOT sign or verify using DSA keys.¶

13.6. Elgamal

The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined in this document, is no longer recommended, and its use is deprecated by [SP800-131A]. Therefore, an implementation MUST NOT generate Elgamal keys.¶

An implementation MUST NOT encrypt using Elgamal keys. An implementation that decrypts a message using an Elgamal secret key SHOULD generate a deprecation warning that the key is too weak for modern use.¶

13.7. EdDSA

Although the EdDSA algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message is used as input (pre-hashed). See Section 5.2.4 for details. Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm.¶

For clarity: while [RFC8032] describes different variants of EdDSA, OpenPGP uses the "pure" variant (PureEdDSA). The hashing that happens with OpenPGP is done as part of the standard OpenPGP signature process, and that hash itself is fed as the input message to the PureEdDSA algorithm.¶

As specified in [RFC8032], Ed448 also expects a "context string". In OpenPGP, Ed448 is used with the empty string as a context string.¶

13.8. Reserved Algorithm Numbers

A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are issues that prevent an implementer from actually implementing the algorithm. These are marked in Section 9.1 as "reserved for".¶

The reserved public-key algorithm X9.42 (21) does not have the necessary parameters, parameter order, or semantics defined. The same is currently true for reserved public-key algorithms AEDH (23) and AEDSA (24).¶

Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures with a public-key identifier of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].¶

13.9. OpenPGP CFB Mode

When using a version 1 Symmetrically Encrypted Integrity Protected Data packet (Section 5.13.1) or --- for historic data --- a Symmetrically Encrypted Data packet (Section 5.7), OpenPGP does symmetric encryption using a variant of Cipher Feedback mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Integrity Protected Data Packets (and the dangerously malleable --- and deprecated --- Symmetrically Encrypted Data Packets). Some mechanisms for encrypting secret-key material also use CFB mode, as described in Section 3.7.2.1.¶

In the description below, the value BS is the block size in octets of the cipher. Most ciphers have a block size of 8 octets. The AES and Twofish have a block size of 16 octets. Also note that the description below assumes that the IV and CFB arrays start with an index of 1 (unlike the C language, which assumes arrays start with a zero index).¶

OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets.¶

Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a block size of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key.¶

Step by step, here is the procedure:¶

1. The feedback register (FR) is set to the IV, which is all zeros.¶
2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value.¶
3. FRE is xored with the first BS octets of random data prefixed to the plaintext to produce C[1] through C[BS], the first BS octets of ciphertext.¶
4. FR is loaded with C[1] through C[BS].¶
5. FR is encrypted to produce FRE, the encryption of the first BS octets of ciphertext.¶
6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C[BS+1] and C[BS+2], the next two octets of ciphertext.¶
7. (The resynchronization step) FR is loaded with C[3] through C[BS+2].¶
8. FR is encrypted to produce FRE.¶
9. FRE is xored with the first BS octets of the given plaintext, now that we have finished encrypting the BS+2 octets of prefixed data. This produces C[BS+3] through C[BS+(BS+2)], the next BS octets of ciphertext.¶
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block).¶
11. FR is encrypted to produce FRE.¶
12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR, and the process is repeated until the plaintext is used up.¶

13.10. Private or Experimental Parameters

S2K specifiers, Signature subpacket types, User Attribute types, image format types, and algorithms described in Section 9 all reserve the range 100 to 110 for private and experimental use. Packet types reserve the range 60 to 63 for private and experimental use. These are intentionally managed with the PRIVATE USE method, as described in [RFC8126].¶

However, implementations need to be careful with these and promote them to full IANA-managed parameters when they grow beyond the original, limited system.¶

13.11. Meta-Considerations for Expansion

If OpenPGP is extended in a way that is not backwards-compatible, meaning that old implementations will not gracefully handle their absence of a new feature, the extension proposal can be declared in the key holder's self-signature as part of the Features signature subpacket.¶

We cannot state definitively what extensions will not be upwards-compatible, but typically new algorithms are upwards-compatible, whereas new packets are not.¶

If an extension proposal does not update the Features system, it SHOULD include an explanation of why this is unnecessary. If the proposal contains neither an extension to the Features system nor an explanation of why such an extension is unnecessary, the proposal SHOULD be rejected.¶

14.1. SHA-1 Collision Detection

As described in [SHAMBLES], the SHA-1 digest algorithm is not collision-resistant. However, an OpenPGP implementation cannot completely discard the SHA-1 algorithm, because it is required for implementing and reasoning about v4 public keys. In particular, the v4 fingerprint derivation uses SHA-1. So as long as an OpenPGP implementation supports v4 public keys, it will need to implement SHA-1 in at least some scenarios.¶

To avoid the risk of uncertain breakage from a maliciously introduced SHA-1 collision, an OpenPGP implementation MAY attempt to detect when a hash input is likely from a known collision attack, and then either deliberately reject the hash input or modify the hash output. This should convert an uncertain breakage (where it is unclear what the effect of a collision will be) to an explicit breakage, which is more desirable for a robust implementation.¶

[STEVENS2013] describes a method for detecting indicators of well-known SHA-1 collision attacks. Some example C code implementing this technique can be found at [SHA1CD].¶

14.2. Advantages of Salted Signatures

V5 signatures include a 128 bit salt that is hashed first. This makes v5 OpenPGP signatures non-deterministic and protects against a broad class of attacks that depend on creating a signature over a predictable message. By selecting a new random salt for each signature made, signatures are not predictable.¶

When the material to be signed may be attacker-controlled, hashing the salt first means that there is no attacker controlled hashed prefix. An example of this kind of attack is described in the paper SHA-1 Is A Shambles (see [SHAMBLES]), which leverages a chosen prefix collision attack against SHA-1.¶

In some cases, an attacker may be able to induce a signature to be made, even if they do not control the content of the message. In some scenarios, a repeated signature over the exact same message may risk leakage of part or all of the signing key, for example see discussion of hardware faults over EdDSA and deterministic ECDSA in [PSSLR17]. Choosing a new random salt for each signature ensures that no repeated signatures are produced, and mitigates this risk.¶

14.3. Elliptic Curve Side Channels

Side channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing oracle, for example, when an application is a network service performing decryption to unauthenticated remote users. ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side channel attacks. Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding of the operations associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations.¶

14.4. Risks of a Quick Check Oracle

In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in OpenPGP CFB mode (used by v1 SEIPD and SED packets) can be as an oracle to decrypt two octets of every cipher block [MZ05]. This check was intended for early detection of session key decryption errors, particularly to detect a wrong passphrase, since v4 SKESK packets do not include an integrity check.¶

There is a danger to using the quick check if timing or error information about the check can be exposed to an attacker, particularly via an automated service that allows rapidly repeated queries.¶

Disabling the quick check prevents the attack.¶

For very large legacy encrypted data whose session key is protected by a passphrase (v4 SKESK), while the quick check may be convenient to the user to be informed early on that they typed the wrong passphrase, the implementation should use the quick check with care. The recommended approach for secure and early detection of decryption failure is to encrypt data using v2 SEIPD. If the session key is public-key encrypted, the quick check is not useful as the public-key encryption of the session key should guarantee that it is the right session key.¶

The quick check oracle attack is a particular type of attack that exploits ciphertext malleability. For information about other similar attacks, see Section 14.7.¶

14.5. Avoiding Leaks From PKCS#1 Errors

The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted PKESK) has been found to be vulnerable to attacks in which a system that allows distinguishing padding errors from other decryption errors can act as a decryption and/or signing oracle that can leak the session key or allow signing arbitrary data, respectively [BLEICHENBACHER-PKCS1]. The number of queries required to carry out an attack can range from thousands to millions, depending on how strict and careful an implementation is in processing the padding.¶

To make the attack more difficult, an implementation SHOULD implement strict, robust, constant time padding checks.¶

To prevent the attack, in settings where the attacker does not have access to timing information concerning message decryption, the simplest solution is to report a single error code for all variants of PKESK processing errors as well as SEIPD integrity errors (this includes also session key parsing errors, such as on invalid cipher algorithm for v3 PKESK, or session key size mismatch for v5 PKESK). If the attacker may have access to timing information, then a constant time solution is also needed. This requires careful design, especially for v3 PKESK, where session key size and cipher information is typically not known in advance, as it is part of the PKESK encrypted payload.¶

14.6. Fingerprint Usability

This specification uses fingerprints in several places on the wire (e.g., Section 5.2.3.20, Section 5.2.3.32, and Section 5.2.3.33), and in processing (e.g., in ECDH KDF Section 12.5). An implementation may also use the fingerprint internally, for example as an index to a keystore.¶

Additionally, some OpenPGP users have historically used manual fingerprint comparison to verify the public key of a peer. For a version 4 fingerprint, this has typically been done with the fingerprint represented as 40 hexadecimal digits, often broken into groups of four digits with whitespace between each group.¶

When a human is actively involved, the result of such a verification is dubious. We have little evidence that most humans are good at precise comparison of high-entropy data, particularly when that data is represented in compact textual form like a hexadecimal fingerprint.¶

The version 5 fingerprint makes the challenge for a human verifier even worse. At 256 bits (compared to v4's 160 bit fingerprint), a v5 fingerprint is even harder for a human to successfully compare.¶

An OpenPGP implementation should prioritize mechanical fingerprint transfer and comparison where possible, and SHOULD NOT promote manual transfer or comparison of full fingerprints by a human unless there is no other way to achieve the desired result.¶

While this subsection acknowledges existing practice for human-representable v4 fingerprints, this document does not attempt to standardize any specific human-readable form of v5 fingerprint for this discouraged use case.¶

NOTE: the topic of interoperable human-in-the-loop key verification needs more work, probably in a separate document.¶

14.7. Avoiding Ciphertext Malleability

If ciphertext can be modified by an attacker but still subsequently decrypted to some new plaintext, it is considered "malleable". A number of attacks can arise in any cryptosystem that uses malleable encryption, so modern OpenPGP offers mechanisms to defend against it. However, legacy OpenPGP data may have been created before these mechanisms were available. Because OpenPGP implementations deal with historic stored data, they may encounter malleable ciphertexts.¶

When an OpenPGP implementation discovers that it is decrypting data that appears to be malleable, it MUST indicate a clear error message that the integrity of the message is suspect, SHOULD NOT attempt to parse nor release decrypted data to the user, and SHOULD halt with an error. Parsing or releasing decrypted data before having confirmed its integrity can leak the decrypted data [EFAIL], [MRLG15].¶

In the case of AEAD encrypted data, if the authentication tag fails to verify, the implementation MUST NOT attempt to parse nor release decrypted data to the user, and MUST halt with an error.¶

An implementation that encounters malleable ciphertext MAY choose to release cleartext to the user if it is not encrypted using AEAD, and it is known to be dealing with historic archived legacy data, and the user is aware of the risks.¶

In the case of AEAD encrypted messages, if the message is truncated, i.e. the final zero-octet chunk and possibly (part of) some chunks before it are missing, the implementation MAY choose to release cleartext from fully authenticated chunks before it to the user if it is operating in a streaming fashion, but it MUST indicate a clear error message as soon as the truncation is detected.¶

Any of the following OpenPGP data elements indicate that malleable ciphertext is present:¶

• all Symmetrically Encrypted Data packets (Section 5.7).¶
• within any encrypted container, any Compressed Data packet (Section 5.6) where there is a decompression failure.¶
• any version 1 Symmetrically Encrypted Integrity Protected Data packet (Section 5.13.1) where the internal Modification Detection Code does not validate.¶
• any version 2 Symmetrically Encrypted Integrity Protected Data packet (Section 5.13.2) where the authentication tag of any chunk fails, or where there is no final zero-octet chunk.¶

• any Secret Key packet with encrypted secret key material (Section 3.7.2.1) where there is an integrity failure, based on the value of the secret key protection octet:¶

  • value 255 or raw cipher algorithm: where the trailing 2-octet checksum does not match.¶
  • value 254: where the SHA1 checksum is mismatched.¶
  • value 253: where the AEAD authentication tag is invalid.¶

To avoid these circumstances, an implementation that generates OpenPGP encrypted data SHOULD select the encrypted container format with the most robust protections that can be handled by the intended recipients. In particular:¶

• The SED packet is deprecated, and MUST NOT be generated.¶

• When encrypting to one or more public keys:¶

  • all recipient keys indicate support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet in their Features subpacket (Section 5.2.3.29), or are v5 keys without a Features subpacket, or the implementation can otherwise infer that all recipients support v2 SEIPD packets, the implementation MUST encrypt using a v2 SEIPD packet.¶
  • If one of the recipients does not support v2 SEIPD packets, then the message generator MAY use a v1 SEIPD packet instead.¶
• Password-protected secret key material in a v5 Secret Key or v5 Secret Subkey packet SHOULD be protected with AEAD encryption (S2K usage octet 253) unless it will be transferred to an implementation that is known to not support AEAD. Implementations should be aware that, in scenarios where an attacker has access to encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or 255) are vulnerable to corruption attacks that can cause leakage of secret data when the secret key is used [KOPENPGP], [KR02].¶

Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) promptly and encourage its spread.¶

Users should migrate to AEAD with all due speed.¶

14.8. Escrowed Revocation Signatures

A keyholder Alice may wish to designate a third party to be able to revoke Alice's own key.¶

The preferred way for her to do this is produce a specific Revocation Signature (signature types 0x20, 0x28, or 0x30) and distribute it securely to her preferred revoker who can hold it in escrow. The preferred revoker can then publish the escrowed Revocation Signature at whatever time is deemed appropriate, rather than generating a revocation signature themselves.¶

There are multiple advantages of using an escrowed Revocation Signature over the deprecated Revocation Key subpacket (Section 5.2.3.20):¶

• The keyholder can constrain what types of revocation the preferred revoker can issue, by only escrowing those specific signatures.¶
• There is no public/visible linkage between the keyholder and the preferred revoker.¶
• Third parties can verify the revocation without needing to find the key of the preferred revoker.¶
• The preferred revoker doesn't even need to have a public OpenPGP key if some other secure transport is possible between them and the keyholder.¶
• Implementation support for enforcing a revocation from an authorized Revocation Key subpacket is uneven and unreliable.¶
• If the fingerprint mechanism suffers a cryptanalytic flaw, the escrowed Revocation Signature is not affected.¶

A Revocation Signature may also be split up into shares and distributed among multiple parties, requiring some subset of those parties to collaborate before the escrowed Revocation Signature is recreated.¶

14.9. Random Number Generation and Seeding

OpenPGP requires a cryptographically secure pseudorandom number generator (CSPRNG). In most cases, the operating system provides an appropriate facility such as a getrandom() syscall, which should be used absent other (for example, performance) concerns. It is RECOMMENDED to use an existing CSPRNG implementation in preference to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, [RFC4086] provides guidance on the generation of random values.¶

OpenPGP uses random data with three different levels of visibility:¶

• in publicly-visible fields such as nonces, IVs, public padding material, or salts,¶
• in shared-secret values, such as session keys for encrypted data or padding material within an encrypted packet, and¶
• in entirely private data, such as asymmetric key generation.¶

With a properly functioning CSPRNG, this does not present a security problem, as it is not feasible to determine the CSPRNG state from its output. However, with a broken CSPRNG, it may be possible for an attacker to use visible output to determine the CSPRNG internal state and thereby predict less-visible data like keying material, as documented in [CHECKOWAY].¶

An implementation can provide extra security against this form of attack by using separate CSPRNGs to generate random data with different levels of visibility.¶

14.10. Traffic Analysis

When sending OpenPGP data through the network, the size of the data may leak information to an attacker. There are circumstances where such a leak could be unacceptable from a security perspective.¶

For example, if possible cleartext messages for a given protocol are known to be either yes (three octets) and no (two octets) and the messages are sent within a Symmetrically-Encrypted Integrity Protected Data packet, the length of the encrypted message will reveal the contents of the cleartext.¶

In another example, sending an OpenPGP Transferable Public Key over an encrypted network connection might reveal the length of the certificate. Since the length of an OpenPGP certificate varies based on the content, an external observer interested in metadata (who is trying to contact who) may be able to guess the identity of the certificate sent, if its length is unique.¶

In both cases, an implementation can adjust the size of the compound structure by including a Padding packet (see Section 5.14).¶

14.11. Surreptitious Forwarding

When an attacker obtains a signature for some text, e.g. by receiving a signed message, they may be able to use that signature maliciously by sending a message purporting to come from the original sender, with the same body and signature, to a different recipient. To prevent this, implementations SHOULD implement the Intended Recipient Fingerprint signature subpacket (Section 5.2.3.33).¶

15.1. Constrained Legacy Fingerprint Storage for v5 Keys

Some OpenPGP implementations have fixed length constraints for key fingerprint storage that will not fit all 32 octets of a v5 fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each stored fingerprint.¶

An OpenPGP implementation MUST NOT attempt to map any part of a v5 fingerprint to such a constrained field unless the relevant spec for the constrained environment has explicit guidance for storing a v5 fingerprint that distinguishes it from a v4 fingerprint. An implementation interacting with such a constrained field SHOULD directly calculate the v5 fingerprint from public key material and associated metadata instead of relying on the constrained field.¶

A.1. Sample v4 Ed25519 key

The secret key used for this example is:¶

D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2¶

Note that this is the raw secret key used as input to the EdDSA signing operation. The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenPGP key is:¶

   C959 BDBA FA32 A2F8 9A15  3B67 8CFD E121 9796 5A9A

The algorithm-specific input parameters without the MPI length headers are:¶

oid: 2b06010401da470f01¶

q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406¶

The entire public key packet is thus:¶

   98 33 04 53 f3 5f 0b 16  09 2b 06 01 04 01 da 47
   0f 01 01 07 40 3f 09 89  94 bd d9 16 ed 40 53 19
   79 34 e4 a8 7c 80 73 3a  12 80 d6 2f 80 10 99 2e
   43 ee 3b 24 06

The same packet, represented in ASCII-armored form is:¶

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEU/NfCxYJKwYBBAHaRw8BAQdAPwmJlL3ZFu1AUxl5NOSofIBzOhKA1i+AEJku
Q+47JAY=
-----END PGP PUBLIC KEY BLOCK-----

A.2. Sample v4 Ed25519 signature

The signature is created using the sample key over the input data "OpenPGP" on 2015-09-16 12:24:53 UTC and thus the input to the hash function is:¶

m: 4f70656e504750040016080006050255f95f9504ff0000000c¶

Using the SHA2-256 hash algorithm yields the digest:¶

d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280¶

Which is fed into the EdDSA signature function and yields this signature:¶

r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366¶

s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404¶

The entire signature packet is thus:¶

   88 5e 04 00 16 08 00 06  05 02 55 f9 5f 95 00 0a
   09 10 8c fd e1 21 97 96  5a 9a f6 22 00 ff 56 f9
   0c ca 98 e2 10 26 37 bd  98 3f db 16 c1 31 df d2
   7e d8 2b f4 dd e5 60 6e  0d 75 6a ed 33 66 01 00
   d0 9c 4f a1 15 27 f0 38  e0 f5 7f 22 01 d8 2f 2e
   a2 c9 03 32 65 fa 6c eb  48 9e 85 4b ae 61 b4 04

The same packet represented in ASCII-armored form is:¶

-----BEGIN PGP SIGNATURE-----

iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S
ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE
-----END PGP SIGNATURE-----

A.3. Sample v5 Certificate (Transferable Public Key)

Here is a Transferable Public Key consisting of:¶

• a v5 Ed25519 Public-Key packet¶
• a v5 direct key self-signature¶
• a v5 Curve25519 Public-Subkey packet¶
• a v5 subkey binding signature¶

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjcFYiDQVxYAAAAtCSsGAQQB2kcPAQEHQLVQ/UIL3goq8tqYyAhqx19AG5YH
uMyAHjCOTyUpVKtRwqgFHxYKAAAAIwUCYiDQVwMVCAoEFgACAQIbAwIeCQ0n
CQMHAwkBBwEJAgcCAAAAIyIhBRtEKdW2+mmb5MgIz7teOE83FiJh8l1/FwE4
zi0wDN9LAe6QPJVjW4F4PVc/MnGWVpABAQDII7BN+BLRKYzNOhbcPvfYF4z1
eV8v9ZpnrKBtyU2VegEA4IBoRJBIBupzrKXL497Z1/H4t/zWsNOwx9Gk/NQN
7QbOPAViINBXEgAAADIKKwYBBAGXVQEFAQEHQOwq6DFNBJ25z8Z/WKRA92BG
lwBQnfJnGYBF7hPBMl1/AwEIB8KOBRgWCAAAAAkFAmIg0FcCGwwAAAAjIiEF
G0Qp1bb6aZvkyAjPu144TzcWImHyXX8XATjOLTAM30t2vVIiqtITHHtzmroU
10kwplUBANrkpE2T3XCNqLYnFEfpj0+eyNjUDX4LZye4k5SICcIkAPwNFfvq
wyg7rLV+WXlG27Z7S2gNpt1VbZSBs6IxjzXABg==
-----END PGP PUBLIC KEY BLOCK-----

The corresponding Transferable Secret Key can be found in Appendix A.4.¶

A.4. Sample v5 Secret Key (Transferable Secret Key)

Here is a Transferable Secret Key consisting of:¶

• a v5 Ed25519 Secret-Key packet¶
• a v5 direct key self-signature¶
• a v5 Curve25519 Secret-Subkey packet¶
• a v5 subkey binding signature¶

-----BEGIN PGP PRIVATE KEY BLOCK-----

xV0FYiDQVxYAAAAtCSsGAQQB2kcPAQEHQLVQ/UIL3goq8tqYyAhqx19AG5YH
uMyAHjCOTyUpVKtRAAABAKmpvxTlZ9KQ6j+aOEk8fYe/h0L8K5pJsuAYhvSV
mL28EbTCqAUfFgoAAAAjBQJiINBXAxUICgQWAAIBAhsDAh4JDScJAwcDCQEH
AQkCBwIAAAAjIiEFG0Qp1bb6aZvkyAjPu144TzcWImHyXX8XATjOLTAM30sB
7pA8lWNbgXg9Vz8ycZZWkAEBAMgjsE34EtEpjM06Ftw+99gXjPV5Xy/1mmes
oG3JTZV6AQDggGhEkEgG6nOspcvj3tnX8fi3/Naw07DH0aT81A3tBsdiBWIg
0FcSAAAAMgorBgEEAZdVAQUBAQdA7CroMU0EnbnPxn9YpED3YEaXAFCd8mcZ
gEXuE8EyXX8DAQgHAAAA/1b9bxwV0acRUcifrLiKHd0VVifoISz2PSVd4q5I
c1+gD+HCjgUYFggAAAAJBQJiINBXAhsMAAAAIyIhBRtEKdW2+mmb5MgIz7te
OE83FiJh8l1/FwE4zi0wDN9Ldr1SIqrSExx7c5q6FNdJMKZVAQDa5KRNk91w
jai2JxRH6Y9PnsjY1A1+C2cnuJOUiAnCJAD8DRX76sMoO6y1fll5Rtu2e0to
DabdVW2UgbOiMY81wAY=
-----END PGP PRIVATE KEY BLOCK-----

The corresponding Transferable Public Key can be found in Appendix A.3.¶

A.5. Sample AEAD-EAX encryption and decryption

This example encrypts the cleartext string Hello, world! with the password password, using AES-128 with AEAD-EAX encryption.¶

  Iterated and Salted S2K

  65011712 (255), SHA2-256

  a5 ae 57 9d 1f c5 d8 2b

  c3 40

  05 1e 07 01 0b 03 08 a5 ae 57 9d 1f c5 d8 2b ff
  69 22

  69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8

  da 74 6b 88 e3 57 e8 ae 54 eb 87 e1 d7 05 75 d7
  2f 60 23 29 90 52 3e 9a 59 09 49 22 40 6b e1 c3

  15 49 67 e5 90 aa 1f 92 3e 1c 0a c6 4c 88 f2 3d

  c3 05 07 01

  74 f0 46 03 63 a7 00 76 db 08 c4 92 ab f2 95 52

  c3 05 07 01

  69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8

  38 81 ba fe 98 54 12 45 9b 86 c3 6f 98 cb 9a 5e

  d2 69

  02 07 01 06

  9f f9 0e 3b 32 19 64 f3 a4 29 13 c8 dc c6 61 93
  25 01 52 27 ef b7 ea ea a4 9f 04 c2 e6 74 17 5d

  4a 3d 22 6e d6 af cb 9c a9 ac 12 2c 14 70 e1 1c
  63 d4 c0 ab 24 1c 6a 93 8a d4 8b f9 9a 5a 99 b9
  0b ba 83 25 de

  61 04 75 40 25 8a b7 95 9a 95 ad 05 1d da 96 eb

  15 43 1d fe f5 f5 e2 25 5c a7 82 61 54 6e 33 9a

  d2 02 07 01 06

  b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f
  78 b8 33 f2 e9 4a 60 c0

  b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f

  78 b8 33 f2 e9 4a 60 c0

  78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 00

  d2 02 07 01 06

  cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
  6f 72 6c 64 21

  d5 0e ae 5b f0 cd 67 05 50 03 55 81 6c b0 c8 ff

  78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 01

  d2 02 07 01 06 00 00 00 00 00 00 00 25

-----BEGIN PGP MESSAGE-----

w0AFHgcBCwMIpa5XnR/F2Cv/aSJPkZmTs1Bvo7WaanPP+Np0a4jjV+iuVOuH4dcF
ddcvYCMpkFI+mlkJSSJAa+HD0mkCBwEGn/kOOzIZZPOkKRPI3MZhkyUBUifvt+rq
pJ8EwuZ0F11KPSJu1q/LnKmsEiwUcOEcY9TAqyQcapOK1Iv5mlqZuQu6gyXeYQR1
QCWKt5Wala0FHdqW6xVDHf719eIlXKeCYVRuM5o=
-----END PGP MESSAGE-----

A.6. Sample AEAD-OCB encryption and decryption

This example encrypts the cleartext string Hello, world! with the password password, using AES-128 with AEAD-OCB encryption.¶

  Iterated and Salted S2K

  65011712 (255), SHA2-256

  56 a2 98 d2 f5 e3 64 53

  c3 3f

  05 1d 07 02 0b 03 08 56 a2 98 d2 f5 e3 64 53 ff
  cf cc

  cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0

  78 c5 c0 41 9c c5 1b 3a 46 87 cb 32 e5 b7 03 1c
  e7 c6 69 75 76 5b 5c 21 d9 2a ef 4c c0 5c 3f ea

  e8 0d e2 43 a3 62 d9 3b 9d c6 07 ed e9 6a 73 56

  c3 05 07 02

  20 62 fb 76 31 ef be f4 df 81 67 ce d7 f3 a4 64

  c3 05 07 02

  cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0

  28 e7 9a b8 23 97 d3 c6 3d e2 4a c2 17 d7 b7 91

  d2 69

  02 07 02 06

  20 a6 61 f7 31 fc 9a 30 32 b5 62 33 26 02 7e 3a
  5d 8d b5 74 8e be ff 0b 0c 59 10 d0 9e cd d6 41

  ff 9f d3 85 62 75 80 35 bc 49 75 4c e1 bf 3f ff
  a7 da d0 a3 b8 10 4f 51 33 cf 42 a4 10 0a 83 ee
  f4 ca 1b 48 01

  a8 84 6b f4 2b cd a7 c8 ce 9d 65 e2 12 f3 01 cb

  cd 98 fd ca de 69 4a 87 7a d4 24 73 23 f6 e8 57

  d2 02 07 02 06

  71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99
  eb de 12 bb 57 0d cf

  71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99

  eb de 12 bb 57 0d cf

  eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 00

  d2 02 07 02 06

  cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
  6f 72 6c 64 21

  d5 0e ae 6a a1 64 9b 56 aa 83 5b 26 13 90 2b d2

  eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 01

  d2 02 07 02 06 00 00 00 00 00 00 00 25

-----BEGIN PGP MESSAGE-----

wz8FHQcCCwMIVqKY0vXjZFP/z8xcEWZO2520JZDX3EaweMXAQZzFGzpGh8sy5bcD
HOfGaXV2W1wh2SrvTMBcP+rSaQIHAgYgpmH3MfyaMDK1YjMmAn46XY21dI6+/wsM
WRDQns3WQf+f04VidYA1vEl1TOG/P/+n2tCjuBBPUTPPQqQQCoPu9MobSAGohGv0
K82nyM6dZeIS8wHLzZj9yt5pSod61CRzI/boVw==
-----END PGP MESSAGE-----

A.7. Sample AEAD-GCM encryption and decryption

This example encrypts the cleartext string Hello, world! with the password password, using AES-128 with AEAD-GCM encryption.¶

  Iterated and Salted S2K

  65011712 (255), SHA2-256

  e9 d3 97 85 b2 07 00 08

  c3 3c

  05 1a 07 03 0b 03 08 e9 d3 97 85 b2 07 00 08 ff
  b4 2e

  b4 2e 7c 48 3e f4 88 44 57 cb 37 26

  0c 0c 4b f3 f2 cd 6c b7 b6 e3 8b 5b f3 34 67 c1
  c7 19 44 dd 59 03 46 66 2f 5a de 61 ff 84 bc e0

  25 02 81 71 5b ba 78 28 ef 71 ef 64 c4 78 47 53

  c3 05 07 03

  de ec e5 81 8b c0 aa b9 0f 8a fb 02 fa 00 cd 13

  c3 05 07 03

  b4 2e 7c 48 3e f4 88 44 57 cb 37 26

  19 36 fc 85 68 98 02 74 bb 90 0d 83 19 36 0c 77

  d2 69

  02 07 03 06

  fc b9 44 90 bc b9 8b bd c9 d1 06 c6 09 02 66 94
  0f 72 e8 9e dc 21 b5 59 6b 15 76 b1 01 ed 0f 9f

  fc 6f c6 d6 5b bf d2 4d cd 07 90 96 6e 6d 1e 85
  a3 00 53 78 4c b1 d8 b6 a0 69 9e f1 21 55 a7 b2
  ad 62 58 53 1b

  57 65 1f d7 77 79 12 fa 95 e3 5d 9b 40 21 6f 69

  a4 c2 48 db 28 ff 43 31 f1 63 29 07 39 9e 6f f9

  d2 02 07 03 06

  ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d
  4d 2b dc 2b

  ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d

  4d 2b dc 2b

  4d 2b dc 2b 00 00 00 00 00 00 00 00

  d2 02 07 03 06

  cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
  6f 72 6c 64 21

  d5 0e 1c e2 26 9a 9e dd ef 81 03 21 72 b7 ed 7c

  4d 2b dc 2b 00 00 00 00 00 00 00 01

  d2 02 07 03 06 00 00 00 00 00 00 00 25

-----BEGIN PGP MESSAGE-----

wzwFGgcDCwMI6dOXhbIHAAj/tC58SD70iERXyzcmDAxL8/LNbLe244tb8zRnwccZ
RN1ZA0ZmL1reYf+EvODSaQIHAwb8uUSQvLmLvcnRBsYJAmaUD3LontwhtVlrFXax
Ae0Pn/xvxtZbv9JNzQeQlm5tHoWjAFN4TLHYtqBpnvEhVaeyrWJYUxtXZR/Xd3kS
+pXjXZtAIW9ppMJI2yj/QzHxYykHOZ5v+Q==
-----END PGP MESSAGE-----

A.8. Sample messages encrypted using Argon2

These messages are the literal data "Hello, world!" encrypted using v1 SEIPD, with Argon2 and the passphrase "password", using different 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 cases, the Argon2 parameters are t = 1, p = 4, and m = 21.¶

-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 128-bit key
Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F

wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+
YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH
XfA3pqV4mTzF
-----END PGP MESSAGE-----

-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 192-bit key
Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955...
Comment: Session key: ...AF8DFE194

wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw
F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys
LVg77Mwwfgl2n/d572WciAM=
-----END PGP MESSAGE-----

-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 256-bit key
Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF
Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0

wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu
623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K
95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ==
-----END PGP MESSAGE-----