FWIW this is on hold until I know for sure what high-security-margin curve to use. I'd like this to be a "one-ciphersuite-fits-all" protocol, which puts a lot of pressure on getting that choice right.
In addition to DJB's Curve41417 (not yet implemented), Mike Hamburg's Goldilocks-448 curve looks pretty good, so I'm waiting for that to shake out.
Those two being the choices, I'd go for 41417: arithmetic modulo 2^414-17 is (to me, at least) simpler, and smaller Edwards coefficient. Performance should be in the same ballpark, if not faster.
I wonder if a higher security margin curve is really required here, though. (Block) ciphers usually have to worry about multi-target attacks; 128-bit security starts to feel small in that scenario. But curves don't have that problem: you need to actually do 2^128 computation even in the multi-target case, so it seems less necessary to insist on >256-bit curves. What's the rationale behind the higher security margin curves?
Performance should be in the same ballpark, but I'd rather go with whichever achieves its security level most efficiently. Goldilocks looks good by that metric [1], so I'm curious how a Curve41417 implementation compares.
The rationale for an "extra-strength" curve is the hope it might resist future cryptanalytic breakthroughs. The extra bits aren't needed for brute force, but if some cryptanalysis comes along in 20 years and lops a bunch of "security bits" off, you might be glad you had extra ones...
That's a hard thing to quantify, but if we can get, say, 96 extra security bits for only a ~3.5x slowdown over Curve25519, it seems worthwhile.
I know you are waiting for the curve thing to get settled but it's too bad there's not a C implementation in the repo right now. Today I'm working on a project that could clearly benefit from Noise but since it doesn't exist I have to use CurveCP and try to work around the problems you've identified myself.
I completely get where you're coming from on the "one ciphersuite to rule them all" problem but as an early adopter I would happily use curve25519 as a stopgap until you decide what the One True Curve should be. Instead I have to do my own CurveCP implementation now and then maybe rip it out later.
Probably a good curve too (nice Mersenne prime, so fast reduction). But I'm not sure it fits into processor words as efficiently as Goldilocks (I'm not an expert here, but someone was trying to explain this to me).
But yeah, those might be 3 good candidates for a higher-security curve (Curve41417, Goldilocks, E-521).
In addition to DJB's Curve41417 (not yet implemented), Mike Hamburg's Goldilocks-448 curve looks pretty good, so I'm waiting for that to shake out.
http://sourceforge.net/p/ed448goldilocks/wiki/Home/
The "curves" mailing list will (hopefully) be a good place to track that discussion:
https://moderncrypto.org https://moderncrypto.org/mail-archive/curves/2014/000139.htm...