[cryptography] Enranda: 4MB/s Userspace TRNG

Russell Leidich pkejjy at gmail.com
Wed May 27 02:51:35 EDT 2015


Hi Steve,

Yeah, the TSD bit probably should have been set from day one. But it
wasn't, so userspace TRNGs are possible. Nonetheless, TSD does not
constitute a threat to randomness: it would just result in a CPU privilege
violation, followed by shutdown of Enranda. Not good, but certainly not
ambiguous. And very rare in the wild.

SMIs only _help_ randomness by messing with timing (due to slow firmware
code). Yeah, another core might issue an SMI just to slow down Enranda. OK,
so it slows down. Entropy density is unaffected. The SMI handler might be
moronic and corrupt the TSC, but that's a firmware bug, not an Enranda bug.
Maybe I missed your point here?

As to Ptacek's article, I don't see any problem with /dev/urandom, but
having both /dev/urandom and a userspace TRNG is at least as secure
(assuming both are bugless). It also avoids dependency on Linux and/or
worrying about urandom implementation. And finally, one could implement a
userspace TRNG with no OS calls whatsoever (and certainly not /dev/
access), given only TSC access. In some regimes, that makes things a lot
easier to implement and minimally latent.

So it seems to me that a lot of security experts want to avoid userspace
TRNGs because they assume that there's somewhere else to go which is
actually safer (nevermind cross-OS), even though those places are all far
removed from the app developer and the relative security of the CPU die.
Sure, entropy from the PCI or USB bus is better than what the TSC has to
offer by way of bandwidth, and possibly unpredictability. But OTOH they are
more prone to wireless snooping and perhaps wireless influence. Personally,
I would prefer to stay close to the core and away from those busses,
especially the screeching serial lines beyond the southbridge. But a hybrid
of the two would be safest. We could throw in the CPU randomness registers
as well, when available.

At least, Enranda is an adjunct to other randomness sources for those who
don't trust any of them. If you don't like it, then at least, you are able
to modify it at will.

Russell Leidich


On Wed, May 27, 2015 at 3:28 AM, Steve Weis <steveweis at gmail.com> wrote:

> On Tue, May 26, 2015 at 7:27 PM, Russell Leidich <pkejjy at gmail.com> wrote:
>
>> Unfortunately, that page doesn't provide insights as to why that piece of
>> advice was issued.
>>
>> On Wed, May 27, 2015 at 2:11 AM, Naveen Nathan <naveen at lastninja.net>
>> wrote:
>>
>>> Avoid: userspace random number generators, havaged, prngd, egd,
>>> /dev/random.
>>> Source: https://gist.github.com/tqbf/be58d2d39690c3b366ad
>>
>>
> The author Thomas Ptacek has a longer post on why people should just use
> /dev/urandom:
> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
>
> Relying solely on the TSC seems like a bad idea because: 1) userspace
> access may be disabled for security purposes with the TSD bit 2) TSC
> measurements may be influenced by processes on other cores able to induce
> SMIs.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150527/973ce61b/attachment-0001.html>


More information about the cryptography mailing list