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/ma
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
[I guess we're top-posting...]
Another benefit is that if it turns out the entropy source is broken,
then if client/server random or IV is guessable, that's something that
affects one connection and can be addressed for future connections by
fixing the entropy source. But if k generation is broke
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 sec
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-spec/pull/406
Cheers,
Joe
___
TLS
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 ke
On 1/23/2016 3:16 PM, Geoffrey Keating wrote:
But if k generation is broken, then that
leaks the key permanently and you need to get a new one and revoke the
old one, which may be difficult.
I agree that if RNG generation is broken then it breaks k generation.
But if RNG generation was brok
Joseph Birr-Pixton wrote:
> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>
What about the way BoringSSL (and OpenSSL, I think) does it? It
incorporates all the inputs that RFC6979 does, but using SHA-512 instead of
HMAC. And, it also includes a random element in the SHA-
On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote:
> 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 signatur
