[cryptography] Enranda: 4MB/s Userspace TRNG

Krisztián Pintér pinterkr at gmail.com
Wed May 27 11:10:07 EDT 2015


On Wed, May 27, 2015 at 3:18 PM, Russell Leidich <pkejjy at gmail.com> wrote:
> I realize that anyone can whiten a long stream of weak entropy into a short
> stream of strong entropy. But I disagree that doing so properly, in this
> case, is trivial.

here is a general solution:

1, initialize a cryptographic sponge
2, absorb N bits worth of raw data (N >= 128)
3, squeeze N bits
4, goto 2

you can further optimize this by making N a multiple of the block
size. you can also be less pedantic, and once you absorbed 128 bit of
entropy, just use the sponge as PRNG, you don't need to input anything
anymore.

here is a less general, but more stable and easier solution:

1. write your data to /dev/random
2. use /dev/urandom to get data

both of these methods are trivial.


> Do you really think that even a "smart" attacker can model a live CPU well
> enough to predict tens of thousands of unique timedelta sequences in a row?

yes. it is not even that hard. in fact some compilers use CPU
emulators for optimization. supposedly not perfect emulators, as i
believe the actual CPU architecture is not public. however, dedicated
attackers might be able to build adequate models. one of such
attackers is Intel itself, having the schematics. and many older CPUs
have known schematics.

actually, it would be an interesting experiment. run the algorithm on
an emulator, without any entropy at all, and see the output. my guess
is the algorithm will continue to churn out pseudorandom data that
passes randomness tests. that is because of the chaotic CPU behavior,
and your whitening.


> real system running enough of an OS to be interesting enough to attack, let alone
> if it has received network or harddrive packets (and in the absence of
> unrelated kernel vulns and the like), whether or not it's currently
> connected to the network.

you see, you are still struggling with the definition of entropy. in
this example, the entropy is the harddrive timing, network timing,
user input, etc. guess what, it is NOT 4Mb/s, but way way less than
that. and especially much less on a box packed with ssd and no user
input. but my major point is that the actual entropy is *unknown*, and
i see no actual attempt to find out how much.

on the top of this true entropy, you have a chaotic deterministic
system. it hardens analysis, but it does not generate entropy.

btw it does not render your collector entirely useless. it just
renders it mostly useless. this is what you actually offer:

1, simplified entropy collection by exploiting the fact that the
history of CPU appears in its current internal state, and the internal
state affects its timings.
2, absolutely no entropy estimation of any sort, except that it is
capped by your system entropy (events outside the CPU), but can be
even less.
3, non-reviewed non-cryptographic algorithm and implementation


More information about the cryptography mailing list