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.
> 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.
That's because of the difference between Confidentiality goals and Authenticity goals.
If I send you a document encrypted with classical crypto today, an attacker could grab a copy, wait a few years, then decrypt with a quantum computer (Harvest-Now-Decrypt-Later). The contents of the document I sent today are exposed in the future.
For documents/transmissions that must remain confidential for 10 years, assuming a quantum computer available in 2030, you should have been encrypting them with PQC since 2020! And if deploying PQC for your clients and servers takes two years, you should have started migrating in 2018!
But if I send you a signed document, it's safe because you're verifying the signature today and there are no quantum computers available today to forge a new signature. The same goes for SSH authentication and web certificates, for example. They're safe right until the moment quantum computers arrive (and by then you better have a good solution!).
That's why so many open-source projects already support ML-KEM for key exchange/encryption, but signatures are still under discussion. The former is more urgent.
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...
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.
That's because of the difference between Confidentiality goals and Authenticity goals.
If I send you a document encrypted with classical crypto today, an attacker could grab a copy, wait a few years, then decrypt with a quantum computer (Harvest-Now-Decrypt-Later). The contents of the document I sent today are exposed in the future.
For documents/transmissions that must remain confidential for 10 years, assuming a quantum computer available in 2030, you should have been encrypting them with PQC since 2020! And if deploying PQC for your clients and servers takes two years, you should have started migrating in 2018!
But if I send you a signed document, it's safe because you're verifying the signature today and there are no quantum computers available today to forge a new signature. The same goes for SSH authentication and web certificates, for example. They're safe right until the moment quantum computers arrive (and by then you better have a good solution!).
That's why so many open-source projects already support ML-KEM for key exchange/encryption, but signatures are still under discussion. The former is more urgent.