[Cryptography] Uncorrelated sequence length, was: A TRNG review per day

Bill Cox waywardgeek at gmail.com
Fri Oct 24 17:01:28 EDT 2014

On Fri, Oct 24, 2014 at 1:56 PM, Bear <bear at sonic.net> wrote:

> On Fri, 2014-10-24 at 05:31 -0400, Bill Cox wrote:
> >
> > So, why do we need true random data at high speed so badly that Intel
> > decided to build in a device requiring large capacitors and it's own
> > power regulator?  The truth is, we don't need high speed.  As many
> > people have argued here, all any single system requires is 256 bits of
> > true random data.  That's all they *ever* need, so long as it remains
> > secret (which is hard), and so long as a cryptographically secure PRNG
> > (CPRNG) is used to generate all future cryptographically pseudo-random
> > data (which is comparatively easy).
> I think I'm going to take issue with this.  While 256 bits plus a
> CPRNG is enough to prevent known and practical means of predicting
> the stream of numbers created, it does not constitute proof that
> a stream of outputs of that length *CANNOT* be predicted.  It
> restricts the uncorrelated sequence length to be provably no more
> than 256 bits.  Actually, it forces the uncorrelated sequence
> length to be provably less than 256 bits assuming a CPRNG.

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

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141024/c0d12a3c/attachment.html>

More information about the cryptography mailing list