On 25/07/17 04:53, Peter Gutmann wrote: > Colm MacCárthaigh <c...@allcosts.net> writes: > >> I think the fix for this is really at the application level; if you >> want defense-in-depth against PRNG problems, it's probably best to use >> separate RNG instances for public data (e.g. client_random, >> server_random, explicit_IV) and for secret data (keys) so that a leak >> in the public data doesn't compromise the private one. We do this in >> s2n, and I think BouncyCastle does it too. > > I do that too. It's also specified in the LTS draft, it's just common > sense really.
I guess you mean this:
"
TLS-LTS drops the requirement to generate the Client.random and
Server.random using "a secure random number generator", typically the
one used to generate encryption keys. The use of a secure/
cryptographic random number generator serves no obvious purpose (all
that's required is a unique value), but exposes 224 bits of the
cryptographic RNG output to an attacker, allowing them to analyse and
potentially attack the RNG, and by extension any crypto keys that it
generates:
o Implementations SHOULD NOT use the raw output from a
cryptographic/secure RNG that's used to generate keying material
to generate the Client.random and Server.random values. Instead,
they SHOULD employ a mechanism that doesn't directly expose
cryptographic RNG output to attackers, for example by using the
crypto RNG to seed a hash-based PRF such as the TLS PRF and using
the output of that for the values.
"
I think something along these lines would be good advice to add
to appendix C.1 or to 4.1.2 where Random is defined.
That said, I'd still argue for an approach that a peer could
see was in use when "public" random byes aren't really needed but
fair enough if that doesn't resonate with people.
Cheers,
S.
>
> Peter.
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
