8 ms·

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

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

some_furry 4y ago
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.
- coder543 4y ago
  > 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?
  - some_furry 4y ago
    > 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/6e6809be8290a7d7a9243b9491c09ec899ecb15b/fiat-c/src https://github.com/mit-plv/fiat-crypto/tree/6e6809be8290a7d7...
- tptacek 4y ago
  I think Filippo has the right side of this debate, but "SHA3 means likely memory corruption flaws" is not a great argument.
  - some_furry 4y ago
    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.
    - tptacek 4y ago
      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.
      - some_furry 4y ago
        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.
        tptacek 4y ago
        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.

some_furry 4y ago

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.

coder543 4y ago
> 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?
- some_furry 4y ago
  > 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/6e6809be8290a7d7a9243b9491c09ec899ecb15b/fiat-c/src https://github.com/mit-plv/fiat-crypto/tree/6e6809be8290a7d7...
tptacek 4y ago
I think Filippo has the right side of this debate, but "SHA3 means likely memory corruption flaws" is not a great argument.
- some_furry 4y ago
  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.
  - tptacek 4y ago
    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.
    - some_furry 4y ago
      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.
      - tptacek 4y ago
        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.