linux-kernel - Re: [PATCH 07/10] random: add new get_random_bytes

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: <5010B86F.1080108@zytor.com>
Date:	Wed, 25 Jul 2012 20:24:31 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	torvalds@...ux-foundation.org, w@....eu, ewust@...ch.edu,
	zakir@...ch.edu, greg@...ah.com, mpm@...enic.com,
	nadiah@...ucsd.edu, jhalderm@...ch.edu, tglx@...utronix.de,
	davem@...emloft.net, DJ Johnston <dj.johnston@...el.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 07/10] random: add new get_random_bytes_arch() function

On 07/25/2012 08:16 PM, H. Peter Anvin wrote:
> On 07/25/2012 08:10 AM, Theodore Ts'o wrote:
>> Aside from whether it's better to do this step in
>> xfer_secondary_pool() or extract_entropy() ...
>
> By the way, I looked at doing this in xfer_secondary_pool()... the
> problem there is that xfer_secondary_pool() is called exactly once per
> invocation of extract_entropy() and so there is no way to make it inject
> the same amount of material as it consumes.
>
> One could put it in extract_entropy[_user]() and if you prefer I'll
> rewrite the patch to do that, however that code would look very similar
> to the one in extract_buf() -- pretty much the same code in the caller
> rather than the callee -- but would have the same downside with being
> processed on 10-byte chunks because the final buffer might be misaligned
> and/or partial.  It would mean just running it once rather than twice
> per output datum, but I actually expected you would prefer the
> additional mashing and security margin.
>

One final reason for this (although this would work in extract_buf() as 
well): the Bull Mountain internal buffer size is 16 bytes long.  This 
means that the interleaving of the buffer operation and the RDRAND pulls 
makes it quite likely that the output of RDRAND used will be 100% 
entropic, since the SHA-1 operations will typically take much longer 
than the RDRAND automatic reseed interval.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/