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.
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.
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.
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.
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.