[Cryptech Tech] trng ready for play

[Bernd Paysan]

Am Montag, 6. Oktober 2014, 22:33:44 schrieb Fredrik Thulin:
> I guess one way to model it is to say the mixer could be asked for entropy
> in  a blocking or non-blocking way by the upper layers. If it is asked to
> block, it would just repeat until all entropy providers have returned
> enough bits (or the upper layer aborts the request perhaps) and if it was
> asked to do non- blocking entropy gathering it would respond EAGAIN up the
> stack.

There are several things to consider when you evaluate the mixer design.  
First of all, what is your thread model to the entropy sources?  The round-
robin mixer makes the thread model that there's a chance that the entropy 
sources are corrupted (controlled by the attacker), but not all of them, and 
it's unknown, which source is corrupted.  Therefore, reading the same amount 
of data from each of the sources to reseed the CSPRNG is a good idea, as is to 
read enough data so that after hashing it, the entropy of the good sources is 
enough to provide a good seed.

The way the hashing and the CSPRNG work also influence this design: As the 
current design uses SHA-2 and ChaCha, the reseeding procedure replaces the 
previous seed, and therefore each seed has to be really good.

I would have used Keccak as sponge function (and so does Bill Cox) today, 
which has different constraints for the mixer.  The sponge function allows 
partial reseeds whenever there is data from some entropy provider, and if you 
just fill up a buffer and do a sponge cycle whenever the buffer is full, no 
matter from which entropy provider the actual entropy comes from, you'll be 
fine, even if an entropy provider is controlled and injects known data at high 
speed - and you can split up the reseeding to small portions of data, if you 
like (e.g. 32 bits per reseed).  The reason for this is that Keccak as sponge 
function keeps enough of the previous state, so even feeding in known stuff 
doesn't reduce the entropy in the PRNG.  Actually, the smaller the amount of 
data you feed in per partial reseed, the more entropy from the previous 
seeding you preserve, i.e. small and frequent reseeds provide higher security 
than large and infrequent reseeds, even though the amount of entropy per 
reseed is the same.

Feeding in a full block of known stuff into SHA-2 as key for ChaCha however 
does reduce the entropy (we only have the counter, which isn't reset at 
reseeding).

That analysis shows that when you replace one part of a cryptographic system 
with a significantly different algorithm, you want to adjust other parts, as 
well, because sane design of each state depends on the knowledge how the other 
states work.  A Keccak-based CSPRNG would want an event-driven input with a 
small amount of data (something between 32 and 128 bits), and do small partial 
reseeds whenever there's entropy available, the SHA-2+ChaCha-based CSPRNG 
wants a big FIFO and a full reseed with a round-robin collection of data.

There would still be a health monitor timeout event in the Keccak case, which 
can inform higher levels that one of the entropy providers died.  This however 
would be a timeout value big enough to trigger only when the entropy provider 
is really dead, whereas the timeout we get now can just mean "you want to 
reseed too often".

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20141007/795991d7/attachment.sig>