| 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
| ||
|
Date: Sat, 25 Jun 2011 13:51:07 +0800 From: Sandy Harris <sandyinchina@...il.com> To: LKML <linux-kernel@...r.kernel.org> Subject: random(4) driver questions 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? 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. 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? 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? -- 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