[dm-crypt] LUKS and backdoors
arno at wagner.name
Mon Oct 21 13:59:35 CEST 2013
On Mon, Oct 21, 2013 at 01:10:26PM +0200, octane indice wrote:
> En réponse à ".. ink .." <mhogomchungu at gmail.com> :
> > How the header is created and maintained seem to be the most
> > obvious place to put a backdoor as discussed in the linked article.
> > can the same be done with LUKS? can a propriety,closed
> > source application be able to create a LUKS header in a
> > way that will allow it to secretly put the master key
> > "between gaps" in a header in a way that will still make
> > the header fully functional and cryptsetup will be able to
> > open it without any complains?
> If you are an attacker and if you generate the key, you don't
> have to store this key anywhere. You just have to
> generate keys which are not random at all.
> This make me think to another problem:
> I use full disk encryption, and I choose to encrypt from the
> install boot disk of my distro, master key is generated and
> all data are copied to disk.
> But at this point, what is the quality of the random? We have
> everything predictible. no random seed because it's the
> same bootdisk for everyone, and all operations are
> the same from one installation to another (choose full
> install, tick box full disk encryption and so on).
> So the PRNG would be in the same state if I do the
> same installation?
Depends. Hardware contributes some Entropy. Every interaction
(keyboad, mouse) you have produces some entropy. Definitely
not the same stae, but if there is no user interaction and the
hardware is limited, it could be a very small set of possible
keys. To be sure, just type random stuff into a console
for for 10 seconds before generating your keys.
Incidentally, your SSH host keys will also be weak if there
is no interaction during installation. So better do that
random typing before packet installation starts.
Current paper on some of the effects of low-entropy keys:
> the fact is that every distro use the cryptsetup default
> which uses /dev/random (e.g. risk of band random)
The default is /dev/urandom. /dev/random is conservative
in what it gives out, /dev/urandom just gives you as many
bits as you want immediately. Seel also the mailing list
archives, this topic has been discussed sevral times before.
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
More information about the dm-crypt