EDP (entropy distribution protocol), userland PRNG design

[Travis H.]

> I can't say I a fan of the idea of having multiple ways of mixing entropy into
> the system. In particular, the idea of producing output by XORing your PRNGs
> output with the output of a semi-public RNG seems like a bad idea to me,
> because an attacker can easily control those values by taking over the web
> server or modifying packets in the network, and if they can somehow predict
> your PRNG outputs then they will be able to actually control the final output.

Ah yes, leveraging a known output into a controlled output would be bad indeed.

> I prefer a multi-stage design, as described by various people smarter than I
> am:
>
>  source(s) --> mixer --> pool --> extractor --> X9.31

Where can I find out more about the design choices for these stages?

> I believe most common hardware RNGs produce data at fairly high rates, often
> over 100 kbytes per second.

Some do, some don't.  Depends on the random source they are tapping.

Mine, the Atom Age HWRNG, produces them at 9600bps:
http://atom_age.tripod.com

Here are two others:

The Intel Random Number Generator
    http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf
The Via C3 Nehemiah RNG
    http://www.cryptography.com/resources/whitepapers/VIA_rng.pdf

The actual output rate depends on things like whitening and von
Neumann correctors, and so may vary.  In any case, the source has some
limit on the entropy rate, and oversampling won't help you generate
random bits any faster; you will get more bits but no more randomness.

With HWRNGs based on radioactive decay, going fast means using some
very unsafe substances.

There are some very fast RNGs, such as the quantis:

http://www.idquantique.com/products/quantis.htm

However, that's a sealed opaque package, so I don't fully trust it. 
I've been wondering if there's a way I could use it such that I didn't
have to fully trust it.  For example, if I could combine several, so
that an effective attack would require collusion of several parties.

> Instead of treating the two entropy sources as somehow different in your mixing
> strategy, just use the HWRNG for most of the inputs, but every tenth sample (or
> whatever), instead use the hash of all the random-looking system data you can
> get ahold of. Only doing it occasionally means there is a reasonable chance
> that sufficient changes have happend to the system since the sample worthwhile
> in terms of entropy gained, and doing a large block of it all at once prevents
> iterative guessing attacks if an attacker can control your HWRNG outputs but
> not your system statistics.

That seems like a very ad-hoc system that treats the HWRNG and
random-looking system data as somehow different (one is used for 90%
of the samples, one for 10%).

> Encrypting the output using keys generated by the PRNG is a good idea, but you
> presented it in a somewhat confusing way, in that it sounded almost like you
> were doing message transfer. [...]
> At not point do the two sides actually exchange messages,

I don't follow.  I'm transmitting entropy from the source to where it
is needed; surely this is a message of some kind?

I think I see what you mean, though, in that you don't need to think
of the encryption as part of the network protocol, but rather as
processing of the already-transmitted data.

> If
> you want to try to keep the entropy values sent from the box with the HWRNG to
> the client a secret from people on the network, just open up a TLS session.

TLS is SSL, right?

Transmitting over SSL would limit the strength to the minimum of the
strength of the asymmetric and symmetric ciphers.  Using my method
alone would not involve PK, so would be faster, need less entropy to
start with, and also the upper bound on strength is the same or
higher.  What I'm saying is that a chain is only as strong as its
weakest link, and my protocol has one less link.

> at little or no extra cost. You can buy a PCI board with a low-end Hifn crypto
> chip on it for less than $80 online.


For anyone who is interested, here is a link:
http://www.hifn.com/info/candp/Boardpartners.html
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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