Re: cryptsetup problem
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
Reply to: