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? [1]the fact is that every distro use the cryptsetup default which uses /dev/random (e.g. risk of band random) thanks Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
