lkml.org 
[lkml]   [2016]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 0/5] /dev/random - a new approach
From
Date
On 08/15/16 22:45, Stephan Mueller wrote:
> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
>
> Hi H,
>
>> On 08/11/16 05:24, Stephan Mueller wrote:
>>> * prevent fast noise sources from dominating slow noise sources
>>>
>>> in case of /dev/random
>>
>> Can someone please explain if and why this is actually desirable, and if
>> this assessment has been passed to someone who has actual experience
>> with cryptography at the professional level?
>
> There are two motivations for that:
>
> - the current /dev/random is compliant to NTG.1 from AIS 20/31 which requires
> (in brief words) that entropy comes from auditible noise sources. Currently in
> my LRNG only RDRAND is a fast noise source which is not auditible (and it is
> designed to cause a VM exit making it even harder to assess it). To make the
> LRNG to comply with NTG.1, RDRAND can provide entropy but must not become the
> sole entropy provider which is the case now with that change.
>
> - the current /dev/random implementation follows the same concept with the
> exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later
> versions, this was changed.
>

I'm not saying it should be *sole*. I am questioning the value in
limiting it, as it seems to me that it could only ever produce a worse
result.

-hpa


\
 
 \ /
  Last update: 2016-09-17 09:57    [W:5.581 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site