Hacker News Reader

Comment by bobkazamakis | Hacker News Reader

You're advocating for cryptographic agility, not defense in depth -- with multiple curves comes multiple vectors, and increased attack surface.

View on HN

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.

> 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.

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.

> 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.

I removed that from that comment several minutes before your reply to just focus in on the terminology issue. I had already made the point about Ed448 being stronger than Ed25519 in the previous comment and the implications that has, so it seemed redundant to repeat here.

Regardless, whether it is "far less likely" or not, it appears to be a very real possibility that is being ignored in favor of what, exactly? An extremely marginal performance gain?

> I suspect that many cryptographers believe it's far less likely than an API handling multiple curves creates opportunities for vulnerabilities that otherwise wouldn't exist. Particularly when one of those code paths is used extremely infrequently.

Honestly, that's just as much an argument in favor of entirely deprecating support for Ed25519, in my view, but that would be an unpopular opinion. In reality, the ECDSA curves support multiple security levels. Has that additional curve support ever been the direct cause of a vulnerability?

It is entirely plausible that an attack is found which halves the number of bits of all EC algorithms (this is about the amount of progress on integer factorization during the 20th century). With such a breach, 1W28 bit security is no longer enough, but 220 bits is. When the performance difference is marginal, I think it makes a lot of sense to build in some wiggle room for a little breakage

That’s true of quantum attacks on symmetric systems, but I’m not aware of any work that hints toward such a possible future for elliptic curves.

If you know of something I’d love to hear it.

I don't know of any possible future for such attacks. My point is just that it's really hard to estimate the probability of unknown mathematical advancement so especially for secrets that you want to keep for a while, it's sensible to build in some buffer for mathematical advancement. I'm not an expert, but I would have a hard time being 99% sure that no one will come up with a sub-exponential algorithm (e.g. some sieving technique) that speeds up solving discrete logs (but doesn't make it trivial). If the cost of the improvement were high it would be a hard tradeoff, but I really don't see a strong argument that the extra couple nanoseconds are that important here.

It's not defense in depth because the curve you using failing means you're compromised and the fact other one exists in lib changes nothing.

This is not extra layer but a side entrance, especially if used protocol allows one side to pick what primitives to use, so attacker can make it use the vulnerable one.

Reply on news.ycombinator.com