On Sat, Jan 23, 2016 at 9:20 PM, Brian Smith <br...@briansmith.org> wrote: >> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA. > > What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates > all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it > also includes a random element in the SHA-512 hash. > > Ed25519 uses SHA-512 instead of HMAC for the same purpose and people seem to > think it works fine. > > Also hashing in some randomness seems like it would help avoid some side > channel leakage. Note that most (all the ones I've looked at for more than 5 > minutes) open-source ECDSA implementations have side-channel issues of > various levels of significance. > > Anyway, I do think that implementations should do something *like this* to > avoid problems when the RNG is bad, but I think prescribing RFC 6979 as the > solution is overly-specific, especially when it doesn't even seem to be the > best way to accomplish the goal in many cases.
I wrote that design before RFC6979 (or, at least, before I was aware of it). The reason that I included randomness into the mix was because I worried that someone might be depending on the randomised nature of ECDSA signatures and suddenly making them deterministic seemed like a risky thing to do. That's not a problem in TLS. I think that those implementations that care about DPA-level side-channel attacks will probably do their thing no matter what the standard says, so I wouldn't have an objection to putting a "SHOULD" in the spec for RFC 6979. I suspect that adherence would be poor, however. As for using that RFC over what I came up with or anything else: at least RFC 6979 has been written down already. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
