(Somewhat) cryptographically secure erasing data from a disk array

causasui · 2019-04-29 15:56:12

I have an old array of disks in software RAID 5 on /dev/md0. I want to erase all the data from the disks before I give them away. I did this:

# openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/md0

The idea here is to generate a key using some data from /dev/urandom and use that key to generate a stream of aes-256 encrypted data, which should be faster than just reading /dev/urandom directly (albeit CPU intensive).
I let this command run overnight and was met with this error in the morning:

error writing output file

/dev/md0 no longer has any partitions (good) and can't be mounted in the usual way. What I am curious about is how I can know that the entire disk has really been wiped -- preferably without running photorec and actually recovering data from it since I don't have anywhere to store any data it might recover...

Any suggestions?

schard · 2019-04-29 16:05:34

Just use shred on the array?

Slithery · 2019-04-29 16:13:13

There's no need for all of that random nonsense, one pass of 0's is enough.

causasui · 2019-04-29 16:45:05

Slithery wrote:

There's no need for all of that random nonsense, one pass of 0's is enough.

So what, this?

# cat /dev/zero > /dev/md0

loqs · 2019-04-29 17:09:48

I would suggest erasing each of the devices that make up the array rather than the assembled array.

Slithery · 2019-04-29 17:20:41

I'd write to each of the underlying devices rather than the raid, something like...

dcfldd if=/dev/zero of=/dev/sda of=/dev/sdb of=/dev/sdc...

causasui · 2019-04-29 17:20:53

loqs wrote:

I would suggest erasing each of the devices that make up the array rather than the assembled array.

Good point, I guess my way will be slower (and maybe more stressful on the disks) since it's calculating parity as it goes along.

frostschutz · 2019-04-29 17:43:25

causasui wrote:

which should be faster than just reading /dev/urandom directly

the speed of /dev/urandom is vastly improved since... uh, 1-2 years ago?

roughly ~250M/s on my not-so-new haswell box. used to be 10M/s

causasui wrote:

what I am curious about is how I can know that the entire disk has really been wiped

downside of random data is that it's impossible to run a verification pass afterwards, so what I like to do is use cryptsetup

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/device crypterasedevice
dd status=progress bs=1M if=/dev/zero of=/dev/mapper/crypterasedevice
dd status=progress bs=1M if=/dev/mapper/crypterasedevice | cmp /dev/zero -

something like that. write zeroes (encrypted to random data), read random data (decrypted to zeroes) and compare.

( --- you could do the same with your openssl command, if you make it deterministic and re-use the same key generator --- )

then you have overwritten data and verified it's really been overwritten.

you can do that for each drive individually, not going through the RAID layer at all.

(on one hand you have to generate more random data, on the other hand it gets rid of metadata updates and synchronisation issues, so it should still be faster than raid)

one pass of 0's is enough.

random data is better, as it gives guarantees that zeroes cannot give

random data has to be stored by the device, zeroes can be compressed to the point of nothingness

Last edited by frostschutz (2019-04-29 17:55:54)

Trilby · 2019-04-29 18:33:20

frostschutz wrote:

zeroes can be compressed to the point of nothingness

By what process? This may be a feature of some filesystem, but if you write zeros to the device, it writes zeros to the device: there is no filesystem and no compression logic involved.

frostschutz · 2019-04-29 18:42:49

Trilby wrote:

if you write zeros to the device, it writes zeros to the device

sure, it should be true -- for now, for HDDs... some SSDs out there do use compression, and there's a general trend towards smarter storage media

but then random data doesn't cost anything and writing it out is not any way slower than zeroes

so there's no point in defending the use of zeroes

one practical example where zeroes vs. random data matters is in determining whether the SD card you bought is fake or not. with zeroes it's impossible to detect, with random data you can verify it

if you're a bit paranoid about "cryptographically secure erasing data" then random data all the way and a verification pass afterwards. then you know it was really overwritten, with zeroes... it can be anything *shrug*

blkdiscard /dev/ssd also gives all zeroes, did the ssd delete the stuff? well, probably. but who knows for sure?

Last edited by frostschutz (2019-04-29 18:45:51)

causasui · 2019-05-01 20:27:55

What about sending the ATA secure erase command via hdparm? https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

loqs · 2019-05-01 20:36:41

See https://csrc.nist.gov/publications/deta … ev-1/final page 33 Notes.

Lone_Wolf · 2019-05-02 11:31:05

You could also try https://www.killdisk.com/eraser.html .

While it may seem like a windows app, their console boot disk uses linux.
I own one license for Active@ KillDisk and can verify i'm unable to recover anything erased with that.

Arch Linux

#1 2019-04-29 15:56:12

(Somewhat) cryptographically secure erasing data from a disk array

#2 2019-04-29 16:05:34

Re: (Somewhat) cryptographically secure erasing data from a disk array

#3 2019-04-29 16:13:13

Re: (Somewhat) cryptographically secure erasing data from a disk array

#4 2019-04-29 16:45:05

Re: (Somewhat) cryptographically secure erasing data from a disk array

#5 2019-04-29 17:09:48

Re: (Somewhat) cryptographically secure erasing data from a disk array

#6 2019-04-29 17:20:41

Re: (Somewhat) cryptographically secure erasing data from a disk array

#7 2019-04-29 17:20:53

Re: (Somewhat) cryptographically secure erasing data from a disk array

#8 2019-04-29 17:43:25

Re: (Somewhat) cryptographically secure erasing data from a disk array

#9 2019-04-29 18:33:20

Re: (Somewhat) cryptographically secure erasing data from a disk array

#10 2019-04-29 18:42:49

Re: (Somewhat) cryptographically secure erasing data from a disk array

#11 2019-05-01 20:27:55

Re: (Somewhat) cryptographically secure erasing data from a disk array

#12 2019-05-01 20:36:41

Re: (Somewhat) cryptographically secure erasing data from a disk array

#13 2019-05-02 11:31:05

Re: (Somewhat) cryptographically secure erasing data from a disk array

Board footer