Proposal: update SecureDrop's use of OpenPGP to support/require post-quantum cryptography

[zenmonkeykstop]

Proposal: update SecureDrop's use of OpenPGP to support/require post-quantum cryptography

Affected components

• SecureDrop Server
• SecureDrop Workstation
• SecureDrop Client

People and roles

Problem Statement

SecureDrop currently relies on an airgap (physical or (for Qubes) virtual) to protect the submission private key. By preventing the private key from ever being shared across a network, this offered protection against earlier iterations of store-now-decrypt-later threats that relied on later acquiring private keys of interest. If at some point in the future it becomes possible to break public-key cryptography using quantum computers, the benefit of the airgap will be partially or entirely lost, as adversaries may be able to decrypt submission files they've acquired.

Post-quantum cryptography (PQC) is available now and is being aggressively adopted by secure applications, to hedge against the uncertainty around quantum computing and soften the blow if it does ever become viable. Currently no open-source whistleblowing system (that I'm aware of) supports PQC to protect submission files (though data in transit may be protected depending on operators' choice of ciphersuites for TLS).

An IETF RFC to add post-quantum support to the openpgpg spec is nearing approval and has already been implemented by the folks at Sequioa: https://sequoia-pgp.org/blog/2025/11/15/202511-post-quantum-cryptography/ . SecureDrop already uses Sequoia - adding optional or even mandatory support for PQC would provide a level of future-proofing for any submissions and sources who use the platform once said support was available. (Historical submissions would not be protected unless they were reencrypted.)

Solution impact

Adding PQC support would protect sources against future adversaries capable of performing store-now-decrypt-later attacks, with the benefit increasing the longer the support is available. Sources could face threats of retribution long after they blow the whistle - securing their communications against future threats is important as a result.

Requirements and constraints

Exploration

Initial proposal

Supporting PQC would be non-trivial and mean using Sequoia across all SecureDrop subprojects: an implementation could look like:

• Update SecureDrop Server to use a pqc-ready version of Sequioa
• Update SecureDrop Workstation to provision a version of sd-gpg that uses sq (likely via chameleon?) instead of gnupg
• Update the SecureDrop Electron app to use Sequioa (built against WASM) instead of openpgp.js (unless the latter added PQC support) for reply handling (or to shell out to a hypothetical sd-sequioa instead)
• the Tails-based SVS would likely need to be updated to add support for a pqc-ready Sequioa, complicating setup a bit.
• Make associated docs changes, and work with orgs who want to update existing submission

Selected proposal

[legoktm]

More specifically on implementation I think there is also a requirement that server admins would need to generate a secret key that supports PQC, store the public part on the server and install the secret part on SDWs.

Historical submissions would not be protected unless they were reencrypted

I would suggest that if do go through with this, we would have a script that once a PQC-enabled public key is configured, it double encrypts all existing submissions (not replies), and teach SDW how to handle those. I'm not sure I'd worry about making it work on Tails, we could make this a SDW-only feature.

instead of openpgp.js (unless the latter added PQC support)

They have an outdated branch: https://github.com/openpgpjs/openpgpjs/commits/pqc/ - but we can ask about their plans once the RFC is accepted.