ed448

[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 :)

[LoupVaillant]

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]

Thanks for the long answer !

Indeed, I had in mind long terms keys. But I understand your point of view. And since I favor the monocypher way (because it's embeddable and because it has blake2b instead of sha 😄) I will continue my project as this.

This request was more a question of personal curiosity. I was eager to see a clean and embeddable curve448.
I don't feel ready to implement one myself yet but I'll share the code for sure if I do.

En tout cas, beau boulot

[LoupVaillant]

By the way, the fact you're talking about ephemeral keys and signing keys in the same sentence suggest you are working on a key exchange protocol. I'm working on one, which is inspired by the Noise protocol framework. Note that those protocols rely entirely on Diffie Hellman key exchanges, and don't use signatures. Which I like very much, because it means that in most cases, your implementation can be smaller (even more embeddable!).

Monokex is meant to be used with Monocypher. Part of it will even ship with Monocypher (upcoming version 2.1.0). It should address most fully online use cases, and most fully offline use cases. Depending on what you are doing, and if I ship the damn thing fast enough, you may want to consider taking a look at Monokex. Or Noise. (I did Monokex even though we have Noise because I felt Noise was more complicated than needed. Monokex also relies on fewer primitives: X25519, Blake2b, Chacha20.)

One last question: since you're using Monocypher, would you like to be added to the users page? That page is currently a bit empty…

[yota-code]

I would be glad to appear in your user page ! But I have no project which has reached this level of maturity :D

The project I'm working on now is more like a toy project. When I start such toy projects, my first goal is to find an excuse to broaden my knowledge on a subject. As a side effect, it may be useful.
I would be glad to exchange my preliminary thoughts on the subject, but this closed topic may not be the best place to do so. And I may be more comfortable to continue this discussion in french (for less grammatical glitches and more intelligible content).

Monokex looks very interesting ! But I'm not familiar enough with the Noise protocol to have a better opinion on it :)

[LoupVaillant]

Shoot me an email (monocypher@loup-vaillant.fr), we'll talk privately (et en français 😄). Just check your spam folder if you're using Gmail, they tend to be a bit strict.

[LoupVaillant]

I'm not familiar enough with the Noise protocol to have a better opinion on it :)

Noise is an excellent protocol, way simpler than stuff like TLS (even 1.3). I just have exacting standards: if I feel a hint of imperfection, I feel the urge to dig deeper.