OpenPGP

1.1. Terms

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].¶

Some terminology used in this document has been improved from previous versions of the OpenPGP specification. See Appendix B.1 for more details.¶

2.1. Confidentiality via Encryption

OpenPGP combines symmetric-key encryption and (optionally) public-key encryption to provide confidentiality. When using public keys, 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 implementation generates a random session key for this message.¶
3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message.¶
4. The sending OpenPGP implementation optionally compresses the message, and then encrypts it using a message key derived from the session key. The encrypted message forms the remainder of the OpenPGP message.¶
5. The receiving OpenPGP implementation decrypts the session key using the recipient's private key.¶
6. The receiving OpenPGP implementation decrypts the message using the message key derived from the session key. If the message was compressed, it will be decompressed.¶

When using symmetric-key encryption, a similar process as described above is used, but the session key is encrypted with a symmetric algorithm derived 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 message key derived from the 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 cryptographic hash function and a public-key signature algorithm. The sequence is as follows:¶

1. The sender creates a message.¶
2. The sending implementation generates a hash digest of the message.¶
3. The sending implementation generates a signature from the hash digest using the sender's private key.¶
4. The signature is attached to or transmitted alongside the message.¶
5. The receiving implementation obtains a copy of the message and the message signature.¶
6. The receiving implementation generates a new hash digest 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

An OpenPGP implementation MAY support the compression of data. Many existing OpenPGP messages are compressed. Implementers, such as those working on constrained implementations that do not want to support compression, might want to consider at least implementing decompression.¶

2.4. Conversion to Base64

OpenPGP's underlying native representation for encrypted messages, signatures, keys, and certificates 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 transport raw binary data, a printable encoding of these binary octets is defined. The raw 8-bit binary octet stream can be converted to a stream of printable ASCII characters using base64 encoding, in a format called ASCII Armor (see Section 6).¶

Implementations SHOULD support base64 conversions.¶

2.5. Signature-Only Applications

OpenPGP is designed for applications that use both encryption and signatures, but there are a number of use cases that only require 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 support.¶

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 in the octet strings identified by square brackets 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 v6 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.¶

3.3. Key IDs and Fingerprints

A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. A fingerprint is more likely to be unique than a key ID. The fingerprint and key ID of a key are calculated differently according to the version of the key.¶

Section 5.5.4 describes how Key IDs and Fingerprints 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) Specifier

A string-to-key (S2K) specifier type is used to convert a passphrase string into a symmetric-key encryption/decryption key. Passphrases requiring use of S2K conversion are currently used in two places: to encrypt the secret part of private keys, and 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 encoded_m, specifying the exponent of the memory size

  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 type ID specifying its meaning. An OpenPGP message, keyring, certificate, detached signature, 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 abort without writing outside the indicated range and MUST treat the packet as 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 denotes the format of the rest of the header, and encodes the Packet Type ID, indicating the type of the packet (see Section 5). 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 [RFC4880] and [RFC2440], and the Legacy packet format as used by implementations predating any IETF specification of the protocol.¶

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

                          ┌───────────────┐
  Encoded Packet Type ID: │7 6 5 4 3 2 1 0│
                          └───────────────┘
  OpenPGP format:
    Bit 7 -- always one
    Bit 6 -- always one
    Bits 5 to 0 -- packet type ID

  Legacy format:
    Bit 7 -- always one
    Bit 6 -- always zero
    Bits 5 to 2 -- packet type ID
    Bits 1 to 0 -- length-type

Bit 6 of the first octet of the packet header indicates whether the packet is encoded in the OpenPGP or Legacy packet format. The Legacy packet format MAY be used when consuming packets to facilitate interoperability 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. This latter case is extremely unlikely, as the Legacy packet format was obsoleted by [RFC2440] in 1998.¶

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.¶

Note that Legacy format headers only have 4 bits for the packet type ID, and hence can only encode packet type IDs less than 16, whereas the OpenPGP format headers can encode IDs as great as 63.¶

  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 Criticality

The Packet Type ID space is partitioned into critical packets and non-critical packets. If an implementation encounters a critical packet where the packet type is unknown in a packet sequence, it MUST reject the whole packet sequence (see Section 10). On the other hand, an unknown non-critical packet MUST be ignored.¶

Packets with Type IDs from 0 to 39 are critical. Packets with Type IDs from 40 to 63 are non-critical.¶

5.1. Public-Key Encrypted Session Key Packet (Type ID 1)

Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or Symmetric-Key Encrypted Session Key packets (Section 5.3) 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 6. 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 10.3.2.1). Any new version of the PKESK packet should be registered in the registry established in Section 10.3.2.1.¶

