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 _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
