On Sat, Apr 18, 2009 at 10:09:59PM -0400, f-dm-c@xxxxxxxxxxxxx wrote: > > Date: Fri, 17 Apr 2009 16:49:14 +0200 > > From: Henrik Theiling <theiling@xxxxxxxxxx> > > > Hi! > > > Wolfgang Sailer writes: > > >... > > > But how to do it in the following situation: > > > When I enlarge a LUKS volume, say by expanding the RAID or enlarging the > > > logvol (LVM partition) that hosts the LUKS volume, how can I then fill the > > > additional space with random data before enlarging the LUKS volume? > > >... > > > Another simple way: enlarge the volume normally and then fill it up > > with dummy files (in the simplest case, use dd if=/dev/zero > > of=dummyfile) until it is absolutely full. Be root for this so no > > reserved space will be spared. (After than, you can simply remove the > > dummy files, of course.) > > I am not sure this would be a 100% solution, but it may be good > enough, depending on your threat model. The problem is that many > filesystems reserve certain blocks for FS metadata, and filling up > the "available" filesystem space might not touch more than a tiny > fraction of those blocks. You might have to create millions of files > to guarantee you've walked all over all the metadata, but exactly what > to do would be highly dependent upon internal details of the filesystem. Indeed. However I submit, that if you are that worried, it is better to either do a very careful raw overwrite of the new data area before adding it or, even better, fill a new disk with dandom data, and then move everythign over. Alternatively, make a backup of the encrypted partition, enlarge and fill and then recreate the filesystem. > It seems far safer, if you're going to do this, to create the crypto > mapping and then write to the crypto partition (not a filesystem > that's built on top of it) to randomize the device. -Then- you can > create a filesystem on top of the randomized partition. This is in fact the procedure I use to wipe drives: Do a cryptsetup with random key and then fill with zeros or weak randomness. I had to wipe about 60 drives in a cluster some time ago, and I found this by far to be the fastest way to do it, also significantly faster than using /dev/urandom directly. (Incidentially I have now drives I can prove that I cannot prove that they contain no data, i.e. I have provable deniability.) > P.S. If you have to worry that encrypting blocks of zeroes might > weaken the cipher, you have the wrong cipher. No reasonable cipher > is vulnerable to any sort of chosen-plaintext attack---and any such > cipher would be unsuitable even if you weren't only writing zeroes, > because many filesystems and many types of files have -very- > predictable contents in certain locations. I agree. There are some attacks with files that have embedded watermarks and can be recognuized from outside the encryption with weal IV schemes, but the same is not true for an encrypted zero overwrite. Also a random key for the zero overwrite does help. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