5.2. Signature Packet (Type ID 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 6 provide an expandable format with subpackets that can specify more information about the signature.¶

For historical reasons, versions 1, 2, and 5 of the Signature packet are unspecified. Any new Signature packet version should be registered in the registry established in Section 10.3.2.2.¶

An implementation MUST generate a version 6 signature when signing with a version 6 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. See Section 10.3.2.2 for more details about packet version correspondence between keys and 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 Packet (Type ID 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 precede 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 6. The remainder of the packet depends on the version.¶

The versions differ in how they encrypt the session key with the passphrase, and in what they encode. The version of the SKESK packet must align with the version of the SEIPD packet (see Section 10.3.2.1). Any new version of the SKESK packet should be registered in the registry established in Section 10.3.2.1.¶

5.4. One-Pass Signature Packet (Type ID 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 6. Any new One-Pass Signature packet version should be registered in the registry established in Section 10.3.2.2.¶
• A one-octet signature type ID. 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 v6 packets, a variable-length field containing:¶

  • A one-octet salt size. The value MUST match the value defined for the hash algorithm as specified in Table 23.¶
  • The salt; a random value of the specified size. 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 v6 packets, 32 octets of the fingerprint of the signing key. Since a v6 signature can only be made by a v6 key, the length of the fingerprint is fixed.¶
• 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). See Section 10.3.2.2 for the full correspondence of versions between Keys, Signatures, and One-Pass Signatures.¶

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 Packets

A key material packet contains all the information about a public or private key. There are four variants of this packet type, two major versions (versions 4 and 6), and two strongly deprecated versions (versions 2 and 3). Consequently, this section is complex.¶

For historical reasons, versions 1 and 5 of the key packets are unspecified.¶

def curve25519Legacy_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)

5.6. Compressed Data Packet (Type ID 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 data that is a compression of a series of OpenPGP packets. See Section 10 for details on how messages are formed.¶

A ZIP-compressed series of packets is compressed into raw [RFC1951] DEFLATE blocks.¶

A ZLIB-compressed series of packets is compressed with raw [RFC1950] ZLIB-style blocks.¶

A BZip2-compressed series of packets is 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 predating support for [RFC2440] MAY interpret Compressed Data packets that use the Legacy format for packet framing.¶

5.7. Symmetrically Encrypted Data Packet (Type ID 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 SHOULD reject such a packet and stop processing the message. If an implementation chooses to process the packet anyway, it MUST return a clear warning that a non-integrity protected packet has been processed.¶

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

The body of this packet consists of:¶

• A random prefix, containing block-size random octets (for example, 16 octets for a 128-bit block length) followed by a copy of the last two octets, encrypted together using Cipher Feedback (CFB) mode, with an Initial Vector (IV) of all zeros.¶
• Data encrypted using CFB mode, with the last block-size octets of the first ciphertext as the IV.¶

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 ID 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 (see Section 12.9). For the random prefix, the Initial Vector (IV) is specified as all zeros. Instead of achieving randomized encryption through an IV, a string of length equal to the block size of the cipher plus two is encrypted for this purpose. The first block-size octets (for example, 16 octets for a 128-bit block length) are random, and the following two octets are copies of the last two octets of the first block-size random octets. For example, for a 16-octet block length, octet 17 is a copy of octet 15 and octet 18 is a copy of octet 16. For a cipher of block length 8, octet 9 is a copy of octet 7, and octet 10 is a copy of octet 8. (In both these examples, we consider the first octet to be numbered 1.)¶

After encrypting these block-size-plus-two octets, a new CFB context is created for the encryption of the data, with the last block-size octets of the first ciphertext as the IV. (Alternatively and equivalently, 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 two octets in the random prefix allows the receiver to immediately check whether the session key is incorrect. See Section 13.4 for hints on the proper use of this "quick check".¶

5.8. Marker Packet (Type ID 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 (Type ID 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.¶

  Some implementations predating [RFC2440] 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 implementation.¶

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 MUST 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 an implementation that predates support for [RFC2440] MAY interpret Literal Data packets that use the Legacy format for packet framing.¶

5.10. Trust Packet (Type ID 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 keyholders are trustworthy introducers, along with other information that implementation 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 (Type ID 13)

A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the keyholder. 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 (Type ID 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 ID (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. Symmetrically Encrypted Integrity Protected Data Packet (Type ID 18)

This packet (the "SEIPD" packet) contains integrity protected and encrypted data. When it has been decrypted, it will contain other packets forming an OpenPGP Message (see Section 10.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 mechanism was introduced in [RFC4880] and 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. See Section 13.7 for more details on choosing between these formats.¶

Any new version of the SEIPD packet should be registered in the registry established in Section 10.3.2.1.¶

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

5.14. Padding Packet (Type ID 21)

The Padding packet contains random data, and can be used to defend against traffic analysis (see Section 13.11) on version 2 SEIPD messages (see Section 5.13.2) and Transferable Public Keys (see Section 10.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 v6 Transferable Public Key that is transferred over an encrypted channel (see Section 10.1).¶
• As the last packet of an Optionally Padded Message within a version 2 Symmetrically Encrypted Integrity Protected Data packet (see Section 10.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 base64 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 base64, 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 base64 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 v6 Signature packets MUST NOT contain a CRC24 footer.¶
• An ASCII-armored Transferable Public Key packet sequence of a v6 key MUST NOT contain a CRC24 footer.¶
• An ASCII-armored keyring consisting of only v6 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 base64 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¶

7.1. Cleartext Signed Message Structure

An OpenPGP cleartext signed message consists of:¶

• The cleartext header -----BEGIN PGP SIGNED MESSAGE----- on a single line,¶
• Some implementations MAY include one or more legacy Hash Armor Headers, which MUST be ignored when well-formed (see Section 6.2.2.3),¶
• An empty line (not included into the message digest),¶
• The dash-escaped cleartext,¶
• A line ending separating the cleartext and following armored signature (not included into the message digest),¶
• The ASCII armored signature(s) including the -----BEGIN PGP SIGNATURE----- Armor Header and Armor Tail Lines.¶

As with any other text signature (Section 5.2.1.2), a cleartext signature is calculated on the text using canonical <CR><LF> line endings. As described above, the line ending before the -----BEGIN PGP SIGNATURE----- Armor Header Line of the armored signature is not considered part of the signed text.¶

Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the end of any line is removed before signing or verifying a cleartext signed message.¶

Between the -----BEGIN PGP SIGNED MESSAGE----- line and the first empty line, the only Armor Header permitted is a well-formed Hash Armor Header (see Section 6.2.2.3). To reduce the risk of confusion about what has been signed, a verifying implementation MUST decline to validate any signature in a cleartext message if that message has any other Armor Header present in this location.¶

7.2. 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.¶

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.¶

7.3. Issues with the Cleartext Signature Framework

Since creating a cleartext signed message involves trimming trailing whitespace on every line, the Cleartext Signature Framework will fail to safely round-trip any textual stream that may include semantically meaningful whitespace.¶

For example, the Unified Diff format [UNIFIED-DIFF] contains semantically meaningful whitespace: an empty line of context will consist of a line with a single " " (SPACE, U+0020) character, and any line that has trailing whitespace added or removed will represent such a change with semantically meaningful whitespace.¶

Furthermore, a Cleartext Signature Framework message that is very large is unlikely to work well. In particular, it will be difficult for any human reading the message to know which part of the message is covered by the signature because they can't understand the whole message at once, in case an Armor Header line is placed somewhere in the body. And, very large Cleartext Signature Framework messages cannot be processed in a single pass, since the signature salt and digest algorithms are only discovered at the end.¶

An implementation that knows it is working with a textual stream with any of the above characteristics SHOULD NOT use the Cleartext Signature Framework. Safe alternatives for a semantically meaningful OpenPGP signature over such a file format are:¶

• A Signed Message, as described in Section 10.3.¶
• A Detached Signature as described in Section 10.4.¶

Either of these alternatives may be ASCII-armored (see Section 6.2) if they need to be transmitted across a text-only (or 7-bit clean) channel.¶

Finally, when a Cleartext Signature Framework message is presented to the user as-is, an attacker can include additional text in the Hash header, which may mislead the user into thinking it is part of the signed text. The signature validation constraints described in Section 6.2.2.3 and Section 7.1 help to mitigate the risk of arbitrary or misleading text in the Armor Headers.¶

9.1. Public-Key Algorithms

Implementations MUST implement Ed25519 (27) for signatures, and X25519 (25) for encryption. Implementations SHOULD implement Ed448 (28) and X448 (26).¶

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 12.4. Elgamal (16) keys are deprecated and MUST NOT be generated (see Section 12.6). DSA (17) keys are deprecated and MUST NOT be generated (see Section 12.5). See Section 12.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]) has 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 11.5 of this document.¶

9.2. ECC Curves for OpenPGP

The parameter curve OID is an array of octets that defines 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 or native point representations for the curve can be represented in that many octets. For the curves specified here, also scalars such as the base point order and the private key can be represented in fsize octets. Note that, however, there exist curves outside this specification where the representation of scalars requires an additional octet.¶

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.¶

The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used only in version 4 keys and signatures. Implementations MAY implement these variants for compatibility with existing v4 key material and signatures. Implementations MUST NOT accept or generate v6 key material using the deprecated OIDs.¶

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 implementations predating support for [RFC2440]. 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 generate packets using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF. Implementations MUST NOT decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF in a version 6 (or later) packet. 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. Transferable Public Keys

OpenPGP users may transfer public keys. This section describes the structure of public keys in transit to ensure interoperability. An OpenPGP Transferable Public Key is also known as an OpenPGP certificate, in order to distinguish it from both its constituent Public-Key packets (Section 5.5.1.1 and Section 5.5.1.2) and the underlying cryptographic key material.¶

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...]]...

10.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). An implementation 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. An implementation MAY choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.¶

10.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.¶

10.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.¶

11.1. 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". The three [FIPS186] curves and the three [RFC5639] curves can be used with ECDSA and ECDH public key algorithms. They are referenced using a sequence of octets, referred to as the curve OID. Section 9.2 describes in detail how this sequence of octets is formed.¶

Separate algorithms are also defined for the use of X25519 and X448, defined in [RFC7748]; and Ed25519 and Ed448, defined in [RFC8032]. Additionally, legacy OIDs are defined for "Curve25519Legacy" (for encryption using the ECDH algorithm) and "Ed25519Legacy" (for signing using the EdDSALegacy algorithm).¶

11.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

11.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.¶

11.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].¶

11.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 11.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 11.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 6 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, or 56 for Curve25519Legacy. For encrypting to a v6 key, the size of the sequence is either 66 for curve NIST P-256, 63 for curves NIST P-384 and NIST P-521, or 67 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1.¶

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 11.5.1 for the details regarding the choice of the KEK algorithm, which SHOULD be one of the three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394].¶

To produce the input to the key wrapping method, first concatenate the following values:¶

• The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).¶
• The session key.¶
• A two-octet checksum of the session key, equal to the sum of the session key octets, modulo 65536.¶

Then, the above values are padded using the method described in [RFC2898] to an 8-octet granularity.¶

For example, in a v3 Public-Key Encrypted Session Key packet, an AES-256 session key is encoded as follows, forming a 40 octet sequence:¶

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

The octets k0 to k31 above denote the session key, and the octets s0 and s1 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 v6 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, single-use 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])¶
• Wipe the memory that contained S, v, and Z to avoid leaking ephemeral secrets¶
• 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 with key pair (r,R) obtains the shared secret by calculating:¶

S = rV = rvG

12.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.

12.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 non-empty. 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 an implementation 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 implementation warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway.¶

12.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.¶

12.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.¶

12.5. DSA

DSA is no longer recommended. It has also been deprecated in [FIPS186]. Therefore, an implementation MUST NOT generate DSA keys.¶

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

12.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.¶

12.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.¶

12.8. Reserved Algorithm IDs

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 as reserved in Section 9.1.¶

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 algorithm ID of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].¶

12.9. CFB Mode

The Cipher Feedback (CFB) mode used in this document is defined in Section 6.3 of [SP800-38A].¶

The CFB segment size s is equal to the block size of the cipher (i.e., n-bit CFB mode where n is the block size is used).¶

12.10. Private or Experimental Parameters

S2K specifiers, Signature subpacket type IDs, User Attribute subpacket type IDs, image format IDs, and the various algorithm IDs described in Section 9 all reserve the range 100 to 110 for private and experimental use. Packet type IDs reserve the range 60 to 63 for 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.¶

12.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 keyholder'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.¶

13.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 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].¶

