Persistent Symmetric Keys in OpenPGP

Internet-Draft	Persistent Symmetric Keys in OpenPGP	January 2025
Huigens	Expires 3 August 2025	[Page]

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 August 2025.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

The OpenPGP standard [RFC9580] 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 private 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 [RFC9580].¶

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 hash-based message authentication codes (HMAC) as a symmetric counterpart to digital signatures, for long-term storage and archival of attestations of authenticity and certification.¶

2. 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 [RFC2119]. 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 [RFC9580]. Any [RFC2119] keyword within this document applies to compliant applications only.¶

3. 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 [Shor]. Symmetric cryptography is also affected by quantum computing but to a lesser extent, which can be countered by using larger keys [Grover]. While the standardization of quantum-secure asymmetric cryptography in OpenPGP is ongoing [PQCinOpenPGP], 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.¶

4. Reusing and Renaming Packets

Rather than introducing new packets for storing persistent symmetric keys, the existing Secret-Key packets are reused for this purpose. To indicate the type of keys, two algorithms (AEAD and HMAC) are registered, whose IDs can be used in the place of public-key algorithm IDs. To accommodate these additions, we propose renaming the Public Key Algorithms registry to Persistent Key Algorithms.¶

Similarly, we reuse the Signature packet for "symmetric signatures". For 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. Nevertheless, given this usage, the naming of these packets may be confusing, so we propose to rename them to "String-to-Key Encrypted Session Key packet" and "Persistent Key Encrypted Session Key packet", instead.¶

5. Persistent Symmetric Key Algorithms

This document defines two new algorithms for use with OpenPGP, extending table 18 of [RFC9580].¶

In addition, it reserves space for future, private and experimental persistent symmetric key algorithms.¶

Table 1: Persistent Symmetric Key Algorithm registrations
ID	Algorithm	Public Key Format	Secret Key Format	Signature Format	PKESK Format
128	AEAD	sym. algo, AEAD algo, fingerprint seed [Section 5.1]	key material	N/A	IV, ciphertext [Section 5.3]
129	HMAC [RFC2104]	hash algo, fingerprint seed [Section 5.2]	key material	authentication tag [Section 5.4]	N/A
130 to 140	Reserved for Future Persistent Symmetric Key Algorithms
200 to 210	Private or Experimental Persistent Symmetric Key Algorithms

These algorithm IDs can be used to store symmetric key material in Secret-Key Packets and Secret-Subkey packets (see section 5.5.3 of [RFC9580]). The AEAD algorithm ID (and future, private or experimental symmetric encryption algorithms) can be used to store session keys encrypted using AEAD in PKESK packets (see section 5.1 of [RFC9580]). The HMAC algorithm ID (and future, private or experimental symmetric authentication algorithms) can be used to store HMAC-based signatures in Signature packets (see section 5.2 of [RFC9580]).¶

As the secret key material is required for all cryptographic operations with symmetric keys, implementations SHOULD NOT use symmetric algorithm IDs in Public-Key Packets or Public-Subkey Packets, and SHOULD NOT export Public-Key Packets from Secret-Key Packets holding symmetric key material.¶

When storing encrypted symmetric key material in a Secret-Key Packet or Secret-Subkey Packet, AEAD encryption (S2K usage octet 253, see section 3.7.2.1 of [RFC9580]) MUST be used, to ensure that the secret key material is bound to the fingerprint. Implementations MUST NOT decrypt symmetric key material in a Secret-Key Packet or Secret-Subkey Packet that was encrypted using a different method.¶

5.1. Algorithm-Specific Fields for AEAD keys

The public key is this series of values:¶

A one-octet symmetric algorithm identifier (see section 9.3 of [RFC9580])¶
A one-octet AEAD algorithm (see section 9.6 of [RFC9580])¶
A 32-octet random seed to randomize the key fingerprint¶

The secret key is this single value:¶

Symmetric key material of the appropriate length for the given symmetric algorithm¶

5.2. Algorithm-Specific Fields for HMAC keys

