Support for RFC 9980 - Post-Quantum Cryptography in OpenPGP #714

Is your feature request related to a problem or specific use case? Please describe.

Yes. We use Bouncy Castle C# for OpenPGP functionality in .NET applications, and there is currently no way to create and process OpenPGP messages using the post-quantum algorithms standardized by RFC 9980.

This is becoming increasingly important for applications that encrypt files which may need to remain confidential for many years.

Traditional OpenPGP public-key encryption relies on algorithms that would be vulnerable to a sufficiently capable cryptographically relevant quantum computer. This creates a "harvest now, decrypt later" concern: an attacker can retain encrypted data today and potentially decrypt it in the future once the required quantum capabilities become available.

For managed file transfer and other systems processing business-critical data, files may contain information whose confidentiality lifetime is significantly longer than the expected lifetime of the cryptographic algorithms protecting them.

RFC 9980 addresses this specifically by extending OpenPGP with post-quantum and hybrid cryptographic algorithms, providing a standardized migration path for long-term secure OpenPGP encryption and signatures.

Describe the solution you'd like

Add OpenPGP support for RFC 9980, including the ability to:

• Generate and import OpenPGP keys using the algorithms defined by RFC 9980.
• Encrypt and decrypt OpenPGP messages using the RFC 9980 composite ML-KEM/ECC schemes.
• Create and verify signatures using the RFC 9980 composite ML-DSA/ECC schemes and standalone SLH-DSA.
• Parse and serialize the corresponding OpenPGP packets, keys, signatures and algorithm identifiers.
• Interoperate with other RFC 9980-compliant OpenPGP implementations and the published test vectors.

RFC 9980 extends RFC 9580, so I understand that this may first require completing the necessary RFC 9580 support in the C# OpenPGP implementation.

There is already an open PR (#525, "New OpenPGP Specification") that implements substantial parts of what later became RFC 9580, but it has remained open since 2024. Completing or incorporating that work could potentially provide the foundation required for RFC 9980 support.

It is also worth noting that Bouncy Castle C# already contains implementations of the underlying post-quantum algorithms such as ML-KEM, ML-DSA and SLH-DSA. The main missing piece appears to be their integration into the OpenPGP protocol according to RFC 9980.

Describe alternatives you've considered

Several alternatives are possible, but all have significant drawbacks:

• Maintaining a custom implementation or fork of the Bouncy Castle OpenPGP code to implement RFC 9580/RFC 9980. Implementing cryptographic protocols independently adds considerable security, maintenance and interoperability risk.
• Calling an external OpenPGP implementation that supports PQC. This adds an external process/runtime dependency and makes deployment and cross-platform support substantially more complicated.
• Applying post-quantum encryption outside OpenPGP before transferring files. While this can provide additional protection, it breaks standard OpenPGP interoperability and requires a proprietary additional encryption layer.
• Continuing to use traditional OpenPGP encryption until PQC support becomes available. This does not address the harvest-now/decrypt-later problem for information that must remain confidential for a long period.

Native RFC 9980 support in Bouncy Castle would therefore provide the cleanest migration path for .NET applications already using its OpenPGP APIs.

Product deployment

• Deployment format: Software / .NET application using BouncyCastle.Cryptography through NuGet
• Version: 2.7.0

Additional context

RFC 9980, "Post-Quantum Cryptography in OpenPGP", was published in July 2026 as an IETF Standards Track RFC. It explicitly extends RFC 9580 and defines:

• composite public-key encryption based on ML-KEM combined with elliptic-curve cryptography;
• composite signatures based on ML-DSA combined with elliptic-curve cryptography; and
• SLH-DSA as a standalone post-quantum signature algorithm.

The RFC's motivation specifically includes providing long-term secure OpenPGP ciphertexts and signatures in preparation for cryptographically relevant quantum computers.

Given Bouncy Castle's existing OpenPGP support and existing implementations of the underlying NIST post-quantum algorithms, adding RFC 9980 support would give .NET applications a standards-based path for introducing post-quantum protection without having to replace Bouncy Castle or implement a separate cryptographic stack.