Re: [dm-crypt] Random fill

[test532@codingninjas.org]

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@fancy-poultry.org> 
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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>