[cryptography] Enranda: 4MB/s Userspace TRNG

Russell Leidich pkejjy at gmail.com
Wed May 27 21:18:41 EDT 2015


I generally agree with your proposed methods of sponging out entropy.

The result of your emulator experiment is a foregone conclusion, unless
there's a bug somewhere:

1. If the emulator is counting some fake notion of clocks-per-instruction,
then Enranda in fill mode will fail to fill because we'll have period-1,
whereas we filter out up to period-255.

2. If the emulator is counting is own emulation time and/or OS overhead
into the TSC, then it should (eventually) finish and issue entropy.

If you flush the cache, shut off all IRQs, IPIs, DMAs, etc., and don't
fetch cache lines from an asynchronous clock domain, then I think an attack
would work in accrual (nonfill) mode, assuming that you had some other
pseudorandom timing source to make things look sufficiently interesting. So
I don't think that the boot block of the firmware is a place where it's
safe to run Enranda in accrual mode; fill mode should just hang.

I think Ron Garret made the point most clearly: entropy is in the eye of
the beholder. So in this case, when Enranda's model of predictability runs
dry, all that remains is entropy (to Enranda). So if your point is that its
output entropy comes mostly from pseudorandom processes, from the
perspective of an educated attacker, I agree. My contention is that those
processes are too hard to model in any realistic OS context. But maybe
there's a really simple but useful system in which that's not the case. If
people want to call it a "simplified entropy collector" which extracts some
entropy from already-past events, and then morph it into something else
entirely, that's fine with me.

Thanks for the feedback, all.

Russell Leidich


On Wed, May 27, 2015 at 3:21 PM, Ron Garret <ron at flownet.com> wrote:

>
> On May 27, 2015, at 5:14 AM, Krisztián Pintér <pinterkr at gmail.com> wrote:
>
> > by definition, entropy is anything the attacker does not know.
>
> No, entropy is anything about your own physical situation that *you* don’t
> know.  That may or may not be something your attacker also doesn’t know.
> This is the fundamental reason randomness is hard.  You want the second
> thing, but all you can guarantee is the first unless you have a *complete*
> model of the physical system generating your data (i.e. thermal or quantum
> noise, no tampering by the attacker, no side channels, etc. etc.)  And this
> is the fundamental problem with Enrada: just because you and I and Russell
> Leidich don’t know how to predict the behavior of a modern CPU doesn’t mean
> the NSA doesn’t.
>
> rg
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150528/6611697f/attachment.html>


More information about the cryptography mailing list