]> 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, asymmetric algorithms included in OpenPGP are vulnerable to attacks that might become possible on quantum computers . Symmetric cryptography is also affected by quantum computing but to a lesser extent, which can be countered by using larger keys . While the standardization of quantum-secure asymmetric cryptography in OpenPGP is ongoing , and will be 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 ), as handling of persistent symmetric key material requires some care. For example, when extracting a Transferable Public Key from a Transferable Secret Key, persistent symmetric keys must be ignored. 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 section 3.7.2.1 of ) 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 section 10.2 of is extended to allow including Persistent Symmetric Key Packets. Persistent Symmetric Keys may be included together with asymmetric keys in a single sequence of Transferable Secret Keys. However, Persistent Symmetric Keys do not accept subcomponents, such as subkeys, User IDs, or direct-key signatures.

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 section 5.1 of ). It can also be used to store an AEAD authentication tag in a Signature packet (see section 5.2 of ). 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 section 9.3 of ). 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.

Algorithm-Specific Fields for Persistent Symmetric Encryption The encrypted session key consists of this series of values: A 1-octet AEAD algorithm ID (see section 9.6 of ). 32 octets of salt. The salt is used to derive the key-encryption key and MUST be securely generated (see section 13.10 of ). 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 section 5.1 of .

Algorithm-Specific Fields for Persistent Symmetric Signatures The signature consists of this series of values: A 1-octet AEAD algorithm ID (see section 9.6 of ). 32 octets of salt. The salt is used to derive the message authentication key and MUST be securely generated (see section 13.10 of ). 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 section 5.2.4 of . Although not required by AEAD algorithms, to maintain consistency with existing signature algorithms, AEAD authentication tags are produced from appropriately hashed data, as per section 5.2.4 of .

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 update the "OpenPGP Packet Types" registry with the entry in .

Updates to Public Key Algorithms IANA is requested to update the "OpenPGP Public Key Algorithms" registry with the entry in .

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.

&RFC2119; &RFC5869; &RFC6234; &RFC9580;

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.