Not every post-quantum migration problem requires a new public-key algorithm. On September 22, the IETF OpenPGP working group published revision 04 of Persistent Symmetric Keys in OpenPGP. The draft proposes persistent symmetric keys for data storage and other cases that do not require asymmetric cryptography, citing performance, smaller keys, and resistance to quantum attack as motivations.
This is an active working-group Internet-Draft, not a final RFC. Its value is broader than OpenPGP: it forces a distinction between cryptographic mechanism and operational purpose. A symmetric algorithm may avoid the quantum exposure of RSA or elliptic-curve key exchange, yet still fail operationally if key distribution, custody, recovery, rotation, or access policy is weak.
Start with the purpose of protection
Public-key encryption is useful when a sender must protect data for a recipient without already sharing a secret. Stored data under one administrative domain may have different requirements. If a durable secret can be managed safely, symmetric encryption can be simpler and more efficient.
That decision cannot be made from an algorithm inventory alone. Teams need to know who creates the data, who reads it, how many systems share access, how long confidentiality must last, whether offline recovery is required, and whether records cross organizational boundaries.
A useful inventory should connect:
- the dataset, archive, backup, application, host, location, and owner;
- confidentiality lifetime, retention rule, criticality, and recovery objective;
- algorithm, mode, parameters, library, and exact protocol profile;
- key purpose, identifier, generation source, storage boundary, and access policy;
- every encryptor, decryptor, automation account, administrator, and recovery operator;
- distribution, escrow, backup, restoration, rotation, revocation, and destruction paths;
- metadata leakage, integrity protection, nonce handling, and replay requirements;
- restore tests, negative tests, access reviews, and retirement evidence; and
- specification revision, maturity, exception, and review date.
Persistent keys change the blast radius
An ephemeral session key usually protects a bounded exchange. A persistent storage key may protect years of records and many copies. Compromise can expose historical data, future writes, backups, replicas, and disaster-recovery media unless designs use appropriate separation and rotation.
Organizations should record whether one key protects one object, one tenant, one dataset, one device, or an entire service. Envelope encryption can separate data-encryption keys from key-encryption keys, but it creates dependencies on wrapping algorithms, metadata, key versions, and recovery services. A quantum-resistant primitive does not reduce the consequences of excessive key reuse.
Sharing is a governance problem
Symmetric access means every authorized decryptor needs the same secret or derived material. As the population grows, distribution and revocation challenges grow too. Removing one recipient may require rekeying data or changing future encryption while maintaining controlled access to older records.
The inventory should identify actual consumers rather than a generic application owner. Service accounts, batch processes, endpoint clients, legal-hold systems, backup tools, and emergency operators can all be hidden dependencies. If one cannot be removed or upgraded, the dataset’s migration is constrained by that consumer.
Recovery must be proven
Persistent encryption is unforgiving: losing the key can be as damaging as disclosing it. Backup and escrow designs should preserve confidentiality while ensuring authorized restoration after hardware failure, personnel change, site loss, or platform migration.
Evidence should include successful restore tests from representative historical versions, not merely confirmation that a key backup exists. Tests need ciphertext, metadata, algorithm implementation, key version, access approvals, and dependencies. Retired software can remain a cryptographic dependency when old archives must still be read.
What organizations should do next
First, classify stored-data use cases by sharing model, confidentiality lifetime, retention, and recovery need. Determine where asymmetric encryption is actually required.
Second, map persistent keys to every protected dataset and consumer. Capture blast radius, custody, derivation, wrapping, rotation, escrow, and deletion policy.
Third, test access removal, rotation, restoration, corrupted metadata, wrong-key rejection, and disaster recovery. Record versions and evidence.
Finally, treat the OpenPGP proposal as work in progress. Follow revisions and interoperability results while applying its inventory lesson now: data-at-rest posture is a relationship among information, infrastructure, people, and keys.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect algorithms and protocols to applications, devices, hosts, locations, keys, owners, dependencies, evidence, exceptions, and migration work.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The draft may change or be replaced, and support across OpenPGP implementations is not assured. Symmetric cryptography is not automatically right for distributed recipients, cross-domain exchange, or nonrepudiation. The decision must follow the actual trust and recovery model.
Source
- Persistent Symmetric Keys in OpenPGP, revision 04, IETF OpenPGP Working Group, September 22, 2026.