lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53C80A6D.5010201@zytor.com>
Date:	Thu, 17 Jul 2014 10:39:57 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>
CC:	linux-crypto@...r.kernel.org
Subject: Re: [PATCH] random: limit the contribution of the hw rng to at most
 half

On 07/17/2014 03:03 AM, Theodore Ts'o wrote:
> For people who don't trust a hardware RNG which can not be audited,
> the changes to add support for RDSEED can be troubling since 97% or
> more of the entropy will be contributed from the in-CPU hardware RNG.
> 
> We now have a in-kernel khwrngd, so for those people who do want to
> implicitly trust the CPU-based system, we could create an arch-rng
> hw_random driver, and allow khwrng refill the entropy pool.  This
> allows system administrator whether or not they trust the CPU (I
> assume the NSA will trust RDRAND/RDSEED implicitly :-), and if so,
> what level of entropy derating they want to use.
> 
> The reason why this is a really good idea is that if different people
> use different levels of entropy derating, it will make it much more
> difficult to design a backdoor'ed hwrng that can be generally
> exploited in terms of the output of /dev/random when different attack
> targets are using differing levels of entropy derating.
> 
> Signed-off-by: Theodore Ts'o <tytso@....edu>

I saw exactly one complaint to that nature, but that was from someone
who really wanted the "nordrand" option (at which point I observed that
it had inadvertently left RDSEED enabled which quickly got rectified.)
The implication was that this was a request from a specific customer who
presumably have their own "audited" hardware RNG.

There may have been other complaints (justified or not) but if so I
haven't seen them.  I'm wondering if we are overgeneralizing here and if
so if it wouldn't be better to defer this until the hwrng supplier for
this is ready, which probably won't happen in time for 3.17 just given
the current timeline.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