Persistent Symmetric Keys in OpenPGP

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

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

Table of Contents

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

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. Creating and Reusing Packets

For storing persistent symmetric keys, we introduce a new packet (see Section 5), 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.¶

5. Persistent Symmetric Key Packet

This document defines a new OpenPGP packet, extending table 3 of [RFC9580].¶

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 [RFC9580]. 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 [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 Persistent Symmetric Key Packet that was encrypted using a different method.¶

6. Extended Transferable Secret Key Grammar

The Transferable Secret Key grammar defined in section 10.2 of [RFC9580] 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.¶

7. Persistent Symmetric Key Algorithm

This document defines one new algorithm for use with OpenPGP, updating table 18 of [RFC9580].¶

This algorithm ID can be used to store symmetric key material in a Persistent Symmetric Key Packet (see Section 5). It can also be used to store a session key encrypted using AEAD in a PKESK packet (see section 5.1 of [RFC9580]). It can also be used to store an AEAD authentication tag in a Signature packet (see section 5.2 of [RFC9580]).¶

Implementations MUST NOT use the symmetric algorithm ID in Public-Key Packets, Public-Subkey Packets, Secret-Key Packets or Secret-Subkey Packets.¶

8. Security Considerations

Security considerations are discussed throughout the document where appropriate.¶

9. IANA Considerations

10. 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, and Daniel Kahn Gillmor, in no particular order.¶

Author's Address