Re: [TLS] Require deterministic ECDSA

On Sun, Jan 24, 2016 at 2:12 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> Hi, Mike
>
>> On 24 Jan 2016, at 2:53 AM, Michael StJohns <msj@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.