Post-Quantum Keys choice for signing/encryption #40496
Replies: 3 comments 8 replies
-
|
I'm not part of the Keycloak team, but I wanted to mention that I’m currently working on an implementation of ML-DSA (CRYSTALS-Dilithium) and plan to contribute it to Keycloak once it reaches a stable stage. |
Beta Was this translation helpful? Give feedback.
-
|
There's no real challenge in implementing a PQC signature mechanism in Keycloak; that's pretty easy we just need a key provider and a signature provider. One challenge is representing the keys in the JWK endpoint, as the standards are not ready for how to do that. That means the keys have to be shared in a non-standard way, for example using PEM files. Another tricky part is that you don't want to use any of the PQC signature algorithms on their own at this point, as it is still unclear how secure they are and interoperability is most likely going to be a pain (not all libs will supported them, and the whole JWK issue). That basically means the recommendation right now is to use hybrid signatures, but that's not something JWS supports (and also would increase both the size and cost of signing). There's also the fact that tokens are short-lived; hence it is less of a priority to find a solution since there are still years until quantum computers are available. That doesn't mean do nothing, and we are paying attention to what is happening in the specs and elsewhere. Since you mention encryption in the title; symmetric encryption is relatively unaffected by and recommendation is to continue using AES for example. The problem with symmetric encryption is the key exchange part, for example in TLS. What is a higher priority is TLS due to store now decrypt later attacks; for example someone could store login request to Keycloak now, then decrypt user passwords years from now. In terms of algorithms, all are readily available to Keycloak today, here's some more details: ML-DSA is fast enough, but signatures are big (6172 bytes url encoded), it's also considered well understood from a security perspective. So the problem here is signature sizes. SLH-DSA is extremely slow and signatures are enormous. This is considered more a backup option if all other signatures are considered insecure. Falcon is fast and signatures are not that big (872 bytes url encoded). Problem with this one is that the security properties of it is less well understood. |
Beta Was this translation helpful? Give feedback.
-
|
This feature is definitively welcomed. We want to have Quantum Algorithms Options for Key Signing in our current deployment. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello Keycloak team!
I'm suggesting the ability for Keycloak admins to use post-quantum cryptography (pqc) algorithms for signing and encrypting tokens in Keycloak. Since quantum computers are starting to be made, a lot of organizations (including ours) are starting to worry about how secure our authentication and federation systems will be in the future.
Right now, Keycloak only lets us use RSA and elliptic curve algorithms for SAML and OIDC tokens, but these won’t be safe once quantum computers are in mass production. It would be amazing if Keycloak could offer some quantum-safe choices so we can start planning our migration and stay ahead of the new technology standards.
The main PQC algorithms I’d love to see supported and would recommend are:
CRYSTALS-Dilithium (ML-DSA): One of the best NIST standard for digital signatures—strong, efficient, and it's already getting a lot of industry attention.
FALCON: Another NIST favorite, with even smaller signatures (though I was informed it’s trickier to implement).
SPHINCS+: A hash-based signature that’s super strong, but the signatures are bigger.
Kyber: The leading post-quantum algorithm for encryption and key exchange.
It would be great if these could be selectable in the Keycloak admin UI, just like we choose RSA or ECDSA now. Ideally, it would also be possible to run in “hybrid” mode (e.g., RSA + Dilithium) while the ecosystem catches up.
Adding these would help a lot of us future-proof our and many others' identity infrastructure and stay safe with new security standards as they start rolling out.
Thanks a bunch for considering this! If you need testers or feedback, I’d be happy to help.
Beta Was this translation helpful? Give feedback.
All reactions