On Sun, 08 Jun 2014, Andrew McGlashan wrote: > > saying that neither regular /dev/urandom nor /dev/random > > are safe (& suggesting an attack against AES-128 CTR mode > > could succeed in only 2^64 attempts). > > > > This is a 2013 paper :( > > Interesting, but I can't say that I fully understand it -- most of it is > way beyond my knowledge.
I haven't read the paper yet, but there were important changes made to the Linux random subsystem in the 2013-2014 time frame. It is really good at making papers about it get obsolete, fast. > It seems that a /true/ hardware RNG that isn't pseudo is required, > anything less is subject to some kind of attack. /dev/random is approximately a CPRNG that is always reseeded, it has the properties of a variable-quality true RNG as long as at least one of its inputs have real randomness (and they do on personal computers like desktops and laptops). The problem is that its *quality* can be really bad right after boot, before Debian has a chance to seed it with data from the previous boot [requires RW media, and it is a large problem at the first boot and for read-only systems, both of which hit the Debian installer *hard*!]. /dev/urandom has the same properties as /dev/random as long as the system is not low on entropy. It can be considered a periodically reseeded CPRNG with a really small period. The low quality (low randomness) of the output of the kernel random subsystem at eatly boot has been addressed on the latest stable and long-term kernels [this includes the Debian kernel], but the effectiveness of the measures to ensure better entropy/randomness at boot depend on the hardware available to the kernel at early boot, and on the variance of several hardware events. Here, the Intel CDRNG, as well as VIA's PadLock TRNG and the old Intel FWH TRNG (the later two are analog designs), are really useful. Anyway, make sure you monkey around a lot with the keyboard and mouse before you let the Debian installer generate any encrypted filesystems on a system without a kernel-supported TRNG/HRNG/DRNG. Or get a large file of random numbers over the network and cat it into /dev/random (i.e. write to it as root) using the Installer's console, before you tell it to generate any crypto keys/encripted filesystems. > Given the 2013 paper, I would have to say that it is very likely that > this would have been followed up upon, but I can't find a reference. You could try searching for someone mentioning the paper on the Linux Kernel mailinglist (LKML), I guess. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140607234840.ga20...@khazad-dum.debian.net
