On Mon, Oct 21, 2013 at 01:10:26PM +0200, octane indice wrote: > En réponse à ".. ink .." <mhogomchungu@xxxxxxxxx> : > > 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[1]? 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: https://factorable.net/paper.html > [1]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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
