EDP (entropy distribution protocol), userland PRNG design

[Eric Rescorla]

"Travis H." <solinym at gmail.com> writes:
> That leaves me with the following design:
>
> That random numbers be sent en clair from the system that can generate
> them to the system that needs them, where they are decrypted using a
> random key (generated locally by /dev/random) and fed into the system
> that needs them, in this case the pool used by /dev/random (where they
> will be hashed together with interrupt timings and other complex
> phenomena before being used).
>
> If the attacker has no access to the LAN traffic, then it gives the
> benefit of a local HWRNG.  If the attacker has access to all the
> network traffic and a great deal of the output of /dev/random on the
> receiving machine, he has at best, a "ciphertext" and the hash of the
> (completely random) "plaintext" to work with.  In actuality it is
> liable to be less clear than that, as /dev/random will scramble it
> with a bunch of low-level stuff and give the hash of that.  State
> remains in the /dev/random pool, so that the next transmission will be
> mixed with the pool created by the first transmission and so on.  So
> in practice an attacker wouldn't even have the hash of the plaintext.
>
> Does anyone see any problem with the reasoning or resultant design? 
> I'd prefer to not argue over the assumptions.  Does anyone have any
> ideas about how to handle authentication/integrity?

Look, this design just reduces to a standard cryptographic PRNG with
some of the seed being random and periodically being reseeded by the
"random" network stream you're sending around. There's no need to
worry about the integrity or confidentiality of the "random" stream
because anyone who controls the network already knows this input. The
only information they don't have is your "random" private key.

That said, frankly, this is all rather silly. A good cryptographic
PRNG seeded with a few hundred bytes of high-quality randomness is
good enough for bits of randomness is good enough for practically any
purpose. Practically the only thing it's not useful for is for
generating OTPs, which, as people have repeatedly told you on this
list, you shouldn't be doing anyway.

Note further that no CPRNG can be safely used to generate OTPs--except
for rather short ones--because the entropy of the resulting randomness
stream is bounded by the size of the CPRNG state no matter how many     
bits of entropy you feed into it. The technical term for this is a 
stream cipher.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com