Repository navigation
Post-Quantum Keys choice for signing/encryption #40496
Replies: 6 comments 14 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. |
|
@ahus1 fyi, trying to reach you via email before |
|
Let's see if this is possibly by adding some providers as an extension. I've sent an invite for a 1:1 to provide some more orientation. |
|
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. |
|
https://datatracker.ietf.org/doc/search?name=jose&sort=&rfcs=on&activedrafts=on&by=group&group= https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/ Things are happening for sure, so probably time to start looking more at this. |
|
@stianst created a feature #43690 to start the development. Some note from me about:
As long as a client uses the token introspection endpoint, it doesn't need to handle the keys. So a first MVP might work without keys available to the client. |
Well the JWK representation is specified: https://www.ietf.org/archive/id/draft-ietf-cose-dilithium-10.html#section-3 No, it is not yet published as a final standard, but neither is the ML-DSA signature in JOSE itself. So either both should be added as an experimental feature or none. That said, it was my understanding that adding JWK public key representations was difficult due to missing SPIs..? If I am mistaken, both should be added, as the PQ signature is obviously rather uninteresting for opaque tokens. |
|
We'll need both; token introspection only route you may as well just to HMAC. Yer, so the JWKs encoding/decoding we have isn't very pluggable, so we'd need some solution for that; or at least be able to wrap the PQC stuff in an experimental flag or something. It can still be split up into multiple tasks though; keys + signing first; jwks stuff as a second. |
|
Thanks for the detailed explanation! |
|
This feature is definitively welcomed. We want to have Quantum Algorithms Options for Key Signing in our current deployment. |
|
France's ANSSI will stop certifying security products without post-quantum cryptography starting in 2027 — the first hard regulatory deadline of its kind globally. Additional mandates: US NSA CNSA 2.0 (2027), NIST IR 8547 (deprecation by 2030, disallowed by 2035), EU critical infrastructure (2030). Adding our use case: we're building quantum-safe infrastructure and need Keycloak to support ML-DSA for JWT signing. Specifically, we need:
We note the tracking epic #43690 (60 subtasks, milestone 27.0.0) and the research spike #45168 (milestone 26.7.0, due July 8). |
|
I'm happy to take it up. If maintainers can create an issue and assign it to me, I'd raise the PR. |
|
Hi everyone! Glad we're making progress on this, thanks so much! |
|
Or should I create an issue and link to this discussion. Then raise the PR against the issue? |
|
Perfect, thanks for creating the issue. I'd raise the PR. |
|
Hi! Just to double check, how do I do that, sorry I'm not very good with linking stuff in GitHub. |
|
I think I found an issue that already exists for this? #43690 It looks very similar to me in what this discussion mentions |
Uh oh!
There was an error while loading. Please reload this page.
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. It's 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.
All reactions