<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 24, 2014 at 1:56 PM, Bear <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2014-10-24 at 05:31 -0400, Bill Cox wrote:<br>
<br>
><br>
> So, why do we need true random data at high speed so badly that Intel<br>
> decided to build in a device requiring large capacitors and it's own<br>
> power regulator?  The truth is, we don't need high speed.  As many<br>
> people have argued here, all any single system requires is 256 bits of<br>
> true random data.  That's all they *ever* need, so long as it remains<br>
> secret (which is hard), and so long as a cryptographically secure PRNG<br>
> (CPRNG) is used to generate all future cryptographically pseudo-random<br>
> data (which is comparatively easy).<br>
<br>
<br>
I think I'm going to take issue with this.  While 256 bits plus a<br>
CPRNG is enough to prevent known and practical means of predicting<br>
the stream of numbers created, it does not constitute proof that<br>
a stream of outputs of that length *CANNOT* be predicted.  It<br>
restricts the uncorrelated sequence length to be provably no more<br>
than 256 bits.  Actually, it forces the uncorrelated sequence<br>
length to be provably less than 256 bits assuming a CPRNG.<br></blockquote></div><br></div><div class="gmail_extra">I agree with you about on point.  Turning off the TRNG leaves the CPRNG vulnerable.  In that case, if the CPRNG algorithm is broken, a lot of generated keys could be compromised.  Using a CPRNG with the TRNG turned off means your security drops to the level of the stream cipher or sponge chosen, which in theory is lower than a well designed TRNG.  In reality, I'm not so sure a CPRNG built using Keccak or ChaCha will be the weak link...<br><br></div><div class="gmail_extra">To help defend against this, the TRNG should be left on, and applications needing the highest security should still read from /dev/random, while applications that can live with the assumption that the CPRNG is secure can read from /dev/urandom.  When I write data to the Linux entropy pool, I only claim to write half as much as I measure.  This should enable it's CPRNG to generate any sequence, even if I am slightly off in my entropy estimate, though I would need to look under the hood at the Linux CPRNG to be sure.<br></div><br><div class="gmail_extra">I suppose there are some use cases for high speed TRNGs that are auditable and trustworthy.  Electronic one-time-pads for large organizations like the US military come to mind, though that seems a bit far-fetched.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Bill<br></div></div>