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 <[email protected]> wrote: > On Tue, May 26, 2015 at 7:27 PM, Russell Leidich <[email protected]> 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 <[email protected]> >> 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. >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
