scrub vs shred vs wipe

Which of these "secure deletion" utilities is best? I've typically used `shred -uvz` for all of my deletion needs, but now I'm worried that I've been doing it wrong. I didn't even know the other two utilities existed until I watched a talk today from 34CCC that mentioned them.

You can add an -n [number] option too, to add shred it over multiple rounds too: ex. shred -uvz -n 10 BeastialityScatDinnerParty.jpg

Here is a better alternative next time you want to destroy data permanently. Create a KeePass database and a VeraCrypt volume. Store the key to your VeraCrypt volume inside your KeePass database. When you are done, delete the key belonging to the encrypted volume and then delete the volume itself. There, it's gone forever.

>>4594 USE ENCRYPTION I really hope it's not the same guy who keeps posting this fuarrrking thread every few months.

Obligatory mention that shred doesn't work if you have an SSD.

>>4601 OP could possibly want to sell the HD to someone, even though had he encrypted the whole think up, he might be afraid. idk, I'am Also, I only know blancco erase, very good, but paid.

I just use `srm`. I don't think it makes much of a difference. Just check the man page and source and make sure it's doing what you want. >>4610 Use DBAN before selling it.

>>4610 >OP could possibly want to sell the HD to someone Dude is asking about shredding individual files. >even though had he encrypted the whole think up, he might be afraid. idk, I'am This paranoia is a reflection of your own incompetence, not any danger in the real world. >Also, I only know blancco erase, very good, but paid. You don't need a paid tool to write 0xff across a whole drive. https://linux.die.net/man/1/dd

>>4600 I've never used VeraCrypt. This might be a reason to test it out for once. Would it be a decent solution to use for something like a flash drive or external HDD? >>4601 I'm using LUKS for my primary OS drive, so that's all well and good. I was looking for something to use with, say, an external hard drive that I'm borrowing, or a flash drive or something. >>4612 DBAN is awesome and I use it regularly prior to decommissioning a machine.

>>4648 You want to know how to write sensitive data to permanent storage and then "delete" it again. You are never going to get a better answer than encrypt the file and throw away the key when you're done.

>>4594 shred seems to work fine for me 3 iterations of random writes (default) and and final pass of zeros destroys the data so bad I can't recover it with Testdisk/PhotoRec or even paid software like prosoft data recovery. shred kind of is like kicking dead whales down the beach for hardware RAID because you can tell which volumes were mirrored based on the "random" data being mirrored (although I cant see how this could help bring back the overwritten data). This is why I always zero the volumes after the wipe (-z). If anyone has any examples of being able to recover shreded disks I would love to hear examples of how you managed it.

>>4657 What do you use when you delete the key? It was suggested to store the key in a keepass database earlier, what do you use to delete the keepass database?

>>4665 >What do you use when you delete the key? The key is derived from a password you keep in your head. You don't literally "throw" anything away. It was metaphorical.

>>4665 Maybe just using full disk encryption and reinstalling the OS at set intervals may help with the keepass database persisting around.

>>4667 >The key is derived from a password you keep in your head. Symmetric encryption keys I mean. Public key encryption keys are stored as files on dick but they too can be protected by symmetric encryption. The tl;dr is that encryption is much more reliable than wiping tools, especially in this age of wear leveling and modern operating systems which will cache copies of files all over the place including swap. >>4675 This, use full disk encryption and stop worrying. If you need to use an unencrypted external drive then encrypt the file with something like gpg before copying it. And do it on an OS that either runs full disk encryption itself or is running without writable permanent storage (live system).

wait gosh people wait just a second. shred works on non journaled fulesystems. Depending on exactly the system you're running it on its not impossible that you're use of shred basically leaves the data intact and writes noise to another sector. A general solution is just to use FDE, where ideally thing will be safe anyway. And you can always simply erase the entire disk (or fill up all the freespace) to garuntee that there are not still files you think should be gone from it.

