Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/crypto: add implementation of Diffie-Hellman x448 #29390

Closed
armfazh opened this issue Dec 22, 2018 · 11 comments
Closed

proposal: x/crypto: add implementation of Diffie-Hellman x448 #29390

armfazh opened this issue Dec 22, 2018 · 11 comments

Comments

@armfazh
Copy link

@armfazh armfazh commented Dec 22, 2018

Feature request: implementation of X25519 and X448.
The X25519 function is provided by x/crypto/curve25519 package, but not for X448.

@gopherbot gopherbot added this to the Unreleased milestone Dec 22, 2018
@armfazh armfazh changed the title x/crypto diffie-hellman x448 x/crypto Diffie-Hellman x448 Dec 22, 2018
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 22, 2018

Change https://golang.org/cl/155717 mentions this issue: x/crypto: Adds Fp25519/448 and X25519/X448 for amd64 arch

@ALTree ALTree changed the title x/crypto Diffie-Hellman x448 x/crypto: add implementation of Diffie-Hellman x448 Dec 22, 2018
@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Jan 29, 2019

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.

@KBassford
Copy link

@KBassford KBassford commented Dec 11, 2019

Due to RFC 7748 (https://tools.ietf.org/html/rfc7748) being adopted by the US government, should be more than enough justification. Dependent Modules (such as ECDH, which is what brought me here) will also require updating. As noted above, the cloudflare module has already been updated.

Thanks

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Mar 24, 2020

The bar for inclusion in the Go standard library (or x/crypto) is not whether a standard is adopted by a certain body, but whether it's widely useful to Go applications. Ed448 deployment is very limited, and there is no strong security argument for using it in place of Ed25519. It's also a very complex implementation, in particular with the necessary optimizations, so it would bring a lot of maintenance cost.

See also https://golang.org/design/cryptography-principles.

@KBassford
Copy link

@KBassford KBassford commented Mar 24, 2020

How would you know if there is any "usefulness" before there is an implementation? That's like saying you don't like chicken without having ever tasted one. I'm genuinely confused.

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Mar 24, 2020

By that argument we would have to implement everything to see if it turns out to be useful, which is not workable. Instead, we look at what was adopted when implemented by other libraries, at the adoption of third-party Go modules, at the usage of the primitives in widespread protocols, and we make a judgement call following the guidelines I linked above, erring on the side of rejecting additions and saving complexity and maintenance budget.

@rsc rsc added this to Active in Proposals Mar 25, 2020
@rsc rsc changed the title x/crypto: add implementation of Diffie-Hellman x448 proposal: x/crypto: add implementation of Diffie-Hellman x448 Apr 1, 2020
@gopherbot gopherbot added the Proposal label Apr 1, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Apr 1, 2020

@agl, in a comment above @KBassford cites RFC 7748 as justification for adding x448 to x/crypto. Since you wrote that RFC, what do you think? Is it broadly useful enough to merit adding here? Thanks.

@rsc
Copy link
Contributor

@rsc rsc commented Apr 15, 2020

Ping @agl

@agl
Copy link
Contributor

@agl agl commented Apr 15, 2020

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. (And the costs of adding more primitives are generally larger than people suppose: they dilute optimisation and verification efforts and ecosystem effects pressure everyone to support every primitive.)

@rsc
Copy link
Contributor

@rsc rsc commented Apr 22, 2020

Based on the discussion above, then, it seems like this is a likely decline.

@rsc rsc moved this from Active to Likely Decline in Proposals Apr 22, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Apr 29, 2020

No change in consensus. Declined.

@rsc rsc closed this Apr 29, 2020
@rsc rsc moved this from Likely Decline to Declined in Proposals Apr 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.