Fastest way to fill 2TB /dev/sdxx with random data?

[charlweed]

If this post is correct
h t t p://help.ubuntu.com/community/EncryptedFilesystemLVMHowto

I can expect that it will take more then 16 days to fill my 2TB partition from /dev/urandom. That's not workable for me. dd if=/dev/urandom of=/dev/sdxx has been running for 36 hours, and I need to finish setting up the filesystem. But I also need to make a "professional effort" at encrypting the partition. I am supposed to fill the partition with random data, to strengthen the encryption for a LUKS partition. It seems that if the bad guys get the drive, they have much more time to try and crack it, then I have to encrypt it.

Ok, so I can try

sudo /sbin/badblocks -c 10240 -s -w -t random -v /dev/sdxx

How long can I expect badblocks to run on a 2TB partition?.

Thanks !

[hans51]

different solutions with different security levels
linux - How do I erase my disk? (In a secure way) (Ubuntu) - Stack Overflow
how long entirely depends on your HW /SW combination (write speed) !!!

[charlweed]

Well the good news is that

 dd if=/dev/urandom of=/dev/sdxx

Only took , 479732 seconds.
That's 5 Days, 13 Hours, 15 Min and 32 Seconds.
Better than 16 days.

[Irithori]

I found this, and I know it is capable of multiple hundreds of megabyte/s (ok, on a rather IO strong system)

The entropy gets "stretched" and probably the blocks are written in defined steps.
(I just came back from a medieval festival and so I am flat out too drunk to judge that now

Bottom line is, there is a slim chance, that it does not stand against a *really* deep forensic analysis.

And while I think of it, be sure to encrypt each disk with that and not an raidvolume on top of them.
(the raid will then be encrypted and used by luks.)

dd bs=1M if=/dev/zero |
   openssl enc -rc4 \
   -K $(dd bs=1 count=16 if=/dev/random | hexdump -e '8/4 "%08x"') \
   -iv 00 -bufsize 65536 |
   (dd bs=1 count=65536 of=/dev/null &&
    sudo dd ibs=65536 obs=1M of=/dev/sdX)

This overwrites sdX with an RC4 stream.
It is significantly faster than using /dev/urandom (on Linux), and uses less entropy,
while usually serving the same purpose (for instance, to initialize a block device for use with a crypto layer).

The key is generated randomly (from /dev/random with an entropy of 128 bits), the first 64KiB of the output
stream are discarded to work around the problem of RC4 leaking some of the key in the beginning of the output.