Comment by FiloSottile | Hacker News Reader

Comment by FiloSottile | Hacker News Reader

Parent Full thread

> If the option existed and were exactly as easy to use, then why wouldn't people pick it for projects were the curve is open for selection?

It’s a good question with a nuanced answer. First, performance. The amount of data encrypted has no effect on key exchanges like X25519 and X448. They happen once per connection/exchange/encryption/decryption and have a fixed cost. In synchronous settings like TLS that time shows up directly as first byte latency. Second, a hard to quantify ecosystem risk: what are the chances you get broken by one of the few attacks that get X25519 but not X448, versus the chances you get broken by an implementation bug in the lesser used X448 implementation?

Cryptography engineering doesn’t happen in a vacuum. When selecting primitives you have to weigh the risks you are mitigating against the cost in engineering and hardware resources, and compare them against other risks you could be mitigating with those resources. It’s very unlikely the risk gap between X25519 and X448 is where anyone should invest next.

To add to what Filippo said: Your Ed448 implementation will also need SHAKE256. SHAKE256 is a SHA3 variant.

There was a recent flurry of buffer overflows in SHA3 implementations. I'm aware of at least PHP being affected.

Wanting Ed448 for political reasons, or purely for psychological comfort reasons, is a perfectly understandable stance to take as a non-expert.

Unfortunately, the details that experts are privy to matter a ton, and severely outweigh any notions of having eggs in multiple baskets.

When cryptography nerds say "don't bother with Ed448", we're open to having our risk calculus checked, but we're nearly unanimous on this one.

The only real reason to prefer 448 over 25519 is "our legal/compliance folks say we need 192-bit or greater security for our asymmetric keys, or we void our [contract, license, certification, etc.]".

If anyone does fall into that trapping, please speak up.

> There was a recent flurry of buffer overflows in SHA3 implementations. I'm aware of at least PHP being affected.

Both your comment here and some stuff FiloSottile implied in the comment above seem like they would be (largely) mitigated by what the "Go 1.20 Cryptography" post mentions about using formally verified primitives that are generated by "fiat-crypto".

Beyond the curve primitive, wouldn't the majority of the code involved be shared/identical? These are closely related curves, not some oddball algorithm that requires a bespoke implementation. If things were more bespoke, I completely agree that would drastically alter the calculus, but if Ed448 is closely related, that seems like it would limit the surface area for mistakes quite a bit?

> Both your comment here and some stuff FiloSottile implied in the comment above seem like they would be (largely) mitigated by what the "Go 1.20 Cryptography" post mentions about using formally verified primitives that are generated by "fiat-crypto".

> Beyond the curve primitive, wouldn't the majority of the code involved be shared/identical? These are closely related curves, not some oddball algorithm that requires a bespoke implementation.

Well, fiat-crypto only provides the curve implementations.

Each language, library, etc. that wants to support ed448 will need a SHAKE256 implementation too. Given the memory bugs in SHA3 implementations, that has historically not been a safe addition, in practice.

Also, I don't see Ed448 on here (but I do see P448? Not sure if that's interoperable): https://github.com/mit-plv/fiat-crypto/tree/6e6809be8290a7d7...

I think Filippo has the right side of this debate, but "SHA3 means likely memory corruption flaws" is not a great argument.

Yeah that's not my argument at all.

My argument is specifically: "SHA3 implementations are necessary for Ed448, which increases code size and therefore also increases attack surface". The memory corruption bug was just a specific recent data point about the attack surface increase.

The more meta point is "just add one more algorithm" isn't a free decision. It involves non-obvious trade-offs.

I hope that makes it clearer.

Oh, I follow the argument, I just don't think it's persuasive. You wouldn't look at a system that deliberately built on SHA3 and say it was worse than a Blake2 scheme because of SHA3 code quality concerns, so I don't think it's a particularly compelling reason to pick a curve.

It's difficult to determine whether you follow an argument when you summarize it in a way that sounds incorrect.

If that's an attempt at highlighting that what you summarized is not persuasive, your tactic also isn't very persuasive. Instead it comes across as snarky, dismissive, or that you misunderstood. It might be worth reconsidering this tactic.

The main reason I wouldn't pick Ed448 is simpler: Nothing else really uses it.

For what it's worth, I'm responding to this:

    There was a recent flurry of buffer overflows in SHA3
    implementations. I'm aware of at least PHP being affected.
     
    Wanting Ed448 for political reasons, or purely for psychological
    comfort reasons, is a perfectly understandable stance to take as a
    non-expert.
     
    Unfortunately, the details that experts are privy to matter a ton, and
    severely outweigh any notions of having eggs in multiple
    baskets. We're open to having our risk calculus checked, but we're
    nearly unanimous on this one.

Who's "we" here? I think Filippo has a mainstream take on the 448 curves, but I don't know that your take on SHA3 is widely shared.

We here is people who don't advise using Ed448. It's tautology.

You don't have to agree with the specific reason I cited. That isn't encapsulated by "we". I was providing an additional argument in case the mainstream take isn't sufficient.

You cut the "To add to what Filippo said" part out of the excerpt you quoted, which was the necessary context to understand I was making an additional, supplementary argument.

I don't agree with the specific reason you cited, which is what I wrote about.

Reply on news.ycombinator.com