Re: use of RDRAND in $random_library
On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
> I've never seen a convincing argument that the kernel /dev/random is
> likely to be *less* secure than the hardware random number generator.
> It's either more secure or the same level of security. Given that, it's a
> risk analysis, and the fact that we have absolutely no idea what the
> hardware random number generator is doing, it would be quite possible to
> insert a mathematical back door into it, and there's no way to audit it, I
> understand why people want to put a software randomization layer that we
> *can* audit in front of it.
One thing to worry about is what happens if the software library (if
it is implemented as a shared library) gets modified by a bad guy.
One thing a really paranoid program can do is to mix (via XOR, for
example) the output that it gets from /dev/urandom or this
cryptorandom shared library with RDRAND.
That way, if Unit 61398 tries to hack the cryptrandom shared library,
there's a fail safe (assuming they haven't hacked Intel's internal
systems to introduce a back door --- if anyone has done that it's much
more likely to be the NSA :-) since the PRC presumably wouldn't be
able to hack RDRAND.
The reason why /dev/urandom combines RDRAND with other sources of
entropy is something that is something that userspace programs can do
as well, especially if it's as easy to do as grabbing entropy from
RDRAND if it happens to be available. Even if /dev/urandom is
bug-free(tm), I can't guarantee that the bad guy hasn't hacked your
kernel --- or worse, hacked whoever is building and uplodaing the
kernel .deb's to the upload queue (or hacked someone on the ftpmaster
team --- remember, the NSA hunts sysadmins :-).
- Ted
Reply to: