3 ms·

And this is one of the reasons why ECDSA is a poor standard: it's too easy to accidentally screw it up, and it results in the worst possible kind of compromise

And this is one of the reasons why ECDSA is a poor standard: it's too easy to accidentally screw it up, and it results in the worst possible kind of compromise (private key). There is a better way: make the nonce a hash of the message signature and the private key. That way you don't need any randomness, and the entire algorithm is deterministic. It is guaranteed (assuming the hash is good, but you need a good hash algorithm to sign things anyway) that no two messages will be signed with the same nonce, and that the nonce cannot be guessed without already having the private key. This is what EdDSA does.

drexlspivey 5y ago
Most modern wallets nowdays use deterministic nonces via RFC 6979. The newly introduced Schnorr signatures also do not have this weakness afaik.
nullc 5y ago
"ECDSA" isn't a concrete scheme that you can use in any case. To implement ECDSA one must pick a group where the discrete log is hard, choose a message hashing function, and choose a way to serialize the values. One can optionally choose a derandomized method for generating the nonces, e.g. RFC6979 which is the approach taken by most implementations created in the last 5 years or so. One could just as well implement something EdDSA compatible with insecure nonce generation and people have done so (for years the thing you got when you goggled for eddsa python was just such an implementation). It's good that the eddsa paper specifies more of the system, as people have made bad choices and ruined the security-- but even it fails to completely specify the system: the exact input handling isn't specified, which has resulted in security problems.
- marcan_42 5y ago
  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. :)

drexlspivey 5y ago

Most modern wallets nowdays use deterministic nonces via RFC 6979. The newly introduced Schnorr signatures also do not have this weakness afaik.

nullc 5y ago

"ECDSA" isn't a concrete scheme that you can use in any case. To implement ECDSA one must pick a group where the discrete log is hard, choose a message hashing function, and choose a way to serialize the values. One can optionally choose a derandomized method for generating the nonces, e.g. RFC6979 which is the approach taken by most implementations created in the last 5 years or so. One could just as well implement something EdDSA compatible with insecure nonce generation and people have done so (for years the thing you got when you goggled for eddsa python was just such an implementation). It's good that the eddsa paper specifies more of the system, as people have made bad choices and ruined the security-- but even it fails to completely specify the system: the exact input handling isn't specified, which has resulted in security problems.

marcan_42 5y ago
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. :)