On Sun, Jan 24, 2016 at 2:12 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > 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.
Standard conjectures in cryptography imply that counter mode for short messages is indistinguishable from random data. A device with 256 random bits can create a long random key . Maybe the issue is the HSM isn't made by people who know the first thing about cryptography, who believe the widely peddled nonsense about entropy. > > 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. The whole point of HSMs is to protect keys, by denying the ability to use the API in ways that reveal keys. Providing k along with the message breaks that entirely. > > Yoav > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
