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 <jpix...@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 <jmask...@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" <jpix...@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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
