Re: [PATCH 07/10] random: add new get_random_bytes_arch() function

["H. Peter Anvin" <hpa@zytor.com>]

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.