LoupVaillant
commented
5 years ago as beautifully carved as you did
Thanks for the compliment, it's appreciated!
It would be nice indeed, but this is out of Monocypher's scope. Monocypher is opinionated, there's only one way to do things. That way users aren't left wondering what they should use. Adding Curve448 would simply be redundant.
I may implement Curve448 in the future anyway, but that would be a separate effort, in a separate library.
Moreover, we could legitimately question the need of a bigger curve altogether. Curve448 would presumably resist quantum attacks longer than smaller curves (because it simply requires more qbits to crack), but my (not very educated) guess is that if Curve25519 goes down, Curve448 won't stand much longer. If you want to resist quantum attacks, forget about Curve448, go post quantum instead.
Right now, our real adversary is brute force. Pollard Rho if I recall correctly. Basically, cracking a curve is as difficult as finding hash collisions for a hash of the same size. This means 128 bits of security for a curve or hash of size 256. It sounds scary because multi key, parallel attacks on AES128 quite clearly demonstrate that 128 bits of security is quite insufficient.
But here the thing: I said "128 bits of security" twice, and it turns out it doesn't mean the same thing in both cases. Trying to crack a 128-bit cipher (or doing a preimage attack on a 128-bit hash) is much easier than trying to find collisions on a 256-bit hash (or cracking a 256-bit curve). For two reasons:
-
Multi key attacks: when attacking a cipher, finding one key among N, is N times cheaper than finding any one key. So we must be worried about attackers trying to crack many keys at once. When trying to find hash collisions (or crack a curve) on the other hand, cracking many many keys is just as difficult as cracking any given key. Multi key attacks basically don't matter with curves.
-
Chance drop off: Instead of computing until we find a key, we can compute less, in the hope that maybe we'll get lucky. When we do this with symmetric cipher, the drop off is linear: cutting the amount of computation by half, halves your chances of cracking the key. With hashes and curves however, the drop off is quadratic: cutting the amount of computation by half, divides your chances by four. Basically, hashes and curves require you to go all the way, or you won't find anything.
Long story short, Curve25519 is enough, even though it ostensibly have "only 128 bits of security". I trust long term keys with it.
I don't have any problem believing at the same time that we need 256-bit cipher, and 265-bit curves are enough (even though they "only" have "128 bits of security"). Long terms keys are safe with Curve25519.
One last thing: signatures use a significant amount of stack space in most implementation. Ed448 will require even more stack space than Ed25519. Possibly a little under twice as much. That, and being significantly slower.
Simply put, Curve448 is harder to implement on embedded targets. Which turn out to be a pretty important niche for Monocypher: it's small enough for many targets, and when it fits, it's one of the fastest crypto libraries out there. (Libsodium does better on platforms that have vector instructions or 128-bit integers, but most embedded targets have none of this stuff.)
By the way, you plan to use two different curves for key exchange and signatures? If you used Curve448 for both, you could share code, and end up with a smaller program.
yota-code
It would be so nice to have a clean implementation of goldilocks ed448 signature, as beautifully carved as you did for the curve25519 ! libdecaf is a cluttered mess and I planned to do x25519 for ephemeral key exchange but ed448 to sign the "public secret" during the exchange itself :)