hydra
hydra copied to clipboard
ory
ed448 support for jwk keys?
Asking about this since the NSA recently published guidance advising the public and private sectors to transition to cryptographic algorithms that are no less than sha384 & ec384 (elliptic curves).
While Edwards' Curves are different, its worth noting that prior to this update sha256 & secp256k1 were both on the list of acceptable cryptographic algorithms. My deduction was that 128-bit security is no longer considered acceptable (to the NSA) for securing information in both the public & private sectors
Link here - https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF (picture below showing the new proposed cryptographic algorithms)
Worth noting that these algorithms are the former 'suite B' list (which was obsoleted by the NSA this year; announced in conjunction with the IETF - https://datatracker.ietf.org/doc/html/rfc8423) - so now these algorithms are for the general public.
Additionally, these are just the interim algorithms that are being recommended until an "official" reference algorithm is selected among the NIST PQ-competition round 3 finalists - https://csrc.nist.gov/news/2020/pqc-third-round-candidate-announcement
Curious to get you all's thoughts on this. Thank you!
Definitely! If anyone is up to contribute this, I think it’s a good issue to get started!
I wanted to try it, but the standard Go package doesn't seem to support ed448. Is it possible to use third-party packages?
For example: https://github.com/otrv4/ed448
Oh I see, in that case I don't think it makes sense to work on this. We will only accept PRs using the go standard library or golang.org/x for cryptography-related things due to the high risk of vulnerabilities in third party code related to cryptographic functions.
Support for ed448 has been considered and declined for inclusion in the standard Go Cryptography library:
We went without X448 for a long time now, so it's not clear we need it in x/crypto, and it's a lot of manually written assembly to review and maintain. Before accepting this I would want to hear who needs it and why.
I suspect that X448 is not worth the maintenance costs. Its utility comes from mitigating the risk of some breakthrough that renders X25519 breakable, but not X448. While that is possible, it seems extremely unlikely, and would probably scare everyone away from X448 too like a crumbing cliff. With quantum attacks coming to destroy both of them and enable retrospective decryption anyway, investing more in elliptic curve primitives doesn't seem like the best application of engineering resources.
Based on the discussion above, then, it seems like this is a likely decline. No change in consensus. Declined.
For completeness, there is a Cloudflare ed448 implementation here.
@aeneasr, I suggest you close this issue, per your comment of 9 Nov 21 (or, at minimum, remove the good_first_issue label, which is what drew my attention).
