Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell <[e-mail]>]

On 25/07/17 04:53, Peter Gutmann wrote:
> Colm MacCárthaigh <[e-mail]> 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.
>