logoalt Hacker News

BoppreHtoday at 10:54 AM1 replyview on HN

Disclaimer: what follows is my opinion.

There's a good consensus that for key exchange/encryption (TLS, SSH, age, etc) the way forward is ML-KEM 768 together with some classical algorithm, like X25519. The public keys are larger (1 KB), but that's usually ok unless you're working on very small microcontrollers. And you should migrate quickly because of harvest-now-decrypt-later attacks.

For signatures, things are harder because there are tradeoffs. Some algorithms have large signatures (10+ KB), others require keeping state and have catastrophic consequences if subkeys are reused. And the systems around it are also more complicated: in a certificate, should you put a classical and a PQC signature together? Or should the PQC signature go in an extension? Should the extension be marked as critical and fail loudly on old clients, or should new clients have a special case to always check it if PQC signature validation is available? Or should we abandon the certificate chains and move to Merkle Tree Certificates[1]?

So signatures/authentication are still up for debate. Unless your team is on the bleeding edge of either crypto research or security risks, then there's not much to do than wait for better consensus to form.

[1] https://postquantum.com/security-pqc/googles-merkle-tree-mtc...


Replies

i_think_sotoday at 11:08 AM

Your opinion is most welcome. Cheers!

> And you should migrate quickly because of harvest-now-decrypt-later attacks.

...

> So signatures/authentication are still up for debate. Unless your team is on the bleeding edge of either crypto research or security risks, then there's not much to do than wait for better consensus to form.

I'm trying, as a layman, to find some not-too-insane middle ground between those contradictions.

show 1 reply