Distinguish ECDSA malleability? about wycheproof HOT 12 OPEN

from wycheproof.

Is there an RFC or other documentation defining the requirements?

I.e., instead of trying to mix schemes, I'd rather generate separate test vectors for
"Bitcoin-ECDSA". If the signatures are DER encoded then I'd also expect that
all BER alternatives must be rejected.

Almost all of the libraries that I'm testing use special case code for the main
curves. Hence test vectors with special cases need to be included for all the curves.
In a lot of cases, I generate such test vectors by starting with the
edge case point addition and then compute corresponding keys and signatures.
I'll look into adding test with degenerate curves for other cases.

from wycheproof.

There are two restrictions enforced by libsecp256k1:

• The S value is between 0x1 and 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0, inclusive. See https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L458
• The signature is exactly DER-encoded. See BIP66 for well-documented C++ code for convenience.

edit: Maybe "Bitcoin-ECDSA" isn't the best name for it, because this is a tricky story. There is a discrepancy between what signatures are allowed in the Bitcoin blockchain, what signatures will be relayed in the P2P network by different implementations of Bitcoin and what signatures will be produced by those different implementations. (All due to historical reasons because OpenSSL was not strict about the things mentioned above). I'd suggest calling it "libsecp256k1-ECDSA" or something.

from wycheproof.

Two minor notes:

Funnily, #65 reports that wycheproof helped to discover a signature malleability due to high S values in EdDSA.

I had edited my previous comment to add a paragraph about naming. I assume you missed that paragraph (because you replied via email.)

from wycheproof.

No objection to calling it whatever you like, but you should be aware that the considerations extent outside Bitcoin, e.g. OpenSSL certificate blacklisting is vulnerable due to this malleability (I can take a valid ECDSA using certificate and make another one which is also valid but has a different hash). So it would be reasonable to expect totally bitcoin unrelated systems to adopt an equivalent countermeasure -- though potentially they might adopt a different tiebreaker, there are several options. We favoured this one because it was appeared the simplest for calling software to implement as a wrapper around a weaker signer/verifier.

from wycheproof.

I can take a valid ECDSA using certificate and make another one which is also valid but has a different hash

There are multiple ways of doing that. Blacklisting certificates that way doesn't work in general, and doing that should be considered a bug with potentially serious security consequences.

from wycheproof.

Maybe, but OpenSSL issued a CVE and a fix for evasion of hash based blacklisted based on using BER extensions in signatures: CVE-2014-8275. Use of ECDSA malleability appears to be an almost equally powerful way to exploit the same vulnerability, it's only weaker in that there are only two possible hashes.

from wycheproof.

Thanks for the pointers. I'm generating a separate file with test vectors for "Bitcoin-ECDSA". This makes it easier to specify how an implementation should behave.

Just a friendly reminder. Has there been progress on this?

from wycheproof.

from wycheproof.

Thanks, that's nice to hear! I think then libsecp256k1 would be the first thing to test against. Maybe bitcoin-core/secp256k1#609 helps as a starter.

Or I believe we could also help by providing an integration here. From what I understand, this repo targets Java but the test vectors were used also for C projects. How did other C libraries use the test vectors in practice?

from wycheproof.

Is there any update on this?

from wycheproof.

I believe this has been solved by fcee28b, thanks!

from wycheproof.