Sure. I’ll start with some basics to get us all up to speed.
As you know, post-quantum cryptography is cryptography designed to be resistant to quantum computers. While there aren’t yet quantum computers capable of breaking the algorithms in use today, as we’ve seen above it is close enough that this is a real threat - communications harvested today might be decrypted in the relatively near future.
NIST recently standardized three PQC cryptographic algorithms (August 2024):
- ML-KEM (CRYSTALS-Kyber), an encryption method
- ML-DSA (CRYSTALS-Dilithium), a signing method
- SLH-DSA (Sphincs+), a second signing method
Two signing methods were standardized in case one proves vulnerable. You can sign data with both, so both algorithms would have to be compromised to forge a complete signature.
As these algorithms were very recently standardized, it will take some time before they are widely supported. This is not something you can enable in GnuPG today on your existing setup.
GnuPG 2.5.0 (a development release, not intended for production use), supports ML-KEM encryption. It does not yet support either signing method. The OpenPGP standard for using ML-KEM in PGP messages is not yet standardized, so it is possible that messages encrypted today will not interchange with production releases. (It does appear the drafts probably will not change much to the final, but there’s no guarantee.)
So what are some things you can do today?
- If your threat model justifies it, research very recent releases or development versions of software you use for encryption. Remember that development versions may have caveats, these might be acceptable for your use case. (E.g. a power-side-channel attack today might be OK to have PQC encrypted data.)
- If you are a developer, contribute to FLOSS to support these projects.
- Support companies doing either of the above