13.2. Advantages of Salted Signatures

V6 signatures include a salt that is hashed first, which size depends on the hashing algorithm. This makes v6 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, the signed hashes and the signatures are not predictable.¶

While the material to be signed could 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" [SHAMBLES], which leverages a chosen prefix collision attack against SHA-1. This means that an adversary carrying out a chosen-message attack will not be able to control the hash that is being signed, and will need to break second-preimage resistance instead of the simpler collision resistance to create two messages having the same signature. The size of the salt is bound to the hash function to match the expected collision resistance level, and at least 16 octets.¶

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.¶

13.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.¶

13.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 v1 SEIPD and SED packets can be used 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 encrypted data whose session key is protected by a passphrase using a version 4 SKESK, the quick check may be convenient to the user, by informing them early that they typed the wrong passphrase. But 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 13.7.¶

13.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 v6 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.¶

13.6. Fingerprint Usability

This specification uses fingerprints in several places on the wire (e.g., Section 5.2.3.23, Section 5.2.3.35, and Section 5.2.3.36), and in processing (e.g., in ECDH KDF Section 11.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. There is 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 ([USENIX-STUDY]).¶

The version 6 fingerprint makes the challenge for a human verifier even worse. At 256 bits (compared to v4's 160 bit fingerprint), a v6 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 v6 fingerprint for this discouraged use case.¶

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

13.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 [RFC4880] and later versions of OpenPGP offer mechanisms to defend against it. However, OpenPGP data may have been created before these defense 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 (MalleableCFB) or raw cipher algorithm: where the trailing 2-octet checksum does not match.¶
  • Value 254 (CFB): where the SHA1 checksum is mismatched.¶
  • Value 253 (AEAD): 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:¶

  • If all recipient keys indicate support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet in their Features subpacket (Section 5.2.3.32), or are v6 keys without a Features subpacket, or the implementation can otherwise infer that all recipients support v2 SEIPD packets, the implementation SHOULD 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.¶
• Passphrase-protected secret key material in a v6 Secret Key or v6 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. An implementation should be aware that, in scenarios where an attacker has write 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 are RECOMMENDED to migrate to AEAD.¶

13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature

The salted key derivation of v2 SEIPD packets (Section 5.13.2) allows the recipient of an encrypted message to reply to the sender and all other recipients without needing their public keys but by using the same v6 PKESK packets he received and a different random salt value. This ensures a secure mechanism on the cryptographic level that enables the use of message encryption in cases where a sender does not have a copy of an encryption-capable certificate for one or more participants in the conversation and thus can enhance the overall security of an application. However, care must be taken when using this mechanism not to create security vulnerabilities, such as the following.¶

• Replying to only a subset of the original recipients and the original sender by use of the session-key-reuse feature would mean that the remaining recipients (including the sender) of the original message could read the encrypted reply message, too.¶
• Adding a further recipient to the reply that is encrypted using the session-key-reuse feature gives that further recipient also cryptographic access to the original message that is being replied to (and potentially to a longer history of previous messages).¶
• A modification of the list of recipients addressed in the above points needs also to be safeguarded when a message is initially composed as a reply with session-key reuse but then first stored (e.g. as a draft) and later reopened for further editing and finally sent.¶
• There is the potential threat that an attacker with network or mailbox access, who is at the same time a recipient of the original message, silently removes themselves from the message before the victim's client receives it. The victim's client that then uses the mechanism for replying with session-key reuse would unknowingly compose an encrypted message that could be read by the attacker. Implementations are encouraged to use the Intended Recipient Fingerprint (Section 5.2.3.36) subpacket when composing messages and to use it to check the consistency of the set of recipients of a message before replying to it with session-key reuse.¶
• When using the session-key-reuse feature in any higher-layer protocol, care should be taken that there is no other potentially interfering practice of session-key reuse established in that protocol. Such interfering session-key reuse could for instance be given if an initial message is already composed by reusing the session key of an existing encrypted file the access to which may be shared among a group of users already. Using the session-key-reuse feature to compose an encrypted reply to such a message would unknowingly give this whole group of users cryptographic access to the encrypted message.¶
• Generally, the use of the session-key-reuse feature should be under the control of the user. Specifically, care should be taken that this feature is not silently used when the user assumes that proper public-key encryption is used. This can be the case for instance when the public key of one of the recipients of the reply is known but has expired. Special care should be taken to ensure that users do not get caught in continued use of the session-key reuse unknowingly but instead receive the chance to switch to proper fresh public-key encryption as soon as possible.¶
• Whenever possible, a client should prefer a fresh public key encryption over the session-key reuse.¶

Even though this not necessarily being a security aspect, note that initially composing an encrypted reply using the session-key-reuse feature on one client and storing it (e.g. as a draft) and later reopening the stored unfinished reply with another client that does not support the session-key-reuse feature may lead to interoperability problems.¶

Avoiding the pitfalls described above requires context-specific expertise. An implementation should only make use of the session-key-reuse feature in any particular application layer when it can follow reasonable documentation about how to deploy the feature safely in the specific application. At the time of this writing, there is no known documentation about safe reuse of OpenPGP session keys for any specific context. An implementer that intends to make use of this feature should publish their own proposed guidance for others to review.¶

13.9. 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 to produce a specific Revocation Signature (signature type IDs 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.23):¶

• 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.¶

13.10. 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 on Linux or BSD, 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 range of visibility 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.¶

13.11. 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 whom) 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).¶

