You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@vinckr ed448 would probably just raise the bar a little on how fast a future quantum computer could break the DLP.
But ed448 itself is not a PQC algorithm.
You can check the references above which algorithms are PQC (mainly ML-DSA or a hybrid variant with two signatures ed25519 + ML-DSA).
But tbh I just wanted to raise awareness on the topic and the updated timelines in context of the new findings.
Of course it would make sense to wait until the final RFCs are there.
But nontheless the first drafts could be implemented to start testing and/or see how the longer key and signature sizes impact real world performance etc.
Adding some concrete context on PQC timelines and what Hydra could do:
France's ANSSI will stop certifying non-PQC products from 2027. The US Executive Order 14409 mandates PQC for all federal systems, with key establishment by 2030 and digital signatures by 2031. Australia's ASD has published post-quantum vendor guidance urging supply chain PQC assessments.
For Hydra specifically:
TLS key exchange: Go 1.24+ already enables X25519MLKEM768 by default in crypto/tls when CurvePreferences is nil. If Hydra does not explicitly set CurvePreferences, PQC key exchange is already active. Worth verifying and documenting.
JWT/OIDC signing: This is the bigger gap. Hydra issues JWTs signed with RS256/ES256, both quantum-vulnerable. RFC 9964 defines ML-DSA algorithm identifiers for JOSE. Go 1.27 will ship crypto/mldsa in stdlib. Tracking this for future ML-DSA JWT signing support would be valuable.
Crypto inventory: Identifying all quantum-vulnerable signing and encryption paths in Hydra would help plan the migration.
Happy to contribute documentation or a crypto audit PR.
Activity
vinckr commentedon Apr 15, 2026
Does the standard Go package support ed448 now or equivalent post-quantum algorithms?
I think that is why the previous issue was closed, because there was no support for post-quantum in the go standard library or golang.org/x
ston1th commentedon Apr 16, 2026
@vinckr ed448 would probably just raise the bar a little on how fast a future quantum computer could break the DLP.
But ed448 itself is not a PQC algorithm.
You can check the references above which algorithms are PQC (mainly
ML-DSAor a hybrid variant with two signaturesed25519 + ML-DSA).vinckr commentedon Apr 16, 2026
Are you aware of any PQC algorithms that we can use that are supported in the go standard library or golang.org/x ?
ston1th commentedon Apr 22, 2026
@vinckr
ML-KEM already landed in golang 1.24: https://go.dev/doc/go1.24#crypto-mlkem
ML-DSA should land in golang 1.27: golang/go#77626
But tbh I just wanted to raise awareness on the topic and the updated timelines in context of the new findings.
Of course it would make sense to wait until the final RFCs are there.
But nontheless the first drafts could be implemented to start testing and/or see how the longer key and signature sizes impact real world performance etc.
This could be one of the relevant drafts for signatures:
https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/
More PQC RFCs and their status can be found here:
https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc
netanmangal commentedon Aug 11, 2026
Adding some concrete context on PQC timelines and what Hydra could do:
France's ANSSI will stop certifying non-PQC products from 2027. The US Executive Order 14409 mandates PQC for all federal systems, with key establishment by 2030 and digital signatures by 2031. Australia's ASD has published post-quantum vendor guidance urging supply chain PQC assessments.
For Hydra specifically:
TLS key exchange: Go 1.24+ already enables X25519MLKEM768 by default in crypto/tls when CurvePreferences is nil. If Hydra does not explicitly set CurvePreferences, PQC key exchange is already active. Worth verifying and documenting.
JWT/OIDC signing: This is the bigger gap. Hydra issues JWTs signed with RS256/ES256, both quantum-vulnerable. RFC 9964 defines ML-DSA algorithm identifiers for JOSE. Go 1.27 will ship crypto/mldsa in stdlib. Tracking this for future ML-DSA JWT signing support would be valuable.
Crypto inventory: Identifying all quantum-vulnerable signing and encryption paths in Hydra would help plan the migration.
Happy to contribute documentation or a crypto audit PR.
vinckr commentedon Aug 11, 2026
We can maybe look at it more seriously next year, but this year is already pretty packed in terms of scheduled work.
netanmangal commentedon Aug 20, 2026
@vinckr I can work on PQC and contribute. Let me know I can open a PR, or you'd like to take this one internally.
vinckr commentedon Aug 27, 2026
@netanmangal no need to send a PR, as I said this is not a priority right now, at least for this year.