Hi, Mike > On 24 Jan 2016, at 2:53 AM, Michael StJohns <m...@nthpermutation.com> wrote: > > On 1/23/2016 7:17 PM, Yoav Nir wrote: >> Also if the signatures are done in a separate hardware module, that module >> is even less likely to have a good random source. >> >> And if we make it rely on external input for the random, that’s a good way >> of getting it to reveal information about the private key, whereas keeping >> the private key secret forever was the whole point of using a hardware >> module. >> >> So that’s another argument in favor of deterministic signatures. >> >> Yoav > > I tried to parse the above into meaningful A implies B logic and failed. > > If you have an HSM, the key that's generating the signature tends to be > generated inside the HSM. If your HSM has a bad RNG, then the key generation > is going to be a problem well before the signature generation RNG problem > kicks in. And to clarify, a key generated inside an HSM tends to use that > HSM's signature mechanism, not something in a separate module. > > I don't think your argument holds. > > "If we make it rely on external input for the random"??? Isn't that exactly > what the RFC uses in the form of the hashed message?
Yeah, it was way past midnight when I wrote that. Only so much coherence in those hours. The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or 521-bit) key. When working as part of a TLS server using regular ECDSA it would need to generate a random k for each full handshake, and many such servers routinely handle tens of thousands of such handshakes per second. So it’s hundreds of kilobytes per second, for an HSM that has no network input, no I/O of any kind other than the signature requests, this may be a problem. I’ve seen people claim this in the past. That last sentence there. If we’re using regular ECDSA, the HSM can either generate its own k or receive a k from the caller. For our software’s FIPS certification we had to support both modes to be able to produce a predictable ECDSA. I don’t know, but I imagine hardware would be required to support this as well. If you run the HSM in production with the external random input, you’re making it possible for an attacker who has compromised the system to discover the key bits by repeatedly calling the HSM with same k’s for different inputs. This is negated by using deterministic ECDSA where the k is a function of the input. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