13.12. 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, an implementation SHOULD implement the Intended Recipient Fingerprint signature subpacket (Section 5.2.3.36).¶

13.13. Hashed vs. Unhashed Subpackets

Each OpenPGP signature can have subpackets in two different sections. The first set of subpackets (the "hashed section") is covered by the signature itself. The second set has no cryptographic protections, and is used for advisory material only, including locally-stored annotations about the signature.¶

For example, consider an implementation working with a specific signature that happens to know that the signature was made by a certain key, even though the signature contains no Issuer Fingerprint subpacket (Section 5.2.3.35) in the hashed section. That implementation MAY synthesize an Issuer Fingerprint subpacket and store it in the unhashed section so that in the future it will be able to recall which key issued the signature.¶

Some subpackets are only useful when they are in the hashed section, and an implementation SHOULD ignore them when they are found with unknown provenance in the unhashed section. For example, a Preferred AEAD Ciphersuites subpacket (Section 5.2.3.15) in a direct key self-signature indicates the preferences of the keyholder when encrypting SEIPD v2 data to the key. An implementation that observes such a subpacket found in the unhashed section would open itself to an attack where the recipient's certificate is tampered with to encourage the use of a specific cipher or mode of operation.¶

13.14. Malicious Compressed Data

It is possible to form a compression quine that produces itself upon decompression, leading to infinite regress in any implementation willing to parse arbitrary numbers of layers of compression. This could cause resource exhaustion which itself could lead to it being terminated by the operating system. If the operating system would create a "crash report", that report could contain confidential information.¶

An OpenPGP implementation SHOULD limit the number of layers of compression it is willing to decompress in a single message.¶

14.1. Constrained Legacy Fingerprint Storage for v6 Keys

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

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

15.1. Rename "Pretty Good Privacy (PGP)" Protocol Group to "OpenPGP"

