1

Currently when I want to wipe a USB disk with pseudorandom data in Linux I do the following:

dd if=/dev/urandom of=/dev/sdb conv=notrunc

urandom is very, very slow, it gets to the point where the bottleneck is not the device.

I know of another method -- the Mersenne twister. This is used in one instance by DBAN as a PRNG to securely erase data with, and it is easily 'random' enough for wiping drives -- and it is very fast. However, I'm not sure how I would use it in Linux. Is there a Mersenne twister program which I can then pipe into dd to wipe drives with?

2
  • 1
    Just a comment. There is no documented case of data being recovered from a device after cleaning with it zeroes.
    – user39559
    Jan 28, 2011 at 14:37
  • I'm aware of that, but the point to be made is that technology is always advancing, so it may be possible to do so in the future. Jan 28, 2011 at 17:41

4 Answers 4

2

The wipe utility uses a Mersenne Twister PRNG for the random passes.

0
2

Why are you using DD to wipe drives? shred is designed specifically to do that and is common to all modern distros.

2
  • shred man page suggests it may not work well on modern file systems that don't necessarily write data in place unixhelp.ed.ac.uk/CGI/man-cgi?shred+1
    – LawrenceC
    Sep 24, 2013 at 21:51
  • Thats for file level wipes, not a drive level wipe - shred may not work when deleting files on journaled filed systems, but would efficiently delete the file systems themselves.
    – Journeyman Geek
    Sep 24, 2013 at 22:56
0

The Mersenne Twister is not cryptographically secure. After observing 624 outputs from the algorithm, it is possible to predict all past and future outputs. I suppose it's better than having all 0's and 1's in the sense that it will better mask the underlying magnetic signature, but that's less effective since your adversary will know the exact pattern that was written.

I'm no security expert, but I suppose my answer would be do NOT use the Mersenne Twister for this task due to that reason. But then again, it's all kind of a moot point, since writing the whole drive with anything will render its previous contents unrecoverable with current technology.

-1

mersenne twister has a ginormous periodicity that's very hard to even get a value for on a machine without using pari/GP. my understanding is that mt19937 (nmersenne twister) from #include <random> in c++ is more like http://www.cplusplus.com/reference/random/mersenne_twister_engine/ and http://www.cplusplus.com/reference/random/mt19937/

w=32 n=624 which states the periodicity (using ttcalc) is (2^((n-1)*w)-1)/32=(2^((624-1)*32)-1)/32=big huge huge number - cpu internals can't handle that size of a number without truncating it to some ridiculously small number. so let's find out the number of digits for that periodicity: ceil(log(abs((2^((624-1)*32)-1)/32)+1;10)/log(10;10)) = 6000 digits worth of number. even ttcalc only goes up to 99 digits. togiveyou an idea, 2^64=18,446,744,073,709,551,616 and is calculable with cpu instructions, but not even the IEEE754 FPU in your processor can handle this size of number. this is where you get into bignum math and number-theory calculators like pari/GP that can handle stuff to 10,000 digits easy - and print it too.

my understanding of /dev/urandom and /dev/random is that they are very poor for long runs like wiping disks and should not be used for steady streams of random numbers only for single-number-acquires like passwords and other crypto, etc.

for better performance on a disk wiping program, maybe nwipe or writing your own c++ utility would be a good idea that uses mt19937 (it's slow, but effective). you can truncate the 32 bits to just 8 or double your bandwidth by using 16 bits worth the 64-bit mt19937 should give you 32 bits worth (same - should write a bug report about the implementation problem in gcc). the upper bit is useless, I guess they figured everybody was going to use a signed number and never use negative numbers. the <random> c++ template library should accommodate both signed and unsigned data types, not just signed.

best thing would be to write a c++ program. I think wipe as an idea is flawed based on http://linux.die.net/man/1/shred and http://linux.die.net/man/4/urandom under Usage where it says "It is designed for security, not speed, and is poorly suited to generating large amounts of random data."

if the only thing you were worrying about was periodicity (distance between repeated patterns), I don't think this is a problem. cryptography is not one of my specialties, but

my understanding of the NIST wipe is you should do something like 8 or 15 passes of MT, to get the magnetic ghost images down to a minimum. the more the merrier of course, but probably with diminishing returns the more you do.

not sure what this kind of stress does to the drive. be carefulwhat usb dock you use, startech SATDOCKU3SEF was the only one I found with a nice and usable fan on it (crank up to max) should this be necessary.

also, I like parallelizing jobs to save time. just stickan & on the end of the command and do as many jobs as you have channels. it willuse 1 thread per job. if your server has 120 threads(4cpux30T), then you can have up to 120-1 jobs, leaving 1 for the system. tocheckon the jobs, use the jobs command,and ITHINK towait forthejobs todoashutdown orwhatever use the wait command. like wait ; shutdown -r 0

I am still trying to figure out how to make use of the foreach command with `ls /dev/disk/by-id there must be a bug in BASH because towipe everything from a livecd I should be able to wipe all disks with

I am developing a web page at http://JesusnJim.com/pc-repair/disks-int-ext/wiping-refreshing-drives-free-fast-and-in-PARALLEL.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .