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

[Colm MacCárthaigh <[e-mail]>]

On Wed, Jul 26, 2017 at 6:22 AM, Martin Rex <[e-mail]> wrote:

> Since you also have no idea whether and how the internal hardware design
> behind Intel RDRAND is backdoored, you should not be using any of its
> output without an at least 10x cryptographic compression in any case.
>

Obviously your CPU can fully compromise you locally, so that's not very
interesting to think about. But for remote attacks, like the one you
describe here, where an adversary may use predictable PRNG output, it is
probably better to mix RDRAND output with something else. There are a few
layers of defense here, such as multi-source NRBGs, or personalization
strings. Those significantly distance the output from the RDRAND. The kind
of compression you mention here can be easily precomputed and tables
generated by someone with a large amount of resources, since it's a pure
function.

In BoringSSL, and s2n, we mix RDRAND in as part of the reseeding. But the
initial seed came from urandom (which is not pure RDRAND). In s2n, we also
use personalization strings to provide another degree of defense.


-- 
Colm