Re: [TLS] Require deterministic ECDSA

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?

Mike

>
>> On 23 Jan 2016, at 9:59 PM, Joseph Birr-Pixton <jpixton@gmail.com> wrote:
>>
>> Hi,
>>
>> The other benefit is being able to test that a critical code path
>> produces the correct answers. With randomised k, this is not really
>> possible. For instance, you can choose k with the top bit clear
>> without any obvious or externally-testable effects, except effectively
>> publishing your long-term private key after a large number of
>> signatures[1].
>>
>> Given the history of these things, I would perhaps challenge the
>> assumption that all TLS stacks will have a bug-free, thread-safe,
>> fork-safe, high quality, uncompromised, backdoor-free, unbiased random
>> number generator :)
>>
>> Cheers,
>> Joe
>>
>> [1]: http://people.rennes.inria.fr/Jean-Christophe.Zapalowicz/papers/asiacrypt2014.pdf
>>
>> On 23 January 2016 at 19:27, Jacob Maskiewicz <jmaskiew@eng.ucsd.edu> wrote:
>>> The main argument I see from the RFC for deterministic ECDSA is computing k
>>> on systems without high quality entropy sources. But any system running a
>>> TLS stack is already going to have a high quality entropy source for
>>> client/server randoms and IVs and such, so what's the benefit of
>>> deterministic ECDSA here?
>>>
>>> -Jake M
>>>
>>> On Jan 23, 2016 11:13 AM, "Joseph Birr-Pixton" <jpixton@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>>>>
>>>> For discussion, here's a pull request with possible language:
>>>>
>>>> https://github.com/tlswg/tls13-spec/pull/406
>>>>
>>>> Cheers,
>>>> Joe
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls