[dm-crypt] Random fill

[dm-crypt] Random fill

[Stroker]

So, I estimate it will take 80 hours to fill my drives 
via: dd if=/dev/urandom of=/dev/sdb1

There seems to be mixed opinions regarding the use of 
frandom or erandom.

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

Perhaps change the key afterward, or even delete/rebuild 
the dm-crypt block?

Thanks,
Stroker

Re: [dm-crypt] Random fill

[Heinz Diehl]

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.

Re: [dm-crypt] Random fill

[Rick Moritz]

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.)

Re: [dm-crypt] Random fill

[Heinz Diehl]

At Sun, 30 Aug 2009 16:07:22 +0200,
Rick Moritz wrote:

> > 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.
 
> 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.

In my opinion, if the encryption is considered secure it doesn't mind if the attacker is
able to distinguish the ciphertext from the rest or not. The logical
consequence of this would be that "wiping" a disk by writing random data on it is
nothing but a complete waste of time.

http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

Re: [dm-crypt] Random fill

[Rick Moritz]

On Sun, 30 Aug 2009 16:28:57 +0200 Heinz Diehl <htd@fancy-poultry.org> wrote:

> At Sun, 30 Aug 2009 16:07:22 +0200,
> Rick Moritz wrote:
> 
> > > 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.
>  
> > 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.
> 
> In my opinion, if the encryption is considered secure it doesn't mind if the attacker is
> able to distinguish the ciphertext from the rest or not. The logical
> consequence of this would be that "wiping" a disk by writing random data on it is
> nothing but a complete waste of time.
> 
> http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

Of course, that holds, if we assume encryption to be secure. But that is a theoretical construct. Given time and ressources NO encryption is secure - therefore it is only reasonable to take any additional matters that enhance security. This is especially advised if the cost to gain ratio is reasonably high. Keeping the number of attack vectors low strengthens the implemtation of the cryptographic algorithm.
Additionally, if LUKS is not used this provides some degree of plausibal deniability. I maintain a disk-full of random data to do intrusion testing on network services.
\vOn the other hand, if you can mathematically/logically prove that dm-crypt + LUKS is secure, I will readily concede that you are correct. ;)

Re: [dm-crypt] Random fill

[Arno Wagner]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Sat, Aug 29, 2009 at 03:58:58PM -0400, Stroker wrote:
> So, I estimate it will take 80 hours to fill my drives 
> via: dd if=/dev/urandom of=/dev/sdb1
> 
> There seems to be mixed opinions regarding the use of 
> frandom or erandom.
> 
> My question is, wouldn't the following command fill my 
> drives with randommess?  Much more quickly than urandom?

Yes. /dev/urandom is not 100% entropy, but still 
cryptographically quite strong randomness, hence 
relatively slow. /dev/zero is of course no entropy 
at all.
 
> dd if=/dev/zero of=/dev/mapper/encrypted_sdb1
> 
> Perhaps change the key afterward, or even delete/rebuild 
> the dm-crypt block?

You can do it wit a random key and use a new one afterwards.

Personally, I use a small tool that outputs a stream of 
pseudo-radsomness generated by the mersenne twister initialized
from /dev/urandom and the final key on the device. This
is likely not information-theoretically secure, but in 
practice it adds about 600 bytes of entropy/state, which 
should make reversing it without the key infeasible.

I use this procedure with a random key to wipe HDDs as well.

Source attached for your convenience.

Arno 
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

[-- Attachment #2: mt_stream.c --]
[-- Type: text/x-csrc, Size: 7111 bytes --]

/* 
   A C-program for MT19937, with initialization improved 2002/1/26.
   Coded by Takuji Nishimura and Makoto Matsumoto.

   Before using, initialize the state by using init_genrand(seed)  
   or init_by_array(init_key, key_length).

   Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
   All rights reserved.                          

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

     1. Redistributions of source code must retain the above copyright
        notice, this list of conditions and the following disclaimer.

     2. Redistributions in binary form must reproduce the above copyright
        notice, this list of conditions and the following disclaimer in the
        documentation and/or other materials provided with the distribution.

     3. The names of its contributors may not be used to endorse or promote 
        products derived from this software without specific prior written 
        permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


   Any feedback is very welcome.
   http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
   email: m-mat @ math.sci.hiroshima-u.ac.jp (remove space)
*/

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

/* compile with gcc -O6 mt_stream mt_stream.c */

/* Period parameters */  
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL   /* constant vector a */
#define UPPER_MASK 0x80000000UL /* most significant w-r bits */
#define LOWER_MASK 0x7fffffffUL /* least significant r bits */

static unsigned long mt[N]; /* the array for the state vector  */
static int mti=N+1; /* mti==N+1 means mt[N] is not initialized */

/* initializes mt[N] with a seed */
void init_genrand(unsigned long s)
{
    mt[0]= s & 0xffffffffUL;
    for (mti=1; mti<N; mti++) {
        mt[mti] = 
	    (1812433253UL * (mt[mti-1] ^ (mt[mti-1] >> 30)) + mti); 
        /* See Knuth TAOCP Vol2. 3rd Ed. P.106 for multiplier. */
        /* In the previous versions, MSBs of the seed affect   */
        /* only MSBs of the array mt[].                        */
        /* 2002/01/09 modified by Makoto Matsumoto             */
        mt[mti] &= 0xffffffffUL;
        /* for >32 bit machines */
    }
}

/* initialize by an array with array-length */
/* init_key is the array for initializing keys */
/* key_length is its length */
/* slight change for C++, 2004/2/26 */
void init_by_array(unsigned long init_key[], int key_length)
{
    int i, j, k;
    init_genrand(19650218UL);
    i=1; j=0;
    k = (N>key_length ? N : key_length);
    for (; k; k--) {
        mt[i] = (mt[i] ^ ((mt[i-1] ^ (mt[i-1] >> 30)) * 1664525UL))
          + init_key[j] + j; /* non linear */
        mt[i] &= 0xffffffffUL; /* for WORDSIZE > 32 machines */
        i++; j++;
        if (i>=N) { mt[0] = mt[N-1]; i=1; }
        if (j>=key_length) j=0;
    }
    for (k=N-1; k; k--) {
        mt[i] = (mt[i] ^ ((mt[i-1] ^ (mt[i-1] >> 30)) * 1566083941UL))
          - i; /* non linear */
        mt[i] &= 0xffffffffUL; /* for WORDSIZE > 32 machines */
        i++;
        if (i>=N) { mt[0] = mt[N-1]; i=1; }
    }

    mt[0] = 0x80000000UL; /* MSB is 1; assuring non-zero initial array */ 
}

/* generates a random number on [0,0xffffffff]-interval */
unsigned long genrand_int32(void)
{
    unsigned long y;
    static unsigned long mag01[2]={0x0UL, MATRIX_A};
    /* mag01[x] = x * MATRIX_A  for x=0,1 */

    if (mti >= N) { /* generate N words at one time */
        int kk;

        if (mti == N+1)   /* if init_genrand() has not been called, */
            init_genrand(5489UL); /* a default initial seed is used */

        for (kk=0;kk<N-M;kk++) {
            y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
            mt[kk] = mt[kk+M] ^ (y >> 1) ^ mag01[y & 0x1UL];
        }
        for (;kk<N-1;kk++) {
            y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
            mt[kk] = mt[kk+(M-N)] ^ (y >> 1) ^ mag01[y & 0x1UL];
        }
        y = (mt[N-1]&UPPER_MASK)|(mt[0]&LOWER_MASK);
        mt[N-1] = mt[M-1] ^ (y >> 1) ^ mag01[y & 0x1UL];

        mti = 0;
    }
  
    y = mt[mti++];

    /* Tempering */
    y ^= (y >> 11);
    y ^= (y << 7) & 0x9d2c5680UL;
    y ^= (y << 15) & 0xefc60000UL;
    y ^= (y >> 18);

    return y;
}

/* generates a random number on [0,0x7fffffff]-interval */
long genrand_int31(void)
{
    return (long)(genrand_int32()>>1);
}

/* generates a random number on [0,1]-real-interval */
double genrand_real1(void)
{
    return genrand_int32()*(1.0/4294967295.0); 
    /* divided by 2^32-1 */ 
}

/* generates a random number on [0,1)-real-interval */
double genrand_real2(void)
{
    return genrand_int32()*(1.0/4294967296.0); 
    /* divided by 2^32 */
}

/* generates a random number on (0,1)-real-interval */
double genrand_real3(void)
{
    return (((double)genrand_int32()) + 0.5)*(1.0/4294967296.0); 
    /* divided by 2^32 */
}

/* generates a random number on [0,1) with 53-bit resolution*/
double genrand_res53(void) 
{ 
    unsigned long a=genrand_int32()>>5, b=genrand_int32()>>6; 
    return(a*67108864.0+b)*(1.0/9007199254740992.0); 
} 
/* These real versions are due to Isaku Wada, 2002/01/09 added */

const char* up = "\x1b[A"; //] 
const char* down = "\n";
const char* right = "\x1b[C"; //]

int main(void)
{
  // int i;
  //unsigned long init[4]={0x123, 0x234, 0x345, 0x456}, length=4;
  //init_by_array(init, length);
  
  // init from /dev/urandom
  long long count = 0;
  unsigned long init[624];
  unsigned long buf[10240];
  int i, j;
  unsigned long r;
  int in;
  ssize_t sret;
  int x, y;
  
  in = open("/dev/urandom", O_RDONLY);
  sret = read(in, init, 624 * sizeof(unsigned long));
  if (sret != 4 * 624) {
    fprintf(stderr,
            "Initialisation failed. Read only %d bytes.\n",
            sret);
    exit(1);
  }
  init_by_array(init, 624);
  
  // printf("100 outputs of genrand_int32()\n");
  while(1) {
    for (i=0; i < 2560; i++) {
      for (j = 0; j < 10240; j++) {
        buf[j] = genrand_int32();
      }
      write(STDOUT_FILENO, &r, sizeof(buf));
      //printf("%10lu ", r);
      //    if (i%5==4) printf("\n");
    }
    count++; // counts in 100MiB steps
    fprintf(stderr,"%10.1fGiB\n%s", count/10.0, up);
 }
  return 0;
}

Re: [dm-crypt] Random fill

[test532]

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
> 

Re: [dm-crypt] Random fill

[Heinz Diehl]

On 31.08.2009, test532@codingninjas.org wrote: 

> I agree with Rick that one should use /dev/urandom (instead of encryption) due 
> to the enabling of known plaintext attacks

Known plaintext attacks on what? On a bunch of zeroes?

After overwriting the whole partition using dmcrypt via /dev/zero, the
random key used will be deleted irrevocably, and the partition gets a brand new
setup of LUKS/dmcrypt, and it gets partially filled with "real" data. You haven't
even to use the same algorithm, hash or whatever. How should this lead to
a significantly better situation to attack the key/ciphertext?

Re: [dm-crypt] Random fill

[test532]

Because the point of filling with random data is to eliminate the possibility 
of being able to tell where real data is stored.

If the random data is cracked by using a known plaintext attack, then the 
benefit of having this random data is nullified.

Kerckhoff's principle should be called Kerckhoff's Ideal, as it is ideal, but 
doesn't mean that AES matches that ideal. If AES was guaranteed to meet that 
ideal, then there would be no point in pre-filling in with random data. Since 
we cannot be guaranteed that AES matches Kerckhoff's ideal, it is safer to 
eliminate as many avenues of attack as we can, as some of those avenues may be 
vulnerable ones for AES for all we know.

Sam

> On 31.08.2009, test532@codingninjas.org wrote:
> > I agree with Rick that one should use /dev/urandom (instead of
> > encryption) due to the enabling of known plaintext attacks
> 
> Known plaintext attacks on what? On a bunch of zeroes?
> 
> After overwriting the whole partition using dmcrypt via /dev/zero, the
> random key used will be deleted irrevocably, and the partition gets a brand
>  new setup of LUKS/dmcrypt, and it gets partially filled with "real" data.
>  You haven't even to use the same algorithm, hash or whatever. How should
>  this lead to a significantly better situation to attack the
>  key/ciphertext?
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Random fill

[Heinz Diehl]

At Mon, 31 Aug 2009 06:50:39 -0400,
test532@codingninjas.org wrote:

Thanks for your polite explaining so far!
 
> Because the point of filling with random data is to eliminate the possibility 
> of being able to tell where real data is stored.

Yes, that's clear.
 
> If the random data is cracked by using a known plaintext attack, then the 
> benefit of having this random data is nullified.

To crack the random data, the attacker must be able to distinguish them from
the "real" data. AS far as I know, if the key after a nullifiying action via
dmcrypt is wiped, the disk is filled with pseudorandom data and ciphertext
of the real data. For a known plaintext attack to work, one must have the
plaintext and the corresponding block of ciphertext resulting in encryting
this plaintext, but that is not possible in this scenario. No one can
distinguish between the real ciphertext (encrypted by a wholly different key)
and the filling with zeroes. 

The aim of a known plaintext attack is to find the key, but it has been
irrevocably wiped, and the real text is encrypted by a totally different key, in fact.

Sorry, but I can not see at all how a procedure which uses /dev/zero and
dmcrypt to fill a partition with pseudorandom data could weaken the whole
encryption / reduce the time for an attack on the real ciphertext at all.

Besides, AES is not vulnerable to known plaintext attacks, as far as I know.

Re: [dm-crypt] Random fill

[test532]

> At Mon, 31 Aug 2009 06:50:39 -0400,
> test532@codingninjas.org wrote:
> 
> Thanks for your polite explaining so far!
> 
> > Because the point of filling with random data is to eliminate the
> > possibility of being able to tell where real data is stored.
> 
> Yes, that's clear.
> 
> > If the random data is cracked by using a known plaintext attack, then the
> > benefit of having this random data is nullified.
> 
> To crack the random data, the attacker must be able to distinguish them
>  from the "real" data. AS far as I know, if the key after a nullifiying
>  action via dmcrypt is wiped, the disk is filled with pseudorandom data and
>  ciphertext of the real data. For a known plaintext attack to work, one
>  must have the plaintext and the corresponding block of ciphertext
>  resulting in encryting this plaintext, ...

The truth in what you say above does make it difficult, but the amount of 
difficulty depends on how full the drive is. On a mostly empty drive, the 
probability of guessing correctly where the plain text equals zeros is fairly 
high. The further from mostly empty the drive becomes, the less likely success 
becomes.

> but that is not possible in this
>  scenario. No one can distinguish between the real ciphertext (encrypted by
>  a wholly different key) and the filling with zeroes.

> 
> The aim of a known plaintext attack is to find the key, but it has been
> irrevocably wiped, and the real text is encrypted by a totally different
>  key, in fact.
> 
> Sorry, but I can not see at all how a procedure which uses /dev/zero and
> dmcrypt to fill a partition with pseudorandom data could weaken the whole
> encryption / reduce the time for an attack on the real ciphertext at all.
> 

> Besides, AES is not vulnerable to known plaintext attacks, as far as I
>  know.

As far as you or I know. But I can guarantee you that someone out there knows 
more and isn't saying. How much more? I don't want to bet my data on it.

My operating system as it is right now has no vulnerabilities in it that I 
know of. That doesn't mean that I am going to turn off SELinux on the machine, 
because I know there is at least a possibility of vulnerabilities, and that is 
enough reason to take any extra precautions that are reasonable.

Sam

> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Random fill

[Heinz Diehl]

At Mon, 31 Aug 2009 09:23:03 -0400,
test532@codingninjas.org wrote:

> The truth in what you say above does make it difficult, but the amount of 
> difficulty depends on how full the drive is. On a mostly empty drive, the 
> probability of guessing correctly where the plain text equals zeros is fairly 
> high. The further from mostly empty the drive becomes, the less likely success 
> becomes.

Ok, got the point.
 
> > Besides, AES is not vulnerable to known plaintext attacks, as far as I
> >  know.
 
> As far as you or I know. But I can guarantee you that someone out there knows 
> more and isn't saying. How much more? I don't want to bet my data on it.

Yes, one head can not contain all wisdom. There's certainly folks out there
which knows more. 

Thank you for the discussion!
 

Re: [dm-crypt] Random fill

[Roscoe]

On Sun, Aug 30, 2009 at 5:58 AM, Stroker<dmcryptmailman@strokerville.com> wrote:
> So, I estimate it will take 80 hours to fill my drives
> via: dd if=/dev/urandom of=/dev/sdb1

Yip, that's definitely too long for me to wait.

> There seems to be mixed opinions regarding the use of
> frandom or erandom.
>
> 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
>
> Perhaps change the key afterward, or even delete/rebuild
> the dm-crypt block?

That's how I do things.  If the cipher you're using is vulnerable to
known plaintext attacks then you have fair bigger issues than someone
being able to guestimate how much encrypted data you might have.

-- Roscoe