4 ms·

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 SH

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.

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.