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

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.

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

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.

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.

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.

@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.

Ping @agl

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.)

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

No change in consensus. Declined.