EDP (entropy distribution protocol), userland PRNG design

[Travis H.]

Assume that one is the sole user of a LAN and that the 10-20 machines
on this network have a need for unpredictable numbers.

Assume further that it is not cost-effective to furnish each with a
HWRNG, even one as inexpensive as a sound card (for example, they may
not have a spare slot on the motherboard nor built-in sound).

So basically, one must either:
1) Use something like /dev/random, which uses complex but
deterministic events to hopefully generate unpredictable numbers,
albeit at a slow rate.
2) Send random numbers to them over the LAN.

First a mention of /dev/random.  In this case, let's assume NetBSD's
/dev/random implementation.  That is a pool with an estimated entropy
count, and it mixes inputs into the pool using a simple LFSR
algorithm, and hashes the pool to get output using SHA-1.

For people who want the gory details, source is here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/rnd.c?rev=1.46.2.1&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/rndpool.c?rev=1.19&content-type=text/x-cvsweb-markup

Suppose that /dev/random is too slow (SHA-1 was never meant to
generate a lot of output) because one of these machines wishes to
generate a large file for use as a one-time pad*.  That leaves
distributing bits.

So now that one has decided to send them numbers over the LAN, one
decides to protect the confidentiality via encryption, and to protect
against malicious insertion via authentication and integrity.  So one
could use a conventional cipher and signature to protect it in
transit.  For simplicity let's just consider the encryption, and
ignore integrity/authentication for a moment.

Since these numbers are random to begin with, and the only goal is to
get random numbers on the receiving node, is there any reason to use
the same encryption key on both ends?  That is, would it not be safer
to use a random key (obtained from the slow /dev/random device) on the
receiving end, since it then would have very little chance of being
disclosed (by virtue of never being negotiated or transmitted)?  And
since the receiver's key is randomly generated (via local means), is
there any reason to do any encryption at all on the sending end?

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?

[*] Alternately, I could use FreeBSD's /dev/random, which is
essentially Yarrow, but reseeded with some low-level timings.  This
would leave me with pseudorandom bits that are somewhere between
counter-mode AES and truly random bits.  I feel that this would not
create strong enough OTPs to justify using an OTP algorithm, but I
suppose you could argue that the method I propose isn't either, if you
don't trust the privacy of your own LAN.

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