Hi, Mike
> On 24 Jan 2016, at 2:53 AM, Michael StJohns 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 rand
> On 24 Jan 2016, at 2:47 AM, Michael StJohns wrote:
>
> On 1/23/2016 2:13 PM, Joseph Birr-Pixton 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-
On Sun, Jan 24, 2016 at 2:12 AM, Yoav Nir wrote:
> Hi, Mike
>
>> On 24 Jan 2016, at 2:53 AM, Michael StJohns 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.
>>>
Strong support for this. TLS will be deployed with broken
implementations and on broken systems. Anything the spec can do to
limit or prevent damage is more than appropriate.
However, agreed that a SHOULD makes more sense, to avoid having
discussions about OpenSSL not being compliant because of a
On 1/24/2016 5:15 AM, Yoav Nir wrote:
>Correct me if I'm wrong but:
>
>1) A receiver of an deterministic ECDSA signature verifies it EXACTLY like
they would a non-deterministic signature.
>2) A receiver of an ECDSA signature cannot determine whether or not the signer
did a deterministic signatu
On 1/24/2016 5:12 AM, Yoav Nir wrote:
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 thous
Sorry - I hit the wrong "reply to" button.
Forwarded Message
Subject:Re: Require deterministic ECDSA
Date: Sat, 23 Jan 2016 20:52:53 -0500
From: Michael StJohns
To: Geoffrey Keating
On 1/23/2016 8:05 PM, Geoffrey Keating wrote:
Michael StJohns writes:
O