IANA bundles a set of registries associated with a particular protocol into a "protocol group". This document requests IANA to update the name of the "Pretty Good Privacy (PGP)" protocol group (i.e., the group of registries described at https://www.iana.org/assignments/pgp-parameters/) to "OpenPGP". If renaming the protocol group results in new URLs for the registries in this protocol group, please arrange for a permanent redirection (e.g., HTTP 301) from the existing URLs to the new URLs. All further updates specified below are for registries within this same "OpenPGP" protocol group.¶

15.2. Registries to be Renamed and Updated

IANA is requested to rename the "PGP String-to-Key (S2K)" registry to "OpenPGP String-to-Key (S2K) Types" and update its content to Table 1.¶

IANA is requested to rename the "PGP Packet Types/Tags" registry to "OpenPGP Packet Types" and update its content to Table 3.¶

IANA is requested to rename the "PGP User Attribute Types" registry to "OpenPGP User Attribute Subpacket Types" and update its content to Table 13.¶

IANA is requested to rename the "Image Format Subpacket Types" registry to "OpenPGP Image Attribute Encoding Format" and update its content to Table 15.¶

IANA is requested to rename the "Key Server Preference Extensions" registry to "OpenPGP Key Server Preference Flags" and update its contents to Table 8.¶

IANA is requested to rename the "Reason for Revocation Extensions" registry to "OpenPGP Reason for Revocation Code" and update its contents to Table 10.¶

IANA is requested to rename the "Key Flags Extensions" registry to "OpenPGP Key Flags" and update its contents to Table 9.¶

IANA is requested to rename the "Implementation Features" registry to "OpenPGP Features Flags" and update its contents to Table 11.¶

IANA is requested to rename the "Public Key Algorithms" registry to "OpenPGP Public Key Algorithms" and update its contents to Table 18.¶

IANA is requested to rename the "Symmetric Key Algorithms" registry to "OpenPGP Symmetric Key Algorithms" and update its contents to Table 21.¶

IANA is requested to rename the "Compression Algorithms" registry to "OpenPGP Compression Algorithms" and update its contents to Table 22.¶

IANA is requested to rename the "Hash Algorithms" registry to "OpenPGP Hash Algorithms" and update its contents to Table 23.¶

IANA is requested to rename the "Signature Subpacket Types" registry to "OpenPGP Signature Subpacket Types" and update its contents to Table 5.¶

15.3. Registries to be Removed

IANA is requested to remove the empty "New Packet Versions" registry.¶

A tombstone note should be added to the OpenPGP protocol group with the following content: Those wishing to use the removed "New Packet Versions" registry should instead register new versions of the relevant packets in the "OpenPGP Key and Signature Versions", "OpenPGP Key ID and Fingerprint" and "OpenPGP Encrypted Message Packet Versions" registries.¶

15.4. Registries to be Added

IANA is requested to add the following registries in the OpenPGP protocol group:¶

• OpenPGP Secret Key Encryption (S2K Usage Octet) containing Table 2.¶
• OpenPGP Signature Types containing Table 4.¶
• OpenPGP Signature Notation Data Subpacket Notation Flags containing Table 6.¶
• OpenPGP Signature Notation Data Subpacket Types containing Table 7.¶
• OpenPGP Key ID and Fingerprint containing Table 12.¶
• OpenPGP Image Attribute Version containing Table 14.¶
• OpenPGP Armor Header Line containing Table 16.¶
• OpenPGP Armor Header Key containing Table 17.¶
• OpenPGP ECC Curve OID and Usage containing Table 19.¶
• OpenPGP ECC Curve-specific Wire Formats containing Table 20.¶
• OpenPGP Hash Algorithm Identifiers for RSA Signatures use of EMSA-PKCS1-v1_5 Padding containing Table 24.¶
• OpenPGP AEAD Algorithms containing Table 25.¶
• OpenPGP Encrypted Message Packet Versions containing Table 26.¶
• OpenPGP Key and Signature Versions containing Table 27.¶
• OpenPGP Elliptic Curve Point Wire Formats containing Table 28.¶
• OpenPGP Elliptic Curve Scalar Encodings containing Table 29.¶
• OpenPGP ECDH KDF and KEK Parameters containing Table 30.¶

15.5. Registration Policies

IANA is requested to set all registries within the OpenPGP protocol group to use the SPECIFICATION REQUIRED registration policy, see Section 4.6 of [RFC8126] with the exception of the registries listed in Section 15.5.1, below. This policy means that review and approval by a designated expert is required, and that the IDs and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible.¶

15.6. Designated Experts

The designated experts will determine whether the new registrations retain the security properties that are expected by the base implementation and that these new registrations do not cause interoperability issues with existing implementations other than not producing or consuming the IDs associated with these new registrations. Registration proposals that fail to meet these criteria could instead be proposed as new work items for the OpenPGP working group or its successor.¶

The subsections below describe specific guidance for classes of registry updates that a designated expert will consider.¶

The designated experts should also consider Section 12.11 when reviewing proposed additions to the OpenPGP registries.¶

A.1. Sample v4 Ed25519Legacy 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 Ed25519Legacy 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 v6 Certificate (Transferable Public Key)

Here is a Transferable Public Key consisting of:¶

• A v6 Ed25519 Public-Key packet¶
• A v6 direct key self-signature¶
• A v6 X25519 Public-Subkey packet¶
• A v6 subkey binding signature¶

The primary key has the fingerprint CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9.¶

The subkey has the fingerprint 12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885.¶

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

xioGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laPCsQYf
GwoAAABCBYJjh3/jAwsJBwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxy
KwwfHifBilZwj2Ul7Ce62azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lw
gyU2kCcUmKfvBXbAf6rhRYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaE
QsiPlR4zxP/TP7mhfVEe7XWPxtnMUMtf15OyA51YBM4qBmOHf+MZAAAAIIaTJINn
+eUBXbki+PSAld2nhJh/LVmFsS+60WyvXkQ1wpsGGBsKAAAALAWCY4d/4wKbDCIh
BssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce62azJAAAAAAQBIKbpGG2dWTX8
j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDEM0g12vYxoWM8Y81W+bHBw805
I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUrk0mXubZvyl4GBg==
-----END PGP PUBLIC KEY BLOCK-----

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

0x0000  10 3e 2d 7d 22 7e c0 e6
0x0008  d7 ce 44 71 db 36 bf c9
0x0010  70 83 25 36 90 27 14 98
0x0018  a7 ef 05 76 c0 7f aa e1
0x0020  9b 00 00 00 2a 06 63 87
0x0028  7f e3 1b 00 00 00 20 f9
0x0030  4d a7 bb 48 d6 0a 61 e5
0x0038  67 70 6a 65 87 d0 33 19
0x0040  99 bb 9d 89 1a 08 24 2e
0x0048  ad 84 54 3d f8 95 a3 06
0x0050  1f 1b 0a 00 00 00 42 05
0x0058  82 63 87 7f e3 03 0b 09
0x0060  07 05 15 0a 0e 08 0c 02
0x0068  16 00 02 9b 03 02 1e 09
0x0070  22 21 06 cb 18 6c 4f 06
0x0078  09 a6 97 e4 d5 2d fa 6c
0x0080  72 2b 0c 1f 1e 27 c1 8a
0x0088  56 70 8f 65 25 ec 27 ba
0x0090  d9 ac c9 05 27 09 02 07
0x0098  02 06 ff 00 00 00 4a

0x0000  10 3e 2d 7d 22 7e c0 e6  salt
0x0008  d7 ce 44 71 db 36 bf c9
0x0010  70 83 25 36 90 27 14 98
0x0018  a7 ef 05 76 c0 7f aa e1
        [ pubkey begins ]
0x0020  9b                       v6 pubkey
0x0021     00 00 00 2a           pubkey length
0x0025                 06        pubkey version
0x0026                    63 87  creation time
0x0028  7f e3                      (2022-11-30T16:08:03Z)
0x002a        1b                 key algo: Ed25519
0x002b           00 00 00 20     key length
0x002f                       f9  Ed25519 public key
0x0030  4d a7 bb 48 d6 0a 61 e5
0x0038  67 70 6a 65 87 d0 33 19
0x0040  99 bb 9d 89 1a 08 24 2e
0x0048  ad 84 54 3d f8 95 a3
         [ trailer begins ]
0x004f                       06  sig version
0x0050  1f                       sig type: direct key signature
0x0051     1b                    sig algo: Ed25519
0x0052        0a                 hash ago: SHA2-512
0x0053           00 00 00 42     hashed subpackets length
0x0057                       05  subpkt length
0x0058  82                       critical subpkt: Sig Creation Time
0x0059     63 87 7f e3           Signature Creation Time
0x005d                 03        subpkt length
0x005e                    0b     subpkt type: Pref. v1 SEIPD Ciphers
0x005f                       09  Ciphers: [AES256 AES128]
0x0060  07
0x0061     05                    subpkt length
0x0062        15                 subpkt type: Pref. Hash Algorithms
0x0063           0a 0e           Hashes: [SHA2-512 SHA3-512
0x0065                 08 0c              SHA2-256 SHA3-256]
0x0067                       02  subpkt length
0x0068  16                       subpkt type: Pref. Compression
0x0069     00                    Compression: [none]
0x006a        02                 subpkt length
0x006b           9b              critical subpkt: Key Flags
0x006c              03           Key Flags: {certify, sign}
0x006d                 02        subpkt length
0x006e                    1e     subpkt type: Features
0x006f                       09  Features: {SEIPDv1, SEIPDv2}
0x0070  22                       subpkt length
0x0071     21                    subpkt type: Issuer Fingerprint
0x0072        06                 Fingerprint version 6
0x0073           cb 18 6c 4f 06  Issuer Fingerprint
0x0078  09 a6 97 e4 d5 2d fa 6c
0x0080  72 2b 0c 1f 1e 27 c1 8a
0x0088  56 70 8f 65 25 ec 27 ba
0x0090  d9 ac c9
0x0093           05              subpkt length
0x0094              27           subpkt type: Pref. AEAD Ciphersuites
0x0095                 09 02 07  Ciphersuites:
0x0098  02                         [ AES256-OCB, AES128-OCB ]
0x0099     06                    sig version
0x009a        ff                 sentinel octet
0x009b           00 00 00 4a     trailer length

0x0000  a6 e9 18 6d 9d 59 35 fc
0x0008  8f e5 63 14 cd b5 27 48
0x0010  6a 5a 51 20 f9 b7 62 a2
0x0018  35 a7 29 f0 39 01 0a 56
0x0020  9b 00 00 00 2a 06 63 87
0x0028  7f e3 1b 00 00 00 20 f9
0x0030  4d a7 bb 48 d6 0a 61 e5
0x0038  67 70 6a 65 87 d0 33 19
0x0040  99 bb 9d 89 1a 08 24 2e
0x0048  ad 84 54 3d f8 95 a3 9b
0x0050  00 00 00 2a 06 63 87 7f
0x0058  e3 19 00 00 00 20 86 93
0x0060  24 83 67 f9 e5 01 5d b9
0x0068  22 f8 f4 80 95 dd a7 84
0x0070  98 7f 2d 59 85 b1 2f ba
0x0078  d1 6c af 5e 44 35 06 18
0x0080  1b 0a 00 00 00 2c 05 82
0x0088  63 87 7f e3 02 9b 0c 22
0x0090  21 06 cb 18 6c 4f 06 09
0x0098  a6 97 e4 d5 2d fa 6c 72
0x00a0  2b 0c 1f 1e 27 c1 8a 56
0x00a8  70 8f 65 25 ec 27 ba d9
0x00b0  ac c9 06 ff 00 00 00 34

0x0000  a6 e9 18 6d 9d 59 35 fc  salt
0x0008  8f e5 63 14 cd b5 27 48
0x0010  6a 5a 51 20 f9 b7 62 a2
0x0018  35 a7 29 f0 39 01 0a 56
      [ primary pubkey begins ]
0x0020  9b                       v6 pubkey
0x0021     00 00 00 2a           pubkey length
0x0025                 06        pubkey version
0x0026                    63 87  creation time
0x0028  7f e3                      (2022-11-30T16:08:03Z)
0x002a        1b                 key algo: Ed25519
0x002b           00 00 00 20     key length
0x002f                       f9  Ed25519 public key
0x0030  4d a7 bb 48 d6 0a 61 e5
0x0038  67 70 6a 65 87 d0 33 19
0x0040  99 bb 9d 89 1a 08 24 2e
0x0048  ad 84 54 3d f8 95 a3
      [ subkey pubkey begins ]
0x004f                       9b  v6 key
0x0050  00 00 00 2a              pubkey length
0x0054              06           pubkey version
0x0055                 63 87 7f  creation time (2022-11-30T16:08:03Z)
0x0058  e3
0x0059     19                    key algo: X25519
0x005a        00 00 00 20        key length
0x005e                    86 93  X25519 public key
0x0060  24 83 67 f9 e5 01 5d b9
0x0068  22 f8 f4 80 95 dd a7 84
0x0070  98 7f 2d 59 85 b1 2f ba
0x0078  d1 6c af 5e 44 35
       [ trailer begins ]
0x007e                    06     sig version
0x007f                       18  sig type: Subkey Binding sig
0x0080  1b                       sig algo Ed25519
0x0081     0a                    hash algo: SHA2-512
0x0082        00 00 00 2c        hashed subpackets length
0x0086                    05     subpkt length
0x0087                       82  critical subpkt: Sig Creation Time
0x0088  63 87 7f e3              Signature Creation Time
0x008c              02           subpkt length
0x008d                 9b        critical subpkt: Key Flags
0x008e                    0c     Key Flags: {EncComms, EncStorage}
0x008f                       22  subpkt length
0x0090  21                       subpkt type: Issuer Fingerprint
0x0091     06                    Fingerprint version 6
0x0092        cb 18 6c 4f 06 09  Fingerprint
0x0098  a6 97 e4 d5 2d fa 6c 72
0x00a0  2b 0c 1f 1e 27 c1 8a 56
0x00a8  70 8f 65 25 ec 27 ba d9
0x00b0  ac c9
0x00b2        06                 sig version
0x00b3           ff              sentinel octet
0x00b4              00 00 00 34  trailer length

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

Here is a Transferable Secret Key consisting of:¶

• A v6 Ed25519 Secret-Key packet¶
• A v6 direct key self-signature¶
• A v6 X25519 Secret-Subkey packet¶
• A v6 subkey binding signature¶

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

xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB
exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ
BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh
RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe
7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/
LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG
GBsKAAAALAWCY4d/4wKbDCIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAAQBIKbpGG2dWTX8j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDE
M0g12vYxoWM8Y81W+bHBw805I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUr
k0mXubZvyl4GBg==
-----END PGP PRIVATE KEY BLOCK-----

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

A.5. Sample locked v6 Secret Key (Transferable Secret Key)

Here is the same secret key as in Appendix A.4, but the secret key material is locked with a passphrase using AEAD and Argon2.¶

The passphrase is the ASCII string:¶

correct horse battery staple

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

xYIGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laP9JgkC
FARdb9ccngltHraRe25uHuyuAQQVtKipJ0+r5jL4dacGWSAheCWPpITYiyfyIOPS
3gIDyg8f7strd1OB4+LZsUhcIjOMpVHgmiY/IutJkulneoBYwrEGHxsKAAAAQgWC
Y4d/4wMLCQcFFQoOCAwCFgACmwMCHgkiIQbLGGxPBgmml+TVLfpscisMHx4nwYpW
cI9lJewnutmsyQUnCQIHAgAAAACtKCAQPi19In7A5tfORHHbNr/JcIMlNpAnFJin
7wV2wH+q4UWFs7kDsBJ+xP2i8CMEWi7Ha8tPlXGpZR4UruETeh1mhELIj5UeM8T/
0z+5oX1RHu11j8bZzFDLX9eTsgOdWATHggZjh3/jGQAAACCGkySDZ/nlAV25Ivj0
gJXdp4SYfy1ZhbEvutFsr15ENf0mCQIUBA5hhGgp2oaavg6mFUXcFMwBBBUuE8qf
9Ock+xwusd+GAglBr5LVyr/lup3xxQvHXFSjjA2haXfoN6xUGRdDEHI6+uevKjVR
v5oAxgu7eJpaXNjCmwYYGwoAAAAsBYJjh3/jApsMIiEGyxhsTwYJppfk1S36bHIr
DB8eJ8GKVnCPZSXsJ7rZrMkAAAAABAEgpukYbZ1ZNfyP5WMUzbUnSGpaUSD5t2Ki
Nacp8DkBClZRa2c3AMQzSDXa9jGhYzxjzVb5scHDzTkjyRZWRdTq8U6L4da+/+Kt
ruh8m7Xo2ehSSFyWRSuTSZe5tm/KXgYG
-----END PGP PRIVATE KEY BLOCK-----

832bd2662a5c2b251ee3fc82aec349a766ca539015880133002e5a21960b3bcf

9e37cb26787f37e18db172795c4c297550d39ac82511d9af4c8706db6a77fd51

c50663877fe31b00000020f94da7bb48d60a61e567706a6587d0331999bb9d89
1a08242ead84543df895a3

f74a6ce873a089ef13a3da9ac059777bb22340d15eaa6c9dc0f8ef09035c67cd

3c60cb63285f62f4c3de49835786f011cf6f4c069f61232cd7013ff5fd31e603

c70663877fe319000000208693248367f9e5015db922f8f48095dda784987f2d
5985b12fbad16caf5e4435

A.6. Sample Cleartext Signed Message

Here is a signed message that uses the cleartext signature framework (Section 7). It can be verified with the certificate from (Appendix A.3).¶

Note that this message makes use of dash-escaping (Section 7.2) due to its contents.¶

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

What we need from the grocery store:

- - tofu
- - vegetables
- - noodles

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

wpgGARsKAAAAKQWCY5ijYyIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAGk2IHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usJ9BvuAqo
/FvLFuGWMbKAdA+epq7V4HOtAPlBWmU8QOd6aud+aSunHQaaEJ+iTFjP2OMW0KBr
NK2ay45cX1IVAQ==
-----END PGP SIGNATURE-----

The signature packet here is:¶

0x0000  c2                       packet type: Signature
0x0001     98                    packet length
0x0002        06                 signature version 6
0x0003           01              signature type: canonical text
0x0004              1b           pubkey algorithm: Ed25519
0x0005                 0a        hash algorithm used: SHA2-512
0x0006                    00 00  hashed subpackets length: 41
0x0008  00 29
0x000a        05                 subpkt length
0x000b           82              critical subpkt: Sig Creation Time
0x000c              63 98 a3 63   (2022-12-13T16:08:03Z)
0x0010  22                       subpkt length
0x0011     21                    subpkt type: issuer fingerprint
0x0012        06                 key version
0x0013           cb 18 6c 4f 06  v6 fingerprint
0x001a  09 a6 97 e4 d5 2d fa 6c
0x0020  72 2b 0c 1f 1e 27 c1 8a
0x0028  56 70 8f 65 25 ec 27 ba
0x0030  d9 ac c9
0x0033           00 00 00 00     unhashed subpackets length: 0
0x0037                       69  left 16 bits of signed hash
0x0038  36
0x0039     20                    salt length
0x003a        76 49 5f 50 21 88  salt
0x0040  90 f7 f5 e2 ee 3c 18 22
0x0048  51 4f 70 50 0f 55 1d 86
0x0050  e5 c9 21 e4 04 e3 4a 53
0x0058  fb ac
0x005a        27 d0 6f b8 0a a8  Ed25519 signature
0x0060  fc 5b cb 16 e1 96 31 b2
0x0068  80 74 0f 9e a6 ae d5 e0
0x0070  73 ad 00 f9 41 5a 65 3c
0x0078  40 e7 7a 6a e7 7e 69 2b
0x0080  a7 1d 06 9a 10 9f a2 4c
0x0088  58 cf d8 e3 16 d0 a0 6b
0x0090  34 ad 9a cb 8e 5c 5f 52
0x0098  15 01

The signature is made over the following data:¶

0x0000  76 49 5f 50 21 88 90 f7
0x0008  f5 e2 ee 3c 18 22 51 4f
0x0010  70 50 0f 55 1d 86 e5 c9
0x0018  21 e4 04 e3 4a 53 fb ac
0x0020  57 68 61 74 20 77 65 20
0x0028  6e 65 65 64 20 66 72 6f
0x0030  6d 20 74 68 65 20 67 72
0x0038  6f 63 65 72 79 20 73 74
0x0040  6f 72 65 3a 0d 0a 0d 0a
0x0048  2d 20 74 6f 66 75 0d 0a
0x0050  2d 20 76 65 67 65 74 61
0x0058  62 6c 65 73 0d 0a 2d 20
0x0060  6e 6f 6f 64 6c 65 73 0d
0x0068  0a 06 01 1b 0a 00 00 00
0x0070  29 05 82 63 98 a3 63 22
0x0078  21 06 cb 18 6c 4f 06 09
0x0080  a6 97 e4 d5 2d fa 6c 72
0x0088  2b 0c 1f 1e 27 c1 8a 56
0x0090  70 8f 65 25 ec 27 ba d9
0x0098  ac c9 06 ff 00 00 00 31

The same data, broken out by octet and semantics, is:¶

0x0000  76 49 5f 50 21 88 90 f7  salt
0x0008  f5 e2 ee 3c 18 22 51 4f
0x0010  70 50 0f 55 1d 86 e5 c9
0x0018  21 e4 04 e3 4a 53 fb ac
      [ message begins ]
0x0020  57 68 61 74 20 77 65 20  canonicalized message
0x0028  6e 65 65 64 20 66 72 6f
0x0030  6d 20 74 68 65 20 67 72
0x0038  6f 63 65 72 79 20 73 74
0x0040  6f 72 65 3a 0d 0a 0d 0a
0x0048  2d 20 74 6f 66 75 0d 0a
0x0050  2d 20 76 65 67 65 74 61
0x0058  62 6c 65 73 0d 0a 2d 20
0x0060  6e 6f 6f 64 6c 65 73 0d
0x0068  0a
      [ trailer begins ]
0x0069     06                    sig version
0x006a        01                 sigtype: canonical text
0x006b           1b              pubkey algorithm: Ed25519
0x006c              0a           hash algorithm: SHA2-512
0x006d                 00 00 00  hashed subpackets length
0x0070  29
0x0071     05                    subpacket length
0x0072        82                 critical subpkt: Sig Creation Time
0x0073           63 98 a3 63       (2022-12-13T16:08:03Z)
0x0077                       22  subpkt length
0x0078  21                       subpkt type: issuer fingerprint
0x0079     06                    key version
0x007a        cb 18 6c 4f 06 09  v6 fingerprint
0x0080  a6 97 e4 d5 2d fa 6c 72
0x0088  2b 0c 1f 1e 27 c1 8a 56
0x0090  70 8f 65 25 ec 27 ba d9
0x0098  ac c9
0x009a        06                 sig version
0x009b           ff              sentinel octet
0x009c              00 00 00 31  trailer length

The calculated SHA2-512 hash digest over this data is:¶

69365bf44a97af1f0844f1f6ab83fdf6b36f26692efaa621a8aac91c4e29ea07
e894cabc6e2f20eedfce6c03b89141a2cc7cbe245e6e7a5654addbec5000b89b

A.7. Sample inline-signed message

This is the same message and signature as in Appendix A.6, but as inline-signed message. The hashed data is exactly the same, and all intermediate values and annotated hex dumps are also applicable.¶

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

xEYGAQobIHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usyxhsTwYJppfk
1S36bHIrDB8eJ8GKVnCPZSXsJ7rZrMkBy0p1AAAAAABXaGF0IHdlIG5lZWQgZnJv
bSB0aGUgZ3JvY2VyeSBzdG9yZToKCi0gdG9mdQotIHZlZ2V0YWJsZXMKLSBub29k
bGVzCsKYBgEbCgAAACkFgmOYo2MiIQbLGGxPBgmml+TVLfpscisMHx4nwYpWcI9l
JewnutmsyQAAAABpNiB2SV9QIYiQ9/Xi7jwYIlFPcFAPVR2G5ckh5ATjSlP7rCfQ
b7gKqPxbyxbhljGygHQPnqau1eBzrQD5QVplPEDnemrnfmkrpx0GmhCfokxYz9jj
FtCgazStmsuOXF9SFQE=
-----END PGP MESSAGE-----

A.8. Sample X25519-AEAD-OCB encryption and decryption

This example encrypts the cleartext string Hello, world! for the sample cert (see Appendix A.3), using AES-128 with AEAD-OCB encryption.¶

0x0000  c1 5d 06 21 06 12 c8 3f
0x0008  1e 70 6f 63 08 fe 15 1a
0x0010  41 77 43 a1 f0 33 79 0e
0x0018  93 e9 97 84 88 d1 db 37
0x0020  8d a9 93 08 85 19 87 cf
0x0028  18 d5 f1 b5 3f 81 7c ce
0x0030  5a 00 4c f3 93 cc 89 58
0x0038  bd dc 06 5f 25 f8 4a f5
0x0040  09 b1 7d d3 67 64 18 de
0x0048  a3 55 43 79 56 61 79 01
0x0050  e0 69 57 fb ca 8a 6a 47
0x0058  a5 b5 15 3e 8d 3a b7

0x0000  c1                       packet type: PKESK
0x0001     5d                    packet length
0x0002        06                 PKESK version 6
0x0003           21              length of fingerprint
0x0004              06           Key version 6
0x0005                 12 c8 3f  Key fingerprint
0x0008  1e 70 6f 63 08 fe 15 1a
0x0010  41 77 43 a1 f0 33 79 0e
0x0018  93 e9 97 84 88 d1 db 37
0x0020  8d a9 93 08 85
0x0025                 19        algorithm: X25519
0x0026                    87 cf  Ephemeral key
0x0028  18 d5 f1 b5 3f 81 7c ce
0x0030  5a 00 4c f3 93 cc 89 58
0x0038  bd dc 06 5f 25 f8 4a f5
0x0040  09 b1 7d d3 67 64
0x0046                    18     ESK length
0x0047                       de  ESK
0x0048  a3 55 43 79 56 61 79 01
0x0050  e0 69 57 fb ca 8a 6a 47
0x0058  a5 b5 15 3e 8d 3a b7

  87 cf 18 d5 f1 b5 3f 81 7c ce 5a 00 4c f3 93 cc
  89 58 bd dc 06 5f 25 f8 4a f5 09 b1 7d d3 67 64

  af 1e 43 c0 d1 23 ef e8 93 a7 d4 d3 90 f3 a7 61
  e3 fa c3 3d fc 7f 3e da a8 30 c9 01 13 52 c7 79

  86 93 24 83 67 f9 e5 01 5d b9 22 f8 f4 80 95 dd
  a7 84 98 7f 2d 59 85 b1 2f ba d1 6c af 5e 44 35

  4d 60 0a 4f 79 4d 44 77 5c 57 a2 6e 0f ee fe d5
  58 e9 af ff d6 ad 0d 58 2d 57 fb 2b a2 dc ed b8

  67 e3 0e 69 cd c7 ba b2 a2 68 0d 78 ac a4 6a 2f
  8b 6e 2a e4 4d 39 8b dc 6f 92 c5 ad 4a 49 25 14

  f6 6d ad cf f6 45 92 23 9b 25 45 39 b6 4f f6 07

  dd 70 8f 6f a1 ed 65 11 4d 68 d2 34 3e 7c 2f 1d

0x0000  d2 69 02 07 02 06 61 64
0x0008  16 53 5b e0 b0 71 6d 60
0x0010  e0 52 a5 6c 4c 40 7f 9e
0x0018  b3 6b 0e fa fe 9a d0 a0
0x0020  df 9b 03 3c 69 a2 1b a9
0x0028  eb d2 c0 ec 95 bf 56 9d
0x0030  25 c9 99 ee 4a 3d e1 70
0x0038  58 f4 0d fa 8b 4c 68 2b
0x0040  e3 fb bb d7 b2 7e b0 f5
0x0048  9b b5 00 5f 80 c7 c6 f4
0x0050  03 88 c3 0a d4 06 ab 05
0x0058  13 dc d6 f9 fd 73 76 56
0x0060  28 6e 11 77 d0 0f 88 8a
0x0068  db 31 c4

0x0000  d2                       packet type: SEIPD
0x0001     69                    packet length
0x0002        02                 SEIPD version 2
0x0003           07              cipher: AES128
0x0004              02           AEAD mode: OCB
0x0005                 06        chunk size (2**12 octets)
0x0006                    61 64  salt
0x0008  16 53 5b e0 b0 71 6d 60
0x0010  e0 52 a5 6c 4c 40 7f 9e
0x0018  b3 6b 0e fa fe 9a d0 a0
0x0020  df 9b 03 3c 69 a2
0x0026                    1b a9  chunk #0 encrypted data
0x0028  eb d2 c0 ec 95 bf 56 9d
0x0030  25 c9 99 ee 4a 3d e1 70
0x0038  58 f4 0d fa 8b 4c 68 2b
0x0040  e3 fb bb d7 b2 7e b0 f5
0x0048  9b b5 00
0x004b           5f 80 c7 c6 f4  chunk #0 AEAD tag
0x0050  03 88 c3 0a d4 06 ab 05
0x0058  13 dc d6
0x005b           f9 fd 73 76 56  final AEAD tag (#1)
0x0060  28 6e 11 77 d0 0f 88 8a
0x0068  db 31 c4

  d2 02 07 02 06

  45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42
  5f af 32 50 21 2f f9

  45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42

  5f af 32 50 21 2f f9

  5f af 32 50 21 2f f9 00 00 00 00 00 00 00 00

  d2 02 07 02 06