]> Proton AG

Route de la Galaise 32 Plan-les-Ouates 1228 Switzerland d.huigens@protonmail.com

sec Internet-Draft This document defines a new packet and algorithm for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for message authentication using AEAD authentication tags. This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The OpenPGP standard has supported symmetric encryption for data packets using session keys since its inception, as well as symmetric encryption using password-derived keys. This document extends the use of symmetric cryptography by adding support for persistent symmetric keys which can be stored in a transferable secret key, and used to symmetrically encrypt session keys, for long-term storage and archival of messages. This document uses authenticated encryption with associated data (AEAD) as defined by . The OpenPGP standard also supports the use of digital signatures for authentication and integrity but no similar symmetric mechanism exists in the standard. This document introduces the use of AEAD authentication tags as a symmetric counterpart to digital signatures, for long-term storage and archival of attestations of authenticity and certification.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Any implementation that adheres to the format and methods specified in this document is called a compliant application. Compliant applications are a subset of the broader set of OpenPGP applications described in . Any keyword within this document applies to compliant applications only.

Motivation When compared to asymmetric cryptography, symmetric cryptography can provide improved performance and equivalent security with smaller keys. In contexts that do not require asymmetric cryptography, such as secure data storage where the same user encrypts and decrypts data, symmetric cryptography can be used to take advantage of these benefits. Additionally, the asymmetric algorithms defined in are vulnerable to attacks that might become possible on quantum computers . While quantum-secure asymmetric cryptography in OpenPGP has been defined in , and is required to secure communications, there is a large body of existing messages encrypted with classical algorithms. Once persistent symmetric keys are available, these messages can be protected against future compromises efficiently by symmetrically re-encrypting the session key, and storing the message symmetrically encrypted for long-term storage and archival.

Creating and Reusing Packets For storing persistent symmetric keys, we introduce a new packet (see ), rather than reusing the Secret Key Packet, as its semantics are different, and the handling of persistent symmetric key material requires some care. For example, it's not possible to extract a public key from a persistent symmetric key, unlike from an asymmetric secret key (see ). For storing session keys encrypted with persistent symmetric keys, while a Symmetric-Key Encrypted Session Key packet exists, its semantics don't match our requirements, as it's intended to encrypt the session key with a user-provided password, and doesn't offer a way to store a reference to a persistent key. Therefore, we reuse the Public-Key Encrypted Session Key packet instead, which does offer the desired semantics. Similarly, we reuse the Signature packet for "symmetric signatures". For these use cases, no new packet is required as the handling of these packets requires no special care. To indicate the type of keys in the new and existing packets, a special persistent symmetric algorithm ID value 0 is registered, which can be used in the place of a public-key algorithm ID.

Persistent Symmetric Key Packet This document defines a new OpenPGP packet, extending table 3 of . ID Critical Packet Type Description Shorthand 40 No Persistent Symmetric Key Packet PSK The Persistent Symmetric Key Packet (Type ID 40) has identical fields to the Secret Key Packet (Type ID 5). However, only version 6 of the packet is defined. Earlier versions of the Secret Key Packet format MUST NOT be used with the Persistent Symmetric Key Packet. The Persistent Symmetric Key Packet MUST NOT be used with asymmetric algorithms, i.e. any of the public key algorithms defined in table 18 of . It may only be used with the persistent symmetric algorithm defined below, with special algorithm ID value 0. When storing encrypted symmetric key material in a Persistent Symmetric Key Packet, AEAD encryption (S2K usage octet 253, see ) MUST be used, to ensure that the secret key material is bound to the fingerprint. Implementations MUST NOT decrypt symmetric key material in a Persistent Symmetric Key Packet that was encrypted using a different method.

Extended Transferable Secret Key Grammar The Transferable Secret Key grammar defined in is updated to additionally allow a single Persistent Symmetric Key Packet to constitute a valid Transferable Secret Key. Persistent Symmetric Keys MUST NOT include any subkeys, User IDs or Attributes, or direct-key or binding signatures, and implementations MUST reject Persistent Symmetric Keys that do include them. However, Persistent Symmetric Keys MAY be concatenated together with other (asymmetric or symmetric) Transferable Secret Keys in a single sequence of Transferable Secret Keys (such as the KEYS object defined by ). Note that the Transferable Public Key grammar defined in is not updated to allow a Persistent Symmetric Key Packet. A Transferable Public Key MUST NOT contain a Persistent Symmetric Key Packet, and implementations MUST reject a Transferable Public Key that does contain it. Therefore, extracting a Transferable Public Key from a Transferable Secret Key consisting of a Persistent Symmetric Key Packet is not possible. When extracting a sequence of Transferable Public Keys (such as the CERTS object defined by ) from a sequence of Transferable Secret Keys containing a mix of symmetric and asymmetric keys, implementations MUST ignore the Persistent Symmetric Keys and return a sequence of Transferable Public Keys corresponding to the asymmetric keys, only.

Persistent Symmetric Key Algorithm This document defines one new algorithm for use with OpenPGP, updating table 18 of . ID Algorithm Public Key Format Secret Key Format Signature Format PKESK Format 0 AEAD sym. algo, fingerprint seed [] key material AEAD algo, salt, authentication tag [] AEAD algo, salt, ciphertext [] This algorithm ID can be used to store symmetric key material in a Persistent Symmetric Key Packet (see ). It can also be used to store a session key encrypted using AEAD in a PKESK packet (see ). It can also be used to store an AEAD authentication tag in a Signature packet (see ). Implementations MUST NOT use the symmetric algorithm ID in Public-Key Packets, Public-Subkey Packets, Secret-Key Packets or Secret-Subkey Packets.

