No. age developer Filippo Valsorda has experimented with Kyber/ML-KEM and maintains a Go library for it, https://github.com/FiloSottile/mlkem768. The public key size is intimidating.

https://x.com/FiloSottile/status/1544803635237998592 (2022-07-06):

> A Kʏʙᴇʀ768+X25519 recipient would clock in at about 1660 characters.

> Classic X25519 age recipient for scale.

> https://paste.dbohdan.com/1mhc0nc-w7ks3/recipient.png [Alt text: A terminal window. The classic recipient on the first line takes about 2/3 of a line. The PQC one takes 16 lines.]

Oh, that's a shame.

I'd like to use something stable and supported for long term backups, so size doesn't matter. Pre-quantum is not something worth migrating to.

Is quantum computing a major issue for symmetric keys? I thought it was primarily an issue with public-keys?

The File Key is symmetric, but the header having recipient implies this is public key crypto.

So break the public key crypto (e.g. X25519), and you don't need to crack the symmetric key.

Also 128 bit? That's not quantum safe either, thanks to Grover's algorithm.

It uses key files that are 128 bits. With symmetric encryption, it’s equivalent to AES-128, so not really post quantum.

It has post quantum plugins, but those are third party plugins!

Yeah 128bit for symmetric is not enough, but it uses public key cryptography, right?

"RECIPIENT can be an age public key generated by age-keygen ("age1...") or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...")."

It has both public key and symmetric mode.

Even with public key, the file is encrypted in symmetric mode with a random key. The key is encrypted with pubkey.

The file format is built around asymmetric cryptography, so maybe going to 256 bits required some work that the authors does not want. Not sure.

Would have made sense to have standard ChaCha 20.

> The key is encrypted with pubkey.

Of course. That's how all public key crypto works. It's entirely infeasible to encrypt large payloads with a public keypair directly.

But this means that the symmetric key is entirely vulnerable to quantum computers. All you have to do is decrypt it.

> so maybe going to 256 bits

No, that's symmetric crypto key lengths, which are not the vulnerability when public keys involved are not PQ.

Which is what I said.

Well, I'd say you left out all the important bits, to the point where your comment could easily be read as "it's the symmetric key that matters, even with public key".

But whatever. Now I know. Both the choice of symmetric key length AND the choice of public key algorithms independent of each other make this format not PQ.

Why anyone in their right mind would migrate to such algorithms in 2025 I have no idea, and especially coming from someone like Filippo it's baffling.

Those already on PQ are better off staying. Those who are not should move to a PQ, not this.

128 bits of symmetric keys are enough for post-quantum security. See https://words.filippo.io/post-quantum-age/.

The public key algorithm has been frustratingly blocked on the IETF and CFRG, which are taking more than 15 months since FIPS 203 to stabilize a simple hash-based hybrid combiner.

Glad to hear about 128bit.

I still stand by that one should not migrate to vanilla `age` until the public key part is PQ, or one will need to do two migrations. The incremental improvement from going GPG to age seems pointless given the timelines.

If PQ compliance is urgent, then sure, migrate to age+PQ plugins. Yes I share the frustration about how long it's taking, so in the mean time for PQ requirements I can't get into, I did for some installations need to migrate to a temporary pre-standard (but still holding up) PQ layer.

And I'm itching to migrate to something standard (or at least de facto standard) when it comes.

Frustrating, but understandable, that many people are making excuses that they are focusing on key exchange, not communication over time.