| 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
| ||
|
Message-ID: <sig.11608c07e8.4E095C34.1020904@containermaster-cmp.de> Date: Tue, 28 Jun 2011 06:44:36 +0200 From: Johann Meier <recv@...tainermaster-cmp.de> To: LKML <linux-kernel@...r.kernel.org> Subject: Re: 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@...r.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/) -- 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/
Powered by blists - more mailing lists