Algorithm-Specific Fields for Persistent Symmetric Keys The public key material consists of this series of values: A 1-octet symmetric algorithm ID (see ). A 32-octet random seed to randomize the key fingerprint. The secret key material consists of this single value: Symmetric key material of the appropriate length for the given symmetric algorithm. Implementations MUST NOT generate or use (i.e. encrypt, decrypt, sign, or verify with) persistent symmetric keys using a symmetric algorithm other than AES-128, AES-192, AES-256, Camellia-128, Camellia-192, Camellia-256, or other future algorithms defined for OpenPGP that are at least as strong as one of those algorithms.

Algorithm-Specific Fields for Persistent Symmetric Encryption The encrypted session key consists of this series of values: A 1-octet AEAD algorithm ID (see ). 32 octets of salt. The salt is used to derive the key-encryption key and MUST be securely generated (see ). The ciphertext and authentication tag resulting from a symmetric key encryption performed using the symmetric-key cipher of the key and the indicated AEAD mode, with the key-encryption key and IV computed as described in , and as additional data the empty string. The following values are concatenated and then encrypted: The 1-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet). The session key described in .

Algorithm-Specific Fields for Persistent Symmetric Signatures The signature consists of this series of values: A 1-octet AEAD algorithm ID (see ). 32 octets of salt. The salt is used to derive the message authentication key and MUST be securely generated (see ). The authentication tag resulting from encrypting the empty string using the symmetric-key cipher of the key and the indicated AEAD mode, with the message authentication key and IV computed as described in , and as additional data the hash digest described in . Although not required by AEAD algorithms, to maintain consistency with existing signature algorithms, AEAD authentication tags are produced from appropriately hashed data, as per .

Key and IV derivation When encrypting a session key or authenticating a message using a persistent symmetric key, the persistent key material and the salt are used to derive an M-bit key and N bits used as initialization vector, where M is the key size of the symmetric algorithm and N is the nonce size of the AEAD algorithm. M + N bits are derived using HKDF (see ). The left-most M bits are used as symmetric algorithm key, the remaining N bits are used as initialization vector. HKDF is used with SHA512 () as hash algorithm, the persistent key material as Initial Keying Material (IKM), the salt as salt, and the Packet Type ID in OpenPGP format encoding (bits 7 and 6 set, bits 5-0 carry the packet type ID), packet version number, cipher algorithm ID and AEAD algorithm ID as info parameter. For example, for a version 6 PKESK packet, when using AES-128 in OCB mode, the info parameter would be the octets 0xC1, 0x06, 0x07, 0x02. For a version 6 Signature packet, when using AES-256 in GCM mode, the info parameter would be the octets 0xC2, 0x06, 0x09, 0x03.

Security Considerations Security considerations are discussed throughout the document where appropriate.

IANA Considerations

Updates to Packet Types IANA is requested to add a row to the "OpenPGP Packet Types" registry with the entry in . The new row's Reference column should point to this document.

Updates to Public Key Algorithms IANA is requested to update the "OpenPGP Public Key Algorithms" registry by amending the row with ID 0 to the values in . The Reference column of that row should be updated to point to this document.

Acknowledgements An initial version of this draft was written by Dan Ristea (Proton AG), with guidance from Dr Philipp Jovanovic (University College London) and the editor. Thanks to feedback and suggestions from Andrew Gallagher, Heiko Schäfer, Justus Winter, Falko Strenzke, Daniel Kahn Gillmor, and Lara Bruseghini, in no particular order.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Federal Information Processing Standard, FIPS This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending RFC 9580. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with Elliptic Curve Cryptography (ECC), and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. American Civil Liberties Union Proton AG This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets.

Test Vectors To help implementing this specification a set of non-normative examples follow here.

Transferable Secret Key Here is a Transferable Secret Key consisting of: A v6 Persistent Symmetric Key packet

The key has the fingerprint eeea1e834ed8aacf3d938a5ccc6a177fcb7775c290eb02c3c17e5fdaa559b2a5. The raw key material is 4f8681aa678cde8465ba0b85256a40bd (for AES-128).

V6 Encrypted Message Here is the message "Hello World" encrypted using the secret key in , consisting of: A v6 PKESK packet A v2 SEIPD packet

The session key is encrypted using AES-128 in OCB mode. The HKDF info is c1060702. The key-encryption key is a64e6ac3aa262e42da23d5a14470857b. The IV is 2d9c726a1b01f60f3b05b89cb887f9. The additional data is the empty string. The encrypted session key is 25e5884dc13bcf40d5ab41b3bc23306ebb1907b4d586b2d678e21c496a8bf35a. The message is encrypted using AES-256 in GCM mode.

V3 Encrypted Message Here is the message "Hello World" encrypted using the secret key in , consisting of: A v3 PKESK packet A v1 SEIPD packet

The session key is encrypted using AES-128. The HKDF info is c1030702. The key-encryption key is 0c233981b8481ff68d253e78e9d7fc1b. The IV is 6186c39f7673f2d540f193e05ecab0. The additional data is the empty string. The encrypted session key is 5f43304125ba1728aab843c0a6d4ce75bd8eb3961a2025c3131e58223ecafee2. The message is encrypted using AES-256.

Detached Signature Here is a detached signature over the message "Hello World" signed using the secret key in , consisting of: A v6 Signature packet

The message is authenticated using AES-128 in OCB mode. The HKDF info is c2060702. The authentication key is 31988c7b45116e19b24ff29a1b93d4c2. The IV is 682aa0b80b031fe8882cecf1b6dca6. The additional data is 32342abfe99d053a5ea192b9192fb88210f6c479bc6a7be6e653e34147593bac.