The public key is this series of values:¶

A one-octet hash algorithm identifier (see section 9.5 of [RFC9580])¶
A 32-octet random seed to randomize the key fingerprint¶

The secret key is this single value:¶

Symmetric key material of the length of the hash output size of the given hash algorithm¶

5.3. Algorithm-Specific Fields for AEAD encryption

A starting initialization vector of size specified by AEAD mode¶
A symmetric key encryption of the plaintext value described in section 5.1 of [RFC9580], performed using the selected symmetric-key cipher operating in the given AEAD mode, including the authentication tag.¶

5.4. Algorithm-Specific Fields for HMAC signatures

An authentication tag of appropriate length for the hash algorithm¶

Although not required by HMAC, to maintain consistency with existing signature algorithms, HMAC tags are produced from appropriately hashed data, as per section 5.2.4 of [RFC9580].¶

6. Security Considerations

Security considerations are discussed throughout the document where appropriate.¶

7. IANA Considerations

7.1. Updates to Public Key Algorithms

IANA is requested to rename the "OpenPGP Public Key Algorithms" registry to "OpenPGP Persistent Key Algorithms", and add the entries in Table 1 to the registry.¶

7.2. Updates to Packet Type Descriptions

IANA is requested to modify the "OpenPGP Packet Types" registry as follows:¶

For Packet Tag 1 ("Public-Key Encrypted Session Key Packet"), change the Packet Type Description to "Persistent Key Encrypted Session Key Packet".¶
For Packet Tag 3 ("Symmetric-Key Encrypted Session Key Packet"), change the Packet Type Description to "String-to-Key Encrypted Session Key Packet".¶

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

Appendix A. Test Vectors

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

A.1. V6 Key

A.1.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:¶

A v6 HMAC Private-Key packet¶
A v6 direct key self-signature¶
A User ID packet¶
A v6 positive certification self-signature¶
A v6 AEAD Private-Subkey packet¶
A v6 subkey binding signature¶

The primary key has the fingerprint 39d3d9b684974edecfa0a31ccfc7a646eca61ee616a42d8e18e2741110994ac7.¶

The subkey has the fingerprint 8431344883f607c31fc112c501b26fb4c3a3696b0f1a1accf3eba78107dc2b3a.¶

A.1.2. Encrypted and Signed Message

Here is the message "Testing\n" encrypted and signed using the secret key Appendix A.1.1, consisting of:¶

A v6 PKESK packet¶
A v2 SEIPD packet¶

The hex-encoded AEAD key used to encrypt the session key is 144d188b5618c745156d1c9ea7c42714e97cb0705189c01e1c4c4b05a65a08ee.¶

The hex-encoded session key is 2ff2190e39a3b12fdf35b0da30a2895f215628cdb237b58686da8d017da59acb.¶

A.2. V4 Key

A.2.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:¶

A v4 HMAC Private-Key packet¶
A User ID packet¶
A v4 positive certification self-signature¶
A v4 AEAD Private-Subkey packet¶
A v4 subkey binding signature¶

The primary key has the fingerprint 342723d5eb7656bb23d58f738a1e196684722f7d.¶

The subkey has the fingerprint 3b642f094fd733630916e9987a60b1ebb00db44c.¶

A.2.2. Encrypted and Signed Message

Here is the message "Testing\n" encrypted and signed using the secret key Appendix A.2.1, consisting of:¶

A v3 PKESK packet¶
A v1 SEIPD packet¶

The hex-encoded AEAD key used to encrypt the session key is b2b1362326be62625621adbbb8bb7d65f567e41ebc9550f6abaa131f883bd56b.¶

The hex-encoded session key is 0010c335e6ce3a2553ad495ef6bdd30f57d6a4a07b74ed3c1bfd2a49226446e7.¶

Author's Address

Daniel Huigens (editor)

Proton AG

Route de la Galaise 32

CH-1228 Plan-les-Ouates

Switzerland

Email: d.huigens@protonmail.com