3 ms·

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

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