3 ms·

With "ECDSA" I meant the original NIST ECDSA standard. It is, objectively, a bad standard. ECDSA as originally specified required the use of random numbers in s

With "ECDSA" I meant the original NIST ECDSA standard. It is, objectively, a bad standard. ECDSA as originally specified required the use of random numbers in signature generation; the RFC6979 approach may interoperate just fine and be a better idea, but it is not FIPS 186-4 compliant. If you have to break standards compliance to avoid security pitfalls, the standard is bad. It's not just about specifying more of the standard either. EdDSA is designed to be harder to screw up an implementation of, by construction.

nullc 5y ago
RFC6979 has a fairly convoluted design (and poor performance, requiring 12 invocations of the compression function when implemented with sha2 for a 256-bit curve) specifically so that it is actually a FIPS compliant DRBG with its initialization parameters set in a particular standard permitted way, so as to result in a derandomized nonce. While I not a FIPS certification expert by any means, it was intended that implementations could implement RFC6979 without breaking the standard by simply using a standard allowed DRBG in the right way. > EdDSA is designed to be harder to screw up an implementation of, by construction. That's the marketing claim at least. It's debatable. Some of its choices make it easier to screw up, and widespread implementations of it have also been wrong in the varrious ways it was intended to address. It's a good idea to try, at least, for sure. I think nonce security in particular is not at all the best example since modern ECDSA implementations are secure against in that respect. I'm also aware of some systems which have had grave security flaws because they believed the EdDSA claim of a deterministic signature meant that it was a unique signature. The promotion of EdDSA itself as magic pixie dust creates vulnerabilities. There is just no replacement for understanding. :)

nullc 5y ago

RFC6979 has a fairly convoluted design (and poor performance, requiring 12 invocations of the compression function when implemented with sha2 for a 256-bit curve) specifically so that it is actually a FIPS compliant DRBG with its initialization parameters set in a particular standard permitted way, so as to result in a derandomized nonce. While I not a FIPS certification expert by any means, it was intended that implementations could implement RFC6979 without breaking the standard by simply using a standard allowed DRBG in the right way. > EdDSA is designed to be harder to screw up an implementation of, by construction. That's the marketing claim at least. It's debatable. Some of its choices make it easier to screw up, and widespread implementations of it have also been wrong in the varrious ways it was intended to address. It's a good idea to try, at least, for sure. I think nonce security in particular is not at all the best example since modern ECDSA implementations are secure against in that respect. I'm also aware of some systems which have had grave security flaws because they believed the EdDSA claim of a deterministic signature meant that it was a unique signature. The promotion of EdDSA itself as magic pixie dust creates vulnerabilities. There is just no replacement for understanding. :)