[curves] How close is Mike's Ed448 to being production-ready?

[Nicholas Wilson]

Hi,

I'm trying to decide between curve41417 and Ed448-Goldilocks, for a
product prototype using a high-security curve. (I can't see the
product being released in the immediate-term, so there should be time
for these curves to get a bit more review and for implementations to
stabilise before we release, don't worry! Until this year, I was too
cautious to jump onto the curve25519 bandwagon because it felt "too
new".)

My preference is for Ed448-Goldilocks because of its strong curve
choice, and because the code looks good already. Really all I'm after
is a good curve, with a canonical and stable wire format for an ECDH
exchange. For me, speed isn't too big an issue, because in a blunt
sense customers who demand "maximum security", higher than curve25519,
are already wasting cycles. Just a nice portable file, MIT-licensed,
plain-C (like curve25519-donna), with a focus on correctness, would be
good enough, and it could be optimized in a later release.

It seems like most of the focus of the ECC community these days seems
to benchmarks and speed comparisons!

Mike's "experimental" Ed448 code is actually already close to meeting
my ease-of-compiling requirements, although I have made two minor
changes:
1. Pull out the ChaCha and /dev/random code as an optional thing.
People shipping crypto code already have their own random source, and
it saves having to making a whole load of ifdefs for fetching Windows
CryptoApi randomness, emscripten/WebCryto getRandomNumber...
2. Avoid the requirement on SHA-512. All protocols already hash in the
ECDH secret with nonces and protocol values, so we may as well make it
easy for protocol designers to use the function their protocol uses
(HKDF, in the protocol I'm working on)

(I also fixed a few typos I think Mike might want to merge in
https://github.com/NWilson/ed448-goldilocks/commit/143f0e0b33fa54816d5e153d7512059e8d91a233)

My version is at https://github.com/NWilson/ed448-goldilocks/tree/nicks-changes

I have to admit, they might things faster, but all the CPU-specific
stuff and __attributes__ scare me off! I have to get code running on 7
architectures, 4 vendors' compilers, and 8 OSes before our company can
ship it...

So really, the question is, how close is Mike's Ed448 to being
production-ready? I'd say the theory looks robust enough that a
serious problem in Ed448 would be very bad news for a lot of Edwards
curves...?

But I'm not an expert! I've studied
http://shiftleft.org/papers/fff/fff.pdf which is helpful which helps
understanding some of the bits of Mike's code that are bit different
to way some other Edwards curves are implemented.

One thing I like about Ed448 is that the Montgomery curve public
format is elegant, so meets my requirement for a stable, canonical
wire format for doing ECDH with. Is that right, or is that something
that might be up for change in a future implementation of Ed448? What
I mean is, suppose that towards the end of 2015 things look good for
Ed448 and we ship it as an experimental feature, is there is a risk
that if later on big popular crypto libraries add support for it,
they'll be using a different serialisation format? We don't want our
protocol to be stranded using an old format that needs conversions to
the "preferred" serialisation!

Thanks for any comments on my rather-long question.

Nick