X448 support

[Darkspirit]

from https://github.com/briansmith/ring/issues/462 for https://github.com/ctz/rustls/issues/52

Please file a separate issue for X448 and/or a separate issue for Ed448 if you want those to be added.

X448 is a perfect replacement for secp521r1 to gain "level 8" security here: https://www.keylength.com/en/3/

btls has both, but no TLS 1.3. Maybe this would be something for ring, @briansmith. (You convinced me that P-521 has no future.)

[briansmith]

As far as a simple but not optimal implementation goes, it should be easy to do this technically. X448 is optimized for Montgomery multiplication, IIUC, and the P-256 and P-384 code already contains all the primitives needed for Montgomery multiplication. In particular, one could build an X448 implementation pretty easily in ring simply by copy/pasting the P-384 code that implements ECDH. The only new part would be the new Montgomery ladder.

In order to do such a simple implementation, I'd recommend doing a quick first prototype to make sure that my assumption that we can reuse the P-384 ECDH code, with a new ladder, is correct. Then we can refactor the code to move the logic shared between X448 and P-384 (and P-256) out of the "suiteb" submodule into a higher-level module.

However, because X448 uses more limbs per element than P-384 does, if we use the same Elem struct that's defined inside ring::ec, we'd have to increase the size of the Elem struct. And that means that we'd be increasing the stack space required for all curves. This is a significant cost. I wonder if anybody is actually using X448 such that this cost is justified?

[Darkspirit]

I saw your work to figure out on what the NIST curves are based on and it's still unclear for me if they are as secure as they should be (I am not a cryptographer). DJB has a nice table of which curves he think they are state of the art and secure: https://safecurves.cr.yp.to/ The switch from P-256 away to X25519 isn't just about speed, but primary about confidence? So as X448 is in my view 16% bigger than P-384 I would expect that it would need some more memory? This is far less than the difference between P-256 and P-384.

"The ~224-bit security level of curve448 is a trade-off between performance and paranoia." (https://tools.ietf.org/html/rfc7748#section-6.2) So X25519 has the same security level as AES128 and X448 as AES256. (https://www.keylength.com/en/3/).

As X25519 and X448 are the trustworthy replacements for the NIST curves on different security levels it is to expect that ones who have to fulfil strong data protection laws and/or contracts will prefer it over P-384/P-521.

[briansmith]

I saw your work to figure out on what the NIST curves are based on and it's still unclear for me if they are as secure as they should be

That little experiment was (still is) hoping to show that they are rigidly-defined. Unfortunately, if they are, it isn't obvious to me how so. In any case, I don't think think the stuff I posted on Twitter is evidence for or against the safety of those curves.

[Darkspirit]

Status update: X448 is being integrated into OpenSSL: https://github.com/openssl/openssl/pull/5470 (Contributed by https://github.com/openssl/openssl/issues/1398#issuecomment-298769294)