Whichever utility you use, ensure it writes to all unallocated space on the drive, and not only shreds files stored on it. However, even with that done, your contents could still be recoverable if the storage media is solid state - since the microcontroller decides what is written where, so it may be performing wear leveling, and other reliability algorithms. For example, you could purchase a 256Gb drive from a reliable manufacturer, that physically has 512Gb of storage because it is of slightly less than perfect quality, and the microcontroller (which allows you to only ever see 256Gb) makes up for the poorer quality media with it's error correction algorithms, copying your data to other areas whilst leaving your data written on blocks it marked as bad. So in essence - you could 'shred' your entire disk, but there remains up to 256Gb of ghost data (old data on areas the microcontroller will not allow you access to). Personally, I would never sell storage media once even encrypted business details have been written onto the drive.

>>4724 There were news of usb sticks with tampered firmware. USB stick has a hidden sector where files get copied to on a firmware level. This way you can't detect the hidden sector nor delete it in any form besides manually destroing the ship / replacing the firmware. So depending on the necessary security level i wouldn't just shred sticks for your company.

>>4725 Yes that's on the microcontroller, since the microcontroller acts as the gatekeeper. Unless you can confirm what it is doing consider it compromised and acting against your interests **you won't be far wrong anyway**.

>>4726 >Unless you can confirm what it is doing Afaik that's impossible. Read the modern stuff is just too small&multilevel to analyze. The guys who figured out the firmware hack just replaced the controller to read the real data out.

Does the secure erase command in hdparm actually force a solid state to clean slate?

>>4724 Encryption happens on the OS, before the data reaches any part of the drive including the microcontroller. 10/10 for paranoia 10/10 for ignorance

>>4759 >paranoia I heard that before the Snowden leaks.

>>4759 If you don't keep a separate header, it's useless, even more useless on flash storage.

>>4759 >Encryption happens on the OS Yes, 'encryption' does happen on a *compromised* OS. Even if your data is encrypted on the drive - it is still on the drive. You are relying on a) an attacker not being able to decrypt your data, rather than b) an attacker not having your data. b) is the only true solution.

>>4773 >Yes, 'encryption' does happen on a *compromised* OS. I don't know how to respond to this. Just to summarize, you pointed out that a malicious storage device can copy data to hidden locations which can't be erased. That's fair enough, 10/10 for paranoia. You then said this also somehow breaks encryption. No it doesn't because the data is encrypted before it is sent to the storage device 10/10 for ignorance. >You are relying on a) an attacker not being able to decrypt your data, rather than b) an attacker not having your data. b) is the only true solution. Relying on an attacker not being able to decrypt your data is literally the fuarrrking point of encryption.

>>4781 >you pointed out that a malicious storage device can copy data to hidden locations which can't be erased. That's fair enough, 10/10 for paranoia. You then said this also somehow breaks encryption. No, I did not say this breaks encryption. I said a compromised OS breaks encryption. 10/10 for jumping to the wrong conclusion. A compromised OS cannot be trusted to be encrypting your data. So if an OS that may not be encrypting your data is writing to a drive that is not wiping your data, then guess what? Your data is compromised. >Relying on an attacker not being able to decrypt your data is literally the fuarrrking point of encryption. Me: The attacker has the locked safe that belongs to Alice. The attacker does not have the safe that belongs to Bob. Bob's items are secure from ANY safe cracking attempts by the attacker. You: A safe is designed to keep things safe. 10/10 for missing the point

>>4783 >No, I did not say this breaks encryption. I said a compromised OS breaks encryption. You're doing it wrong. If you want to play the security nihilism game, your compromised OS wirelessly transmitted your sensitive data to the NSA van across the street the moment it was created. a) you lose b) you lose All you've done here is invented an inconsistent threat model.

>>4773 so, how do you actually prevent the attacker from getting your data? And if you fail, wouldn't you rather have your attacker *not* be able to just look at all your data willy-nilly? The point of encryption is, *if your attacker has your data it is still worthless to them without the passcode*. Encrypted data is strictly safer than hidden data.

>>4785 >The point of encryption is, *if your attacker has your data it is still worthless to them without the passcode*. Encrypted data is strictly safer than hidden data. He's saying that the encryption is backdoored because your OS is compromised. But for some reason the attacker is too incompetent to simply exfil the plaintext. Instead he watches you "encrypt" it and waits to get physical access to the drive and then uses the backdoor he inserted at encryption time to "decrypt" it. Because logic. >so, how do you actually prevent the attacker from getting your data? In this threat model you can't. He was just too stupid to realize that before posting.