4 ms·

The API can easily accommodate adding a curve to crypto/ecdh, just not doing it outside the standard library. The reason not to implement X448 is simply that ~n

The API can easily accommodate adding a curve to crypto/ecdh, just not doing it outside the standard library. The reason not to implement X448 is simply that ~no one uses it, and it would be a lot of maintainer time to make it safe and make it fast. FWIW, no one uses X448 because if X25519 falls it's unlikely to be due to something that leaves us with any confidence in the similar-but-bigger Ed448 curve. It will have to be a cryptanalysis breakthrough or progress in quantum computers, both of which are more likely to break both than only one. The original Ed448 paper is a good read for understanding the "paranoia" motivation behind the curve. https://eprint.iacr.org/2015/625.pdf https://eprint.iacr.org/2015/625.pdf

coder543 4y ago
I'm not exactly a crypto expert, just someone who pays attention to this kind of stuff, so I might be incorrect or have some misconceptions, but even that paper's justification agrees that there are possible outcomes where a stronger curve could prevail in the face of a weakness of Ed25519. There are certainly scenarios where "all crypto becomes invalid" or "ECC becomes invalid" or "curves similar to Ed25519 become invalid", but with Defense In Depth... if all other things are equal, a stronger curve is better, and that is effectively the case here. The only downside of Ed448 that I'm aware of is a slight performance penalty, which is irrelevant in most applications, so there's no reason to actively choose a weaker curve. The "overkill" option is the sensible option in most cases. AFAIK, no one is actually encrypting large sums of data using an asymmetric algorithm like we're discussing. It's typically just used to encrypt a symmetric key, which is then lightning fast to use on the bulk of the data. The performance of the asymmetric algorithm is only important in very specific scenarios. I also believe that "no one" uses Ed448 in much the same way that "no one" uses JPEG XL; a lack of ecosystem support drastically hinders adoption, and it has nothing to do with people believing that Ed448 has no advantage over Ed25519. But, that's just like, my opinion. JPEG XL would be drastically better than the other image format options, but ecosystem support is a chicken and egg problem. Measuring the existing adoption of a poorly supported option doesn't give much insight. If people appreciate Ed25519 (and they really seem to), then offering the stronger version of Ed25519 seems like an obvious next step, even though it is a lot of work (which is why my original comment mentioned future proofing the API, but you seem to indicate that it is, so that's good). If the option existed and were exactly as easy to use, then why wouldn't people pick it for projects where the curve is open for selection?
- bobkazamakis 4y ago
  You're advocating for cryptographic agility, not defense in depth -- with multiple curves comes multiple vectors, and increased attack surface.
  - coder543 4y ago
    Perhaps that is a clearer choice of words, but I find it debatable to say this categorically isn't defense-in-depth. Choosing a stronger curve is similar to an additional level of defense, since it mitigates additional theoretical weaknesses that the lesser curve would not. The point of "defense-in-depth" is to add additional layers that mitigate different weaknesses. Maybe making a stronger layer isn't the same as adding an additional layer, but it has the same outcome, so it feels like a distinction without difference.
    - remus 4y ago
      > The point of "defense-in-depth" is to add additional layers that mitigate different weaknesses. Maybe making a stronger layer isn't the same as adding an additional layer, but it has the same outcome, so it feels like a distinction without difference. Not to speak for Filippo, but adding extra layers comes with a cost. Presumably they've weighed up the cost of adding this functionality (in terms of maintainer time etc.) and decided the cost of implementing it outweighed the benefit.
      - coder543 4y ago
        I agree. I'm mostly happy to hear that the new API is able to support Ed448 in the future; that it isn't locked out by a compatibility choice being made today.
    - stouset 4y ago
      > Breaking Curve25519 would not necessarily break Curve448, like a thicker wall which can withstand certain attacks that a thinner wall cannot. This sounds great to a non-cryptographer, but it's really not all that true. We've crossed a threshold where—to continue the metaphor—the wall is so thick that the only way it's likely to be breached either by going over/around it or by something that exploits a material weakness in a way where it doesn't matter in practice how thick the wall is. While it's of course possible that someone finds a way to break Curve25519 in a way that leaves Curve448 standing, I suspect that many cryptographers believe it's far more likely that an API handling multiple curves will create opportunities for vulnerabilities that otherwise wouldn't exist. Particularly when one of those code paths is used extremely infrequently.
aborsy 4y ago
>> if X25519 falls it's unlikely to be due to something that leaves us with any confidence in the similar-but-bigger Ed448 curve. It will have to be a cryptanalysis breakthrough or progress in quantum computers, both of which are more likely to break both than only one. This argument is often cited in this context, and is a bit generic. A bigger curve requires more qubits to break, costs more, and provides a number of additional years that could be important. Still I won’t use 448 (unless I need a prime-order group), because the support for it is limited, and you have to make sure it has been safely implemented.

coder543 4y ago

I'm not exactly a crypto expert, just someone who pays attention to this kind of stuff, so I might be incorrect or have some misconceptions, but even that paper's justification agrees that there are possible outcomes where a stronger curve could prevail in the face of a weakness of Ed25519. There are certainly scenarios where "all crypto becomes invalid" or "ECC becomes invalid" or "curves similar to Ed25519 become invalid", but with Defense In Depth... if all other things are equal, a stronger curve is better, and that is effectively the case here. The only downside of Ed448 that I'm aware of is a slight performance penalty, which is irrelevant in most applications, so there's no reason to actively choose a weaker curve. The "overkill" option is the sensible option in most cases. AFAIK, no one is actually encrypting large sums of data using an asymmetric algorithm like we're discussing. It's typically just used to encrypt a symmetric key, which is then lightning fast to use on the bulk of the data. The performance of the asymmetric algorithm is only important in very specific scenarios. I also believe that "no one" uses Ed448 in much the same way that "no one" uses JPEG XL; a lack of ecosystem support drastically hinders adoption, and it has nothing to do with people believing that Ed448 has no advantage over Ed25519. But, that's just like, my opinion. JPEG XL would be drastically better than the other image format options, but ecosystem support is a chicken and egg problem. Measuring the existing adoption of a poorly supported option doesn't give much insight. If people appreciate Ed25519 (and they really seem to), then offering the stronger version of Ed25519 seems like an obvious next step, even though it is a lot of work (which is why my original comment mentioned future proofing the API, but you seem to indicate that it is, so that's good). If the option existed and were exactly as easy to use, then why wouldn't people pick it for projects where the curve is open for selection?

bobkazamakis 4y ago
You're advocating for cryptographic agility, not defense in depth -- with multiple curves comes multiple vectors, and increased attack surface.
- coder543 4y ago
  Perhaps that is a clearer choice of words, but I find it debatable to say this categorically isn't defense-in-depth. Choosing a stronger curve is similar to an additional level of defense, since it mitigates additional theoretical weaknesses that the lesser curve would not. The point of "defense-in-depth" is to add additional layers that mitigate different weaknesses. Maybe making a stronger layer isn't the same as adding an additional layer, but it has the same outcome, so it feels like a distinction without difference.
  - remus 4y ago
    > The point of "defense-in-depth" is to add additional layers that mitigate different weaknesses. Maybe making a stronger layer isn't the same as adding an additional layer, but it has the same outcome, so it feels like a distinction without difference. Not to speak for Filippo, but adding extra layers comes with a cost. Presumably they've weighed up the cost of adding this functionality (in terms of maintainer time etc.) and decided the cost of implementing it outweighed the benefit.
    - coder543 4y ago
      I agree. I'm mostly happy to hear that the new API is able to support Ed448 in the future; that it isn't locked out by a compatibility choice being made today.
  - stouset 4y ago
    > Breaking Curve25519 would not necessarily break Curve448, like a thicker wall which can withstand certain attacks that a thinner wall cannot. This sounds great to a non-cryptographer, but it's really not all that true. We've crossed a threshold where—to continue the metaphor—the wall is so thick that the only way it's likely to be breached either by going over/around it or by something that exploits a material weakness in a way where it doesn't matter in practice how thick the wall is. While it's of course possible that someone finds a way to break Curve25519 in a way that leaves Curve448 standing, I suspect that many cryptographers believe it's far more likely that an API handling multiple curves will create opportunities for vulnerabilities that otherwise wouldn't exist. Particularly when one of those code paths is used extremely infrequently.

aborsy 4y ago

>> if X25519 falls it's unlikely to be due to something that leaves us with any confidence in the similar-but-bigger Ed448 curve. It will have to be a cryptanalysis breakthrough or progress in quantum computers, both of which are more likely to break both than only one. This argument is often cited in this context, and is a bit generic. A bigger curve requires more qubits to break, costs more, and provides a number of additional years that could be important. Still I won’t use 448 (unless I need a prime-order group), because the support for it is limited, and you have to make sure it has been safely implemented.