I agree with Rick that one should use /dev/urandom (instead of encryption) due to the enabling of known plaintext attacks as Rick points out otherwise. The cost of taking more time is worth it and only paid once for the lifetime of the drive. But yes, using the 'following command' you describe will be many multiple times faster. I found on all my machines that urandom only is able to do 2-3 megs/sec (per core), whereas dmcrypt is able to encrypt at a high percentage to the full speed of the drive (60-100 megs/sec). I write to point out something else though, something that may not be obvious when using the urandom method. If you have a multiple core CPU, then you can divide the time required by the amount of cpus you have by breaking up the work into equal sized chunks and doing them in parallel, since by using urandom the bottleneck is your cpu, not the disk. It appears that the urandom code benefits from being called by mutiple CPUs -- and yes, I have tested this, as it is how I do it, and I get twice the rate of fill (I have only 2 core machines) than if I do only one urandom to fill the whole disk. I can only assume that this holds true for more than 2 cores also, as it is truly twice as fast this way with 2 cores, not just a little faster. Just use seek parameter on dd. Make one process of dd start at beginning, make the other start in middle, and run them both at the same time. Also, I recommend dd_rescue instead of dd, as I find dd gets slower and slower as it goes (obviously leaks something as it runs for extended times) while dd_rescue works great. Also with dd_rescue, you can and should use the -D flag which causes it to use O_DIRECT when writing in order to prevent it from filling your write buffer with this random output. This allows you to use your system without its speed being affected much by the random filling process. Also, for optimal results: Make sure to use a large block size (a few megs works optimal for me, maybe bigger if your drives are faster). This prevents the drive from having to seek often due to writing to multiple spots on the disk at once. Regards, Sam > On Sun, 30 Aug 2009 14:07:27 +0200 Heinz Diehl <htd@xxxxxxxxxxxxxxxxx> wrote: > > At Sat, 29 Aug 2009 15:58:58 -0400, > > > > Stroker wrote: > > > My question is, wouldn't the following command fill my > > > drives with randommess? Much more quickly than urandom? > > > > > > dd if=/dev/zero of=/dev/mapper/encrypted_sdb1 > > > > Yes, with pseudorandomness just like urandom, as far as I know. > > > > > Perhaps change the key afterward, or even delete/rebuild > > > the dm-crypt block? > > > > You can overwrite the LUKS header multiple times and set up a new one. > > > > Btw: why do you want to overwrite the entire partition? In my eyes, this > > is some kind of rocket science and makes no sense, considering > > Kerckhoff's law. > > I somewhat disagree: > > It is useful to create random data on the partition in order to hide which > sectors contain encrypted data and which don't - this makes attacks much > harder. Also, if you use a known algorithm with only a tiny random seed > (the key) to fill the disk, this may be reasonable attacked (after all, > you've got gigabytes of known plaintext: /dev/zero..) and therefore the > "background noise effect" introduced by randomly filling the disk is > quickly negated. urandom should routinely recheck the kernels entropy pool > for new seeds for its pseudorandomness - therefore providing MUCH better > randomness than just using encryption. > > 80 hours is completely acceptable for filling up a disk - I recall waiting > almost 14 days for my partition to be "initialized". Once it's been done, > you don't need to bother with it anymore for the lifetime of the disk. (If > you keep using it with full disk encryption.) > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
