Hi, Recently I implemented RFC 6979 and also I'm implementing some CT things.
Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA signatures. However, the requirement to use RFC 6979 is problematic for several reasons, noted below. I think this group should reconsider if the fingerprinting threat that motivated the requirement for deterministic signatures is significant enough to overcome these problems. If the requirement for deterministic signatures were removed, all the problems below would be resolved. (Additionally the more secure RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1 1.5.) If it is still seen as very important to require signatures be deterministic, the requirement to to use specifically RFC 6979 should be be removed, and replaced with a more general requirement to use *some* secure deterministic nonce for ECDSA signatures, without mandating RFC 6979 specifically. Here are the problems I see with mandating the use of RFC 6979: 1. RFC 6979 deterministic signatures are not and cannot be compliant with FIPS and other regulations. This means, in particular, that a log cannot use the same CABForum-compliant (HSM) ECDSA implementation that it could use to sign certificates. 2. RFC 6979 is a very inefficient way of generating deterministic signatures. Every RFC 6979 signature requires invoking the SHA-256 compression function 19 to 22 times. The BitCoin core developers reported that this takes 10% of total signature generation time. [0] 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for ECDSA. This is a step backward from recent progress towards provable security of internet protocols. 4. Because of #1, #2, and #3, most crypto libraries and HSM implementations would be better off using a different deterministic signature scheme (such as a variant of the much more efficient one used for Ed25519). And/or they may use a different, non-deterministic, solution to the concerns that originally motivated the creation of RFC 6979 in the first place, such as the one that Google's BoringSSL [1] and Cisco [2] have implemented. If one is going to use a better scheme, then maintaining RFC 6979 support too just for this one protocol is a large burden. 5. There is no way to check that the log actually used RFC 6979, or any other specific secure deterministic scheme, because part of calculating the nonce involves hashing the private key. Thus the requirement to use RFC 6979 is unenforceable technically or even by policy. [0] https://crypto.stackexchange.com/a/42551 (I can't find the original citation for what the Bitcoin people said.) [1] https://boringssl.googlesource.com/boringssl/+/783e0957875ac62b35aa4f8741069e133695a3d4 [2] https://blogs.cisco.com/security/fips-and-deterministic-ecdsa-achieving-robust-security-and-conformance Cheers, Brian -- https://briansmith.org/ _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
