search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.3k stars 17.58k forks source link

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

Closed armfazh closed 4 years ago

armfazh commented 5 years ago

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

gopherbot commented 5 years ago

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

FiloSottile commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

Ping @agl

agl commented 4 years ago

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 commented 4 years ago

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

rsc commented 4 years ago

No change in consensus. Declined.