lkml.org 
[lkml]   [2011]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: random(4) driver questions
On 06/27/11 16:54, Ted Ts'o wrote:
> On Sat, Jun 25, 2011 at 01:51:07PM +0800, Sandy Harris wrote:
>> There was a paper some time back by a group of Israeli researchers
>> and looking at the Linux /dev/random driver, and claiming to find
>> it wanting in several ways. www.pinkas.net/PAPERS/gpr06.pdf
>>
>> To what extent have their objections been dealt with. If some
>> were considered bogus, is there documentation somewhere
>> explaining why?
>
> Suffice it to say the random generator has changed significantly since
> 2006. There is now a secondary pool, which uses catastrophic
> reseeding, etc.
>
>> One problem they pointed out is that there may be little
>> entropy available on a Linux-based router; no keyboard or
>> mouse, solid state storage so no disk entropy, and an
>> enemy might observe network activity, so network
>> interrupts give little or no useful entropy.
>
> Sure, but a Linux-based router shouldn't be doing crypto work. If it
> *is* and it is important crypto work, then it needs a hardware random
> number generator. There's no magic here.
>
> If you don't want to pay the cost of a random number generator, you
> can do things such as at installation time, bootstrapping the random
> number generator with some cryptographically secure randomness
> available by the installation system.
>
>> The only in-kernel solution I can think of would be
>> to add something in the system call interface to
>> make very system call throw timing information
>> into the pool. I very much doubt, though, that that
>> is a good idea. What do others think, and does
>> anyone have a better idea?
>
> It won't hurt (aside from wasting CPU time, assuming you don't add any
> entropy credits), but won't necessarily help, either.
>
>> What happens to /dev/random when it runs on
>> a virtual machine and all the things it relies on
>> for entropy get virtualised away?
>>
>> The server that the VM is hosted on will usually
>> have plenty of entropy, often a hardware RNG.
>> Is there an interface that makes that visible
>> from the VM? Perhaps a virtual "hardware"
>> RNG driven by /dev/urandom on the host?
>
> Yes, paravirtualizing the random number generator would be a big help.
> Probably what I would do is to periodically add entropy from the host
> OS to the guest OS, via some paravirt channel. This would add a new
> "catastrophic reseeding", and if the virtual guest can mix in some
> other unknown material, again that can only help.
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

If you don't have a hardware rnd, you can use an entropy daemon like
haveged (http://www.issihosts.com/haveged/)


\
 
 \ /
  Last update: 2011-06-28 07:03    [W:0.518 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site