lkml.org 
[lkml]   [2012]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-07-26 06:01    [W:0.111 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site