Colm MacCárthaigh wrote: > Martin Rex <m...@sap.com> 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.
We're either talking about different things, or I fail to understand what you're talking about. The predictable failure of EC_Dual was based on the fact that the internal state and the output had (almost) the _same_ size. With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of a black-box CPRNG output into a 256-bit _new_ output that you actually use in communication protocols. Should the creator of a backdoored black-box-CPRNG be able to recompute the internal state from a few leaked _new_ (post-compression) outputs, then you _will_ be able to notice a real problem (non-randomness) problem with the outputs of black-box-CPRNG. > > 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. Any half-way portable crypto library will have code for collecting entropy on pre-RDRAND Intel CPUs and non-Intel CPUs, probably use an entropy pool that is >=512 bits and outputs of at most half of the size of the entropy pool, and use compressed RDRAND outputs for additional entropy gathering, and at most for nonces, but never use RDRAND alone for generation of secret keying material. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
