This post-quantum crypto thing is ridiculous.

If they start getting severe budget cuts, I'm sure they'd be happy with just capturing the key exchange and then one out of every N packets from that session, or using timing analysis to discard the majority of unnecessary traffic (heavy web resources, video streaming, etc). That would be enough to drastically limit storage space while still preserving a significant amount of information.

> Hmm. I’ll have to port this to my 486 and SPARCstations and see.

The majority of the computational cost for ML-KEM is in the use of Keccak in the form of SHAKE as a hash function and XOF. The overhead from actual lattice cryptography is almost negligible. I highly doubt Keccak is going to be efficient on a 486 or anything of that era. The lack of SIMD means that it will struggle. Any modern computer with SIMD will not see a prohibitive increase in computational cost when switching to something like mlkem768x25519.

Keccak is optimized to be exceptionally efficient in a raw hardware implementation such as a future SHA-3 instruction set, but most users of ML-KEM are not going to be using ancient hardware. There's also a Kyber-90s variant which uses SHA-2 and AES instead of SHAKE, which offloads the majority of computations to dedicated instructions from SHA-NI and AES-NI, neither of which are supported by the 486 or SPARCstation.

Those old computers used to run 4096 bit Diffie-Hellman just fine. Hybrid ML-KEM768/X25519 is several times faster.