How to delete file(s) in secure manner?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Is there a way to make sure that a deleted file can not be recovered?
As you know, deleting a file by pressing shift-del or using trash doesn't mean that file is gone forever. It resides somewhere in the computer.
In day to day life, law enforcement or thieves use recovery programs to reveal our private data or something else.
They can recover all data that resides on hard disk, in RAM, and even USB.
To protect us from these people, what should one do? Which program should one use?
Note: I don't want an answer like first use a recovery program then erase that file with shred. With just one program, I want to erase all unused/deleted files on my computer.
security
add a comment |
Is there a way to make sure that a deleted file can not be recovered?
As you know, deleting a file by pressing shift-del or using trash doesn't mean that file is gone forever. It resides somewhere in the computer.
In day to day life, law enforcement or thieves use recovery programs to reveal our private data or something else.
They can recover all data that resides on hard disk, in RAM, and even USB.
To protect us from these people, what should one do? Which program should one use?
Note: I don't want an answer like first use a recovery program then erase that file with shred. With just one program, I want to erase all unused/deleted files on my computer.
security
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35
add a comment |
Is there a way to make sure that a deleted file can not be recovered?
As you know, deleting a file by pressing shift-del or using trash doesn't mean that file is gone forever. It resides somewhere in the computer.
In day to day life, law enforcement or thieves use recovery programs to reveal our private data or something else.
They can recover all data that resides on hard disk, in RAM, and even USB.
To protect us from these people, what should one do? Which program should one use?
Note: I don't want an answer like first use a recovery program then erase that file with shred. With just one program, I want to erase all unused/deleted files on my computer.
security
Is there a way to make sure that a deleted file can not be recovered?
As you know, deleting a file by pressing shift-del or using trash doesn't mean that file is gone forever. It resides somewhere in the computer.
In day to day life, law enforcement or thieves use recovery programs to reveal our private data or something else.
They can recover all data that resides on hard disk, in RAM, and even USB.
To protect us from these people, what should one do? Which program should one use?
Note: I don't want an answer like first use a recovery program then erase that file with shred. With just one program, I want to erase all unused/deleted files on my computer.
security
security
edited May 22 '14 at 22:39
Braiam
52.7k20138224
52.7k20138224
asked Aug 18 '11 at 8:22
user20296
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35
add a comment |
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35
add a comment |
11 Answers
11
active
oldest
votes
Shred
This command line tool is already installed from the core utilities in Ubuntu to securely erase and overwrite single files using the Gutman method.
Fast shredding
shred -vzn 0 /dev/sdc1
erases whole partitions by overwriting everything with 0
s in a single iteration. If no legal aspects require another procedure, doing so is most probably safe to securely delete your private data Craig Wright Lecture Notes in Computer Science, 2008, 5352, 243-257.
Secure shredding
shred -vzn 3 /dev/sdc1
erases the whole partition using 3 iterations with random numbers. In addition (option -z
) this writes zeros to hide the shredding process at the end. This will take 4 times longer than the fast method.
NOTE: By shredding a partition we will overwrite this partition with 0
or random numbers. It therefore efficiently deletes everything including file system caches on that partition forever. This can also be used to remove unwanted remnants of deleted files. Files we want to keep will have to be backed up before shredding.
Wipe
More options, and the possibility of erasing directories in addition to single files, are offered by this command line utility.
wipe filename
wipe -r dirname
Additional notes on journaling file systems and SSDs:
Please read the notes in the linked manpages on security issues arising from still recoverable backups in journaling file systems when erasing single files. Overwriting whole partitions rather than single files will effectively erase all data even when using a journaling file system.
Erasing data on a solid state disk (SSD) can if at all only be done by overwriting the whole drive (not only single partitions) with several iterations. Some SSDs may have an inbuilt feature to erase data but this may not always be efficient (see this link from comment). At present there is no general recommendation on the wiping processes or number of erase iterations needed to securely remove all data remnants on all SSDs available.
These options can be added in the context menu of Nautilus and Thunar.
- In Thunar, open "Edit" then "Configure Custom Actions"
Add (the plus sign)
Name "Shred File"
Description whatever you like
Action "shred -u %f"
Similarly for wipe
.
- For Nautilus see this question and those related
Select "Appearance Conditions" and select "Other Files"
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
|
show 12 more comments
There isn't one command that you can run which will easily clean up all the already-deleted files for you. However, there are a number of things you can do to reduce your vulnerability to this sort of attack in future.
As others have said, using tools like shred or srm allows you to delete a specific file by actually overwriting it, rather than just removing it from the filesystem. If you're feeling bold, you can replace the rm
command with shred
or srm
to securely delete files going forward. That means that whenever you (or another program) tries to delete something using rm
, the secure delete command will run instead.
However, if you're using a solid state disk, or even some newer mechanical disks, shred and other overwriting-based methods may not be effective, since the disk may not actually write where you think it's writing (source).
Full-Disk Encryption
A more convenient option is full-disk encryption. If you use the alternate installer, Ubuntu can automatically set up a fully-encrypted disk for you you, but you can also customize and configure the settings yourself. Once installed, the encryption is almost invisible to you: after you enter the passphrase (be sure to pick a good, long one) when the computer starts up, everything looks and feels just like normal Ubuntu.
You can also encrypt external media like USB drives using Ubuntu's Disk Utility. Setting up an encrypted external disk is as simple as checking the "encrypt underlying filesystem" box when formatting the disk. You can even store the passphrase on your (encrypted) keyring, so that you don't need to enter the phrase every time you plug that disk into your computer.
If your whole disk -- and all your removable media -- is encrypted, there's much less to worry about. A thief or police officer would need to swipe your computer while it's on, (or within a minute or two of turning it off if they're very good) in order to access your data. If you hibernate (rather than suspend) your computer when it's not in use, then you should be pretty safe.
If you ever need to completely destroy all your data, you don't need to do a Gutmann wipe of your whole disk. Simply overwrite the very beginning of the disk, to destroy the headers for the encrypted volume. Unlike with a regular filesystem, this will actually make it impossible to recover the data.
So, how do you go from your current setup to a safely encrypted disk? It's quite a challenge to retrofit a currently-installed operating system to use an encrypted disk. The easiest approach is to backup all your data and settings, then reinstall with an encrypted disk. When backing up, make sure to back up your data to an encrypted external drive, but don't save the passphrase in your keyring.
After you've backed everything up, you may want to aggressively wipe your hard drive, to make sure that none of your existing data can be recovered in the future. If you're using an SSD, the process is even more challenging, so depending how much you want to invest in the process, it might be worth destroying your current disk (a challenging proposition) and starting with a new one.
When reinstalling the OS, if you haven't aggressively wiped the disk already, you should make sure to completely fill the new encrypted partition, which will overwrite all your old data. Once you've restored your backup, you may want to aggressively wipe the start of the backup disk, to destroy the encryption header, so that it can't be recovered again.
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
add a comment |
Update: If you have not yet deleted the file that you want to be non-recoverable, use the accepted answer. If, however, you already deleted the file[s], then this is the next best method that I know of.
If I read you right, you want to erase all your previously deleted files. Here is a simple way to do that:
$ dd if=/dev/zero of=/path/to/mounted/partition/tmp_file bs=1M count=999999999999
Let that run till it complains till it gets a disk write error [out of space]. Then delete the file! What this does is just fill up your empty disk with 000s, so all your previous files get overwritten. Make sure to delete the file now, or you will not have any disk left. You might want to do this a few times if you are really paranoid. Or if you want to write random to your disk, I'd suggest replace /dev/zero
with /dev/urandom
.
However, this will take much much longer, so I'd run it overnight. Also, if you want a progress meter, do this instead:
$ free=$( df {PARTITION OR MOUNTPOINT} |awk '{print $3}'|tail -1 )
$ dd if=/dev/zero bs=1M count=999999999999 | pv -s "$free" > /path/to/mounted/partition/tmp_file
First you are getting your free disk space with du, awk, and tail, then using dd to get /dev/zero, piping that to pv
which stands for "pipe viewer", that redirects everything to tmp_file
Once again, delete the file afterwards. $ rm tmp_file
Anyway, hope someone finds this useful! :)
1
Is there a command-line utility that does this for you? Say,overwrite_empty_space /dev/sdb1
?
– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
add a comment |
First, delete files with rm on the terminal or with shift-delete on nautilus.
Better yet, use srm
, from the Secure-Delete tools package.
You can install the secure delete tools like this:
apt-get install secure-delete
Second, use sfill to wipe out unused space on your disk:
sudo sfill -f <directory>
This will take some time, since it is using crypto techniques to fill out the disk.
Warning: this is going through your whole filesystem, and you are root. Use with care!
This will create a file which wipes out all previously existing data. The file will be created in <directory>
.
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
add a comment |
A GUI program for this is BleachBit (it's also in the sources). More recent (deb file) version at the BleachBit Sourceforge page.
Beyond simply deleting files, it includes advanced features such as shredding files to prevent recovery, wiping free disk space to hide traces of files deleted by other applications.
"BleachBit quickly frees disk space and tirelessly guards your privacy.
Free cache, delete cookies, clear Internet history, shred temporary
files, delete logs, and discard junk you didn't know was there.
Designed for Linux and Windows systems, it wipes clean 90 applications
including Firefox (vacuuming to make it faster), Internet Explorer,
Adobe Flash, Google Chrome, Opera, Safari and more." (from http://bleachbit.sourceforge.net/)
BleachBit has several advanced cleaners:
- Clear the memory and swap on Linux
- Delete broken shortcuts on Linux
- Delete the Firefox URL history without deleting the whole file—with optional shredding
- Find widely-scatted junk such as Thumbs.db and .DS_Store files.
- Delete the OpenOffice.org recent documents list without deleting the whole Common.xcu file
- Overwrite free disk space to hide previously files
- Vacuum Firefox, Google Chrome, Liferea, Thunderbird, and Yum databases: shrink files without removing data to save space and improve speed
- Surgically remove private information from .ini and JSON configuration files with deleting the whole file
For details on how to use Bleachbit to delete securely specific files and folders
see this answer.
add a comment |
If you want a solution which can't be thwarted by a pathologically obsessed individual then you should consider some combination (limited by monetary resources) of:
- degaussing -- magnetically erasing the hard drive
- physically disabling the hard drive -- i.e. industrial hole punch
- acid bath <-- you can't get bits from a pile of goo.
These solutions range drastically in cost & ingenuity. A few:
- http://www.semshred.com/hard_drive_crusher
- http://www.edrsolutions.com/solution.asp
- http://www.doc-res.com/hard-drive-destruction.shtm
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
add a comment |
I would say the the solution is a combination of several answers given here. For already-deleted files and partitions still in use, I agree with Matt.
Then, for the future I would suggest to start using secure-delete tools instead of simple 'rm'.
Last, when it will be possible to reformat the partition, the option of encrypt the partition should be considered. Perhaps using some approach that offers Plausible deniability like in Truecrypt
add a comment |
For SSDs and other flash storage media
SSDs and many other flash storage media use a technique called “wear levelling” that reassigns unused blocks of storage cells based on their number of previous write cycles to prolong the drive’s life time. As a consequence overwriting block ranges doesn't work as a method to erase storage content securely (or even efficiently) like it does for hard disk drives. On the other side flash storage allows much faster and efficient secure erasure of blocks, block ranges or entire drives.
Erase the entire drive
You should use the drive's security erase feature.
Make sure the drive security supports secure erause1 and is not “frozen”. If it is, it may help to suspend and resume the computer.
$ sudo hdparm -I /dev/sdX | grep frozen
not frozen
The (filtered) command output means that this drive supports secure erasure, is ”not frozen” and you can continue.
Set a User Password (
Eins
in this example). This password is cleared too, the exact choice does not matter.
sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
Issue the ATA Secure Erase command.
sudo hdparm --user-master u --security-erase Eins /dev/sdX
See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.
(source)
If the command output in step 1 is empty the drive does not support secure erasure but may still support the TRIM command required for the section below.
Erase a drive partition
The blkdiscard(8)
2 can erase block devices securely if the drive supports it1:
sudo blkdiscard --secure /dev/sdXN
where /dev/sdXN
is the path to the block device node referring to the drive or partition to erase.
1 If your drive is inside an external casing with a USB or FireWire connection the translation chipset may block support of some optional features like secure erasure and TRIM even if the enclosed drive supports it.
2 Available and installed by default since Ubuntu Xenial Xerus (16.04).
add a comment |
I use truecrypt file image for such essential data. I't handy, free, crossplatform and I don't need a full disk nor using any extra software to "really delete" the file.
Just make sure you have strong password and make make backup of the image file. I keep backup in a cloud.
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
add a comment |
The first option is shred. The previous answer in regards to shred is lacking some needed details. You will not overcome the file system caching, snapshots and journaling, etc. if you run shred on the partition (as in the example of
sdc5
), and data will remain, lots of it potentially.
For shred to be effective, especially on modern SSD's etc, you must run it on the device not the partition. This would be
/dev/sdc
... without a number on the end (partition number).
You will need to do this from a live USB if the drive you wish to clean is the primary device for your computer. In this case, you will be best to add persistence to the live USB when you create it so that you can download a few extra tools to do the job properly also.
Run the command:
sudo shred -vfxz /dev/sdc
orsda
or whatever the device name is. If you are unsure of name, open Disks or GParted to identify your device, or run the command-lsblk
in the terminal and identify the name of your device there.
Adding the letters
f
andx
to the command is important as f= force permissions and x=exact size of files. Without these you may miss data that required permission to read or write, or miss data when the file is rounded up to the block size.
You can add a desired number of write passes by adding
-n
(number you desire). Example:sudo shred -vfxz -n 5 /dev/sdc
This is the first port of call to wipe your drive. It may help to run similar tools such as shrub, secure-delete and nwipe. They all work in the same way with very similar commands and slightly different methods and patterns. Go to the Linux man page or Google them to quickly become familiar with how to use the commands. It is not likely you will need more than the standard 4 shred passes, but if it is important you might as well go the extra mile as it could possibly help.
Your RAM may well have data on it. After installing secure-delete, run the command for sdmem. This will wipe your RAM memory. However the first data you ever filled the RAM with, plus any data that stayed in RAM for prolonged periods, may well have left a trace.
When buying new RAM(or HD's/SSD's for that matter), it is best to fill the drive to completion a few times. You could use shred, but dd is probably better here. Command:
sudo dd if=/dev/urandom of=/dev/ # (insert your device partion name)
It is also best with RAM to repeat this procedure before using sensitive data if you want to increase your security, and wipe sensitive data from RAM as quickly as possible afterwards. It is this time left in place that is mostly responsible for its ability to leave a trace.
The only thing left to do is create a partition or install your next distro.
Encryption - People often state this as a reliable method, but if you are going to continue to use your hard drive or pass it on to someone else, this is not an effective option. With regard to legal trouble, failing to unlock an encrypted device is often not an option and can be presumed guilt or an actual offense in many places. It may stop a thief, etc. though (stealing data only lol).
Also note, an encrypted home folder is very different and protects nothing from physically being examined on your computer, it is for online/system safety essentially and can be circumvented.
If disposing of the device - After wiping with shred, then encrypting with a long password that contains special characters like * etc. to break up the letters and numbers of your password, use shred again but you can just specify the first 10gig of the drive (depends on size, but this is a large safe number). Example:
sudo shred -vfxzs10G /dev/sdc
This is quicker and just as effective as shredding the whole drive in these circumstances.
Then to be sure, take the hard drive and RAM out, the RAM is easy to snap and destroy, SSDs are too. You can get creative and release that paranoid energy while breaking them.
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
add a comment |
You can use DD to secure erase a file, good luck recovering it when you do that. See an example on this site.
Here is the command to secure wipe a file (Adjust the bs=xx
parameter)
dd if=/dev/urandom of=/tmp/test/myfile.txt bs=27 count=1 conv=notrunc
where bs=##
is how much random data to write to a file in bytes (must match the size of the file being overwritten, enter file size in bytes as seen in ls -l
command)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f57572%2fhow-to-delete-files-in-secure-manner%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
Shred
This command line tool is already installed from the core utilities in Ubuntu to securely erase and overwrite single files using the Gutman method.
Fast shredding
shred -vzn 0 /dev/sdc1
erases whole partitions by overwriting everything with 0
s in a single iteration. If no legal aspects require another procedure, doing so is most probably safe to securely delete your private data Craig Wright Lecture Notes in Computer Science, 2008, 5352, 243-257.
Secure shredding
shred -vzn 3 /dev/sdc1
erases the whole partition using 3 iterations with random numbers. In addition (option -z
) this writes zeros to hide the shredding process at the end. This will take 4 times longer than the fast method.
NOTE: By shredding a partition we will overwrite this partition with 0
or random numbers. It therefore efficiently deletes everything including file system caches on that partition forever. This can also be used to remove unwanted remnants of deleted files. Files we want to keep will have to be backed up before shredding.
Wipe
More options, and the possibility of erasing directories in addition to single files, are offered by this command line utility.
wipe filename
wipe -r dirname
Additional notes on journaling file systems and SSDs:
Please read the notes in the linked manpages on security issues arising from still recoverable backups in journaling file systems when erasing single files. Overwriting whole partitions rather than single files will effectively erase all data even when using a journaling file system.
Erasing data on a solid state disk (SSD) can if at all only be done by overwriting the whole drive (not only single partitions) with several iterations. Some SSDs may have an inbuilt feature to erase data but this may not always be efficient (see this link from comment). At present there is no general recommendation on the wiping processes or number of erase iterations needed to securely remove all data remnants on all SSDs available.
These options can be added in the context menu of Nautilus and Thunar.
- In Thunar, open "Edit" then "Configure Custom Actions"
Add (the plus sign)
Name "Shred File"
Description whatever you like
Action "shred -u %f"
Similarly for wipe
.
- For Nautilus see this question and those related
Select "Appearance Conditions" and select "Other Files"
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
|
show 12 more comments
Shred
This command line tool is already installed from the core utilities in Ubuntu to securely erase and overwrite single files using the Gutman method.
Fast shredding
shred -vzn 0 /dev/sdc1
erases whole partitions by overwriting everything with 0
s in a single iteration. If no legal aspects require another procedure, doing so is most probably safe to securely delete your private data Craig Wright Lecture Notes in Computer Science, 2008, 5352, 243-257.
Secure shredding
shred -vzn 3 /dev/sdc1
erases the whole partition using 3 iterations with random numbers. In addition (option -z
) this writes zeros to hide the shredding process at the end. This will take 4 times longer than the fast method.
NOTE: By shredding a partition we will overwrite this partition with 0
or random numbers. It therefore efficiently deletes everything including file system caches on that partition forever. This can also be used to remove unwanted remnants of deleted files. Files we want to keep will have to be backed up before shredding.
Wipe
More options, and the possibility of erasing directories in addition to single files, are offered by this command line utility.
wipe filename
wipe -r dirname
Additional notes on journaling file systems and SSDs:
Please read the notes in the linked manpages on security issues arising from still recoverable backups in journaling file systems when erasing single files. Overwriting whole partitions rather than single files will effectively erase all data even when using a journaling file system.
Erasing data on a solid state disk (SSD) can if at all only be done by overwriting the whole drive (not only single partitions) with several iterations. Some SSDs may have an inbuilt feature to erase data but this may not always be efficient (see this link from comment). At present there is no general recommendation on the wiping processes or number of erase iterations needed to securely remove all data remnants on all SSDs available.
These options can be added in the context menu of Nautilus and Thunar.
- In Thunar, open "Edit" then "Configure Custom Actions"
Add (the plus sign)
Name "Shred File"
Description whatever you like
Action "shred -u %f"
Similarly for wipe
.
- For Nautilus see this question and those related
Select "Appearance Conditions" and select "Other Files"
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
|
show 12 more comments
Shred
This command line tool is already installed from the core utilities in Ubuntu to securely erase and overwrite single files using the Gutman method.
Fast shredding
shred -vzn 0 /dev/sdc1
erases whole partitions by overwriting everything with 0
s in a single iteration. If no legal aspects require another procedure, doing so is most probably safe to securely delete your private data Craig Wright Lecture Notes in Computer Science, 2008, 5352, 243-257.
Secure shredding
shred -vzn 3 /dev/sdc1
erases the whole partition using 3 iterations with random numbers. In addition (option -z
) this writes zeros to hide the shredding process at the end. This will take 4 times longer than the fast method.
NOTE: By shredding a partition we will overwrite this partition with 0
or random numbers. It therefore efficiently deletes everything including file system caches on that partition forever. This can also be used to remove unwanted remnants of deleted files. Files we want to keep will have to be backed up before shredding.
Wipe
More options, and the possibility of erasing directories in addition to single files, are offered by this command line utility.
wipe filename
wipe -r dirname
Additional notes on journaling file systems and SSDs:
Please read the notes in the linked manpages on security issues arising from still recoverable backups in journaling file systems when erasing single files. Overwriting whole partitions rather than single files will effectively erase all data even when using a journaling file system.
Erasing data on a solid state disk (SSD) can if at all only be done by overwriting the whole drive (not only single partitions) with several iterations. Some SSDs may have an inbuilt feature to erase data but this may not always be efficient (see this link from comment). At present there is no general recommendation on the wiping processes or number of erase iterations needed to securely remove all data remnants on all SSDs available.
These options can be added in the context menu of Nautilus and Thunar.
- In Thunar, open "Edit" then "Configure Custom Actions"
Add (the plus sign)
Name "Shred File"
Description whatever you like
Action "shred -u %f"
Similarly for wipe
.
- For Nautilus see this question and those related
Select "Appearance Conditions" and select "Other Files"
Shred
This command line tool is already installed from the core utilities in Ubuntu to securely erase and overwrite single files using the Gutman method.
Fast shredding
shred -vzn 0 /dev/sdc1
erases whole partitions by overwriting everything with 0
s in a single iteration. If no legal aspects require another procedure, doing so is most probably safe to securely delete your private data Craig Wright Lecture Notes in Computer Science, 2008, 5352, 243-257.
Secure shredding
shred -vzn 3 /dev/sdc1
erases the whole partition using 3 iterations with random numbers. In addition (option -z
) this writes zeros to hide the shredding process at the end. This will take 4 times longer than the fast method.
NOTE: By shredding a partition we will overwrite this partition with 0
or random numbers. It therefore efficiently deletes everything including file system caches on that partition forever. This can also be used to remove unwanted remnants of deleted files. Files we want to keep will have to be backed up before shredding.
Wipe
More options, and the possibility of erasing directories in addition to single files, are offered by this command line utility.
wipe filename
wipe -r dirname
Additional notes on journaling file systems and SSDs:
Please read the notes in the linked manpages on security issues arising from still recoverable backups in journaling file systems when erasing single files. Overwriting whole partitions rather than single files will effectively erase all data even when using a journaling file system.
Erasing data on a solid state disk (SSD) can if at all only be done by overwriting the whole drive (not only single partitions) with several iterations. Some SSDs may have an inbuilt feature to erase data but this may not always be efficient (see this link from comment). At present there is no general recommendation on the wiping processes or number of erase iterations needed to securely remove all data remnants on all SSDs available.
These options can be added in the context menu of Nautilus and Thunar.
- In Thunar, open "Edit" then "Configure Custom Actions"
Add (the plus sign)
Name "Shred File"
Description whatever you like
Action "shred -u %f"
Similarly for wipe
.
- For Nautilus see this question and those related
Select "Appearance Conditions" and select "Other Files"
edited Apr 13 '17 at 12:25
Community♦
1
1
answered Aug 18 '11 at 8:53
TakkatTakkat
109k37253379
109k37253379
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
|
show 12 more comments
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
6
6
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
It is probably also worth noting that if you're using a solid state drive, it also acts as a simple log structured file system and may not overwrite the data.
– James Henstridge
Aug 18 '11 at 8:58
2
2
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
@shred, "about 20 minutes to erase a 1.44MB". About whole life to erase 640 gb :) . For wipe, "... we cannot guarantee that wipe will actually erase data, or that wiped data is not recoverable by advanced means." In other words, wipe has no real/full power on memory.
– user20296
Aug 20 '11 at 7:50
2
2
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
Note that, while you can use shred on individual files, as well, if you use a modern journaling filesystem, there's no guarantee that shred will result in unrecoverable deletion. You'd have to blow away the entire partition. I think the US government standard is 7 passes with random data.
– Scott Severance
Aug 24 '11 at 2:44
4
4
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
One comment regarding SSD: Overwriting the whole drive will not really help. In short: You cannot reliably remove data from flash memory. Always store confidential files encrypted. (cf. Wei et al., Reliably Erasing Data From Flash-Based Solid State Drives: usenix.org/events/fast11/tech/full_papers/Wei.pdf)
– freddyb
Aug 26 '11 at 10:19
2
2
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
@freddyb: I am aware of the fact that at present it is not clear how to securely erase data from a SSD. Encryption is always better - this includes conventional drives as well! The question however was on how to securely erase data (implying they may not have been encrypted before).
– Takkat
Sep 1 '11 at 14:18
|
show 12 more comments
There isn't one command that you can run which will easily clean up all the already-deleted files for you. However, there are a number of things you can do to reduce your vulnerability to this sort of attack in future.
As others have said, using tools like shred or srm allows you to delete a specific file by actually overwriting it, rather than just removing it from the filesystem. If you're feeling bold, you can replace the rm
command with shred
or srm
to securely delete files going forward. That means that whenever you (or another program) tries to delete something using rm
, the secure delete command will run instead.
However, if you're using a solid state disk, or even some newer mechanical disks, shred and other overwriting-based methods may not be effective, since the disk may not actually write where you think it's writing (source).
Full-Disk Encryption
A more convenient option is full-disk encryption. If you use the alternate installer, Ubuntu can automatically set up a fully-encrypted disk for you you, but you can also customize and configure the settings yourself. Once installed, the encryption is almost invisible to you: after you enter the passphrase (be sure to pick a good, long one) when the computer starts up, everything looks and feels just like normal Ubuntu.
You can also encrypt external media like USB drives using Ubuntu's Disk Utility. Setting up an encrypted external disk is as simple as checking the "encrypt underlying filesystem" box when formatting the disk. You can even store the passphrase on your (encrypted) keyring, so that you don't need to enter the phrase every time you plug that disk into your computer.
If your whole disk -- and all your removable media -- is encrypted, there's much less to worry about. A thief or police officer would need to swipe your computer while it's on, (or within a minute or two of turning it off if they're very good) in order to access your data. If you hibernate (rather than suspend) your computer when it's not in use, then you should be pretty safe.
If you ever need to completely destroy all your data, you don't need to do a Gutmann wipe of your whole disk. Simply overwrite the very beginning of the disk, to destroy the headers for the encrypted volume. Unlike with a regular filesystem, this will actually make it impossible to recover the data.
So, how do you go from your current setup to a safely encrypted disk? It's quite a challenge to retrofit a currently-installed operating system to use an encrypted disk. The easiest approach is to backup all your data and settings, then reinstall with an encrypted disk. When backing up, make sure to back up your data to an encrypted external drive, but don't save the passphrase in your keyring.
After you've backed everything up, you may want to aggressively wipe your hard drive, to make sure that none of your existing data can be recovered in the future. If you're using an SSD, the process is even more challenging, so depending how much you want to invest in the process, it might be worth destroying your current disk (a challenging proposition) and starting with a new one.
When reinstalling the OS, if you haven't aggressively wiped the disk already, you should make sure to completely fill the new encrypted partition, which will overwrite all your old data. Once you've restored your backup, you may want to aggressively wipe the start of the backup disk, to destroy the encryption header, so that it can't be recovered again.
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
add a comment |
There isn't one command that you can run which will easily clean up all the already-deleted files for you. However, there are a number of things you can do to reduce your vulnerability to this sort of attack in future.
As others have said, using tools like shred or srm allows you to delete a specific file by actually overwriting it, rather than just removing it from the filesystem. If you're feeling bold, you can replace the rm
command with shred
or srm
to securely delete files going forward. That means that whenever you (or another program) tries to delete something using rm
, the secure delete command will run instead.
However, if you're using a solid state disk, or even some newer mechanical disks, shred and other overwriting-based methods may not be effective, since the disk may not actually write where you think it's writing (source).
Full-Disk Encryption
A more convenient option is full-disk encryption. If you use the alternate installer, Ubuntu can automatically set up a fully-encrypted disk for you you, but you can also customize and configure the settings yourself. Once installed, the encryption is almost invisible to you: after you enter the passphrase (be sure to pick a good, long one) when the computer starts up, everything looks and feels just like normal Ubuntu.
You can also encrypt external media like USB drives using Ubuntu's Disk Utility. Setting up an encrypted external disk is as simple as checking the "encrypt underlying filesystem" box when formatting the disk. You can even store the passphrase on your (encrypted) keyring, so that you don't need to enter the phrase every time you plug that disk into your computer.
If your whole disk -- and all your removable media -- is encrypted, there's much less to worry about. A thief or police officer would need to swipe your computer while it's on, (or within a minute or two of turning it off if they're very good) in order to access your data. If you hibernate (rather than suspend) your computer when it's not in use, then you should be pretty safe.
If you ever need to completely destroy all your data, you don't need to do a Gutmann wipe of your whole disk. Simply overwrite the very beginning of the disk, to destroy the headers for the encrypted volume. Unlike with a regular filesystem, this will actually make it impossible to recover the data.
So, how do you go from your current setup to a safely encrypted disk? It's quite a challenge to retrofit a currently-installed operating system to use an encrypted disk. The easiest approach is to backup all your data and settings, then reinstall with an encrypted disk. When backing up, make sure to back up your data to an encrypted external drive, but don't save the passphrase in your keyring.
After you've backed everything up, you may want to aggressively wipe your hard drive, to make sure that none of your existing data can be recovered in the future. If you're using an SSD, the process is even more challenging, so depending how much you want to invest in the process, it might be worth destroying your current disk (a challenging proposition) and starting with a new one.
When reinstalling the OS, if you haven't aggressively wiped the disk already, you should make sure to completely fill the new encrypted partition, which will overwrite all your old data. Once you've restored your backup, you may want to aggressively wipe the start of the backup disk, to destroy the encryption header, so that it can't be recovered again.
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
add a comment |
There isn't one command that you can run which will easily clean up all the already-deleted files for you. However, there are a number of things you can do to reduce your vulnerability to this sort of attack in future.
As others have said, using tools like shred or srm allows you to delete a specific file by actually overwriting it, rather than just removing it from the filesystem. If you're feeling bold, you can replace the rm
command with shred
or srm
to securely delete files going forward. That means that whenever you (or another program) tries to delete something using rm
, the secure delete command will run instead.
However, if you're using a solid state disk, or even some newer mechanical disks, shred and other overwriting-based methods may not be effective, since the disk may not actually write where you think it's writing (source).
Full-Disk Encryption
A more convenient option is full-disk encryption. If you use the alternate installer, Ubuntu can automatically set up a fully-encrypted disk for you you, but you can also customize and configure the settings yourself. Once installed, the encryption is almost invisible to you: after you enter the passphrase (be sure to pick a good, long one) when the computer starts up, everything looks and feels just like normal Ubuntu.
You can also encrypt external media like USB drives using Ubuntu's Disk Utility. Setting up an encrypted external disk is as simple as checking the "encrypt underlying filesystem" box when formatting the disk. You can even store the passphrase on your (encrypted) keyring, so that you don't need to enter the phrase every time you plug that disk into your computer.
If your whole disk -- and all your removable media -- is encrypted, there's much less to worry about. A thief or police officer would need to swipe your computer while it's on, (or within a minute or two of turning it off if they're very good) in order to access your data. If you hibernate (rather than suspend) your computer when it's not in use, then you should be pretty safe.
If you ever need to completely destroy all your data, you don't need to do a Gutmann wipe of your whole disk. Simply overwrite the very beginning of the disk, to destroy the headers for the encrypted volume. Unlike with a regular filesystem, this will actually make it impossible to recover the data.
So, how do you go from your current setup to a safely encrypted disk? It's quite a challenge to retrofit a currently-installed operating system to use an encrypted disk. The easiest approach is to backup all your data and settings, then reinstall with an encrypted disk. When backing up, make sure to back up your data to an encrypted external drive, but don't save the passphrase in your keyring.
After you've backed everything up, you may want to aggressively wipe your hard drive, to make sure that none of your existing data can be recovered in the future. If you're using an SSD, the process is even more challenging, so depending how much you want to invest in the process, it might be worth destroying your current disk (a challenging proposition) and starting with a new one.
When reinstalling the OS, if you haven't aggressively wiped the disk already, you should make sure to completely fill the new encrypted partition, which will overwrite all your old data. Once you've restored your backup, you may want to aggressively wipe the start of the backup disk, to destroy the encryption header, so that it can't be recovered again.
There isn't one command that you can run which will easily clean up all the already-deleted files for you. However, there are a number of things you can do to reduce your vulnerability to this sort of attack in future.
As others have said, using tools like shred or srm allows you to delete a specific file by actually overwriting it, rather than just removing it from the filesystem. If you're feeling bold, you can replace the rm
command with shred
or srm
to securely delete files going forward. That means that whenever you (or another program) tries to delete something using rm
, the secure delete command will run instead.
However, if you're using a solid state disk, or even some newer mechanical disks, shred and other overwriting-based methods may not be effective, since the disk may not actually write where you think it's writing (source).
Full-Disk Encryption
A more convenient option is full-disk encryption. If you use the alternate installer, Ubuntu can automatically set up a fully-encrypted disk for you you, but you can also customize and configure the settings yourself. Once installed, the encryption is almost invisible to you: after you enter the passphrase (be sure to pick a good, long one) when the computer starts up, everything looks and feels just like normal Ubuntu.
You can also encrypt external media like USB drives using Ubuntu's Disk Utility. Setting up an encrypted external disk is as simple as checking the "encrypt underlying filesystem" box when formatting the disk. You can even store the passphrase on your (encrypted) keyring, so that you don't need to enter the phrase every time you plug that disk into your computer.
If your whole disk -- and all your removable media -- is encrypted, there's much less to worry about. A thief or police officer would need to swipe your computer while it's on, (or within a minute or two of turning it off if they're very good) in order to access your data. If you hibernate (rather than suspend) your computer when it's not in use, then you should be pretty safe.
If you ever need to completely destroy all your data, you don't need to do a Gutmann wipe of your whole disk. Simply overwrite the very beginning of the disk, to destroy the headers for the encrypted volume. Unlike with a regular filesystem, this will actually make it impossible to recover the data.
So, how do you go from your current setup to a safely encrypted disk? It's quite a challenge to retrofit a currently-installed operating system to use an encrypted disk. The easiest approach is to backup all your data and settings, then reinstall with an encrypted disk. When backing up, make sure to back up your data to an encrypted external drive, but don't save the passphrase in your keyring.
After you've backed everything up, you may want to aggressively wipe your hard drive, to make sure that none of your existing data can be recovered in the future. If you're using an SSD, the process is even more challenging, so depending how much you want to invest in the process, it might be worth destroying your current disk (a challenging proposition) and starting with a new one.
When reinstalling the OS, if you haven't aggressively wiped the disk already, you should make sure to completely fill the new encrypted partition, which will overwrite all your old data. Once you've restored your backup, you may want to aggressively wipe the start of the backup disk, to destroy the encryption header, so that it can't be recovered again.
edited Aug 24 '11 at 8:27
answered Aug 23 '11 at 20:30
flamsmarkflamsmark
72258
72258
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
add a comment |
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
Can you explain the part about 'Simply overwrite the very beginning of the disk, to destroy the headers...'? I've always just discarded or returned encrypted drives when they failed, assuming nobody could recover the data. Is this a bad assumption? This is with 64 character random hex passwords, so nobody is cracking them.
– Tom Brossman
Feb 17 '12 at 14:12
1
1
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
The slides (pdf) you linked to lead to the conclusion that the only way to reliably shred an SSD is to literally (physically) shred it.
– Titus
Jun 15 '17 at 7:22
add a comment |
Update: If you have not yet deleted the file that you want to be non-recoverable, use the accepted answer. If, however, you already deleted the file[s], then this is the next best method that I know of.
If I read you right, you want to erase all your previously deleted files. Here is a simple way to do that:
$ dd if=/dev/zero of=/path/to/mounted/partition/tmp_file bs=1M count=999999999999
Let that run till it complains till it gets a disk write error [out of space]. Then delete the file! What this does is just fill up your empty disk with 000s, so all your previous files get overwritten. Make sure to delete the file now, or you will not have any disk left. You might want to do this a few times if you are really paranoid. Or if you want to write random to your disk, I'd suggest replace /dev/zero
with /dev/urandom
.
However, this will take much much longer, so I'd run it overnight. Also, if you want a progress meter, do this instead:
$ free=$( df {PARTITION OR MOUNTPOINT} |awk '{print $3}'|tail -1 )
$ dd if=/dev/zero bs=1M count=999999999999 | pv -s "$free" > /path/to/mounted/partition/tmp_file
First you are getting your free disk space with du, awk, and tail, then using dd to get /dev/zero, piping that to pv
which stands for "pipe viewer", that redirects everything to tmp_file
Once again, delete the file afterwards. $ rm tmp_file
Anyway, hope someone finds this useful! :)
1
Is there a command-line utility that does this for you? Say,overwrite_empty_space /dev/sdb1
?
– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
add a comment |
Update: If you have not yet deleted the file that you want to be non-recoverable, use the accepted answer. If, however, you already deleted the file[s], then this is the next best method that I know of.
If I read you right, you want to erase all your previously deleted files. Here is a simple way to do that:
$ dd if=/dev/zero of=/path/to/mounted/partition/tmp_file bs=1M count=999999999999
Let that run till it complains till it gets a disk write error [out of space]. Then delete the file! What this does is just fill up your empty disk with 000s, so all your previous files get overwritten. Make sure to delete the file now, or you will not have any disk left. You might want to do this a few times if you are really paranoid. Or if you want to write random to your disk, I'd suggest replace /dev/zero
with /dev/urandom
.
However, this will take much much longer, so I'd run it overnight. Also, if you want a progress meter, do this instead:
$ free=$( df {PARTITION OR MOUNTPOINT} |awk '{print $3}'|tail -1 )
$ dd if=/dev/zero bs=1M count=999999999999 | pv -s "$free" > /path/to/mounted/partition/tmp_file
First you are getting your free disk space with du, awk, and tail, then using dd to get /dev/zero, piping that to pv
which stands for "pipe viewer", that redirects everything to tmp_file
Once again, delete the file afterwards. $ rm tmp_file
Anyway, hope someone finds this useful! :)
1
Is there a command-line utility that does this for you? Say,overwrite_empty_space /dev/sdb1
?
– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
add a comment |
Update: If you have not yet deleted the file that you want to be non-recoverable, use the accepted answer. If, however, you already deleted the file[s], then this is the next best method that I know of.
If I read you right, you want to erase all your previously deleted files. Here is a simple way to do that:
$ dd if=/dev/zero of=/path/to/mounted/partition/tmp_file bs=1M count=999999999999
Let that run till it complains till it gets a disk write error [out of space]. Then delete the file! What this does is just fill up your empty disk with 000s, so all your previous files get overwritten. Make sure to delete the file now, or you will not have any disk left. You might want to do this a few times if you are really paranoid. Or if you want to write random to your disk, I'd suggest replace /dev/zero
with /dev/urandom
.
However, this will take much much longer, so I'd run it overnight. Also, if you want a progress meter, do this instead:
$ free=$( df {PARTITION OR MOUNTPOINT} |awk '{print $3}'|tail -1 )
$ dd if=/dev/zero bs=1M count=999999999999 | pv -s "$free" > /path/to/mounted/partition/tmp_file
First you are getting your free disk space with du, awk, and tail, then using dd to get /dev/zero, piping that to pv
which stands for "pipe viewer", that redirects everything to tmp_file
Once again, delete the file afterwards. $ rm tmp_file
Anyway, hope someone finds this useful! :)
Update: If you have not yet deleted the file that you want to be non-recoverable, use the accepted answer. If, however, you already deleted the file[s], then this is the next best method that I know of.
If I read you right, you want to erase all your previously deleted files. Here is a simple way to do that:
$ dd if=/dev/zero of=/path/to/mounted/partition/tmp_file bs=1M count=999999999999
Let that run till it complains till it gets a disk write error [out of space]. Then delete the file! What this does is just fill up your empty disk with 000s, so all your previous files get overwritten. Make sure to delete the file now, or you will not have any disk left. You might want to do this a few times if you are really paranoid. Or if you want to write random to your disk, I'd suggest replace /dev/zero
with /dev/urandom
.
However, this will take much much longer, so I'd run it overnight. Also, if you want a progress meter, do this instead:
$ free=$( df {PARTITION OR MOUNTPOINT} |awk '{print $3}'|tail -1 )
$ dd if=/dev/zero bs=1M count=999999999999 | pv -s "$free" > /path/to/mounted/partition/tmp_file
First you are getting your free disk space with du, awk, and tail, then using dd to get /dev/zero, piping that to pv
which stands for "pipe viewer", that redirects everything to tmp_file
Once again, delete the file afterwards. $ rm tmp_file
Anyway, hope someone finds this useful! :)
edited Jul 2 '14 at 19:27
answered Aug 25 '11 at 13:12
MattMatt
6,54183550
6,54183550
1
Is there a command-line utility that does this for you? Say,overwrite_empty_space /dev/sdb1
?
– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
add a comment |
1
Is there a command-line utility that does this for you? Say,overwrite_empty_space /dev/sdb1
?
– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
1
1
Is there a command-line utility that does this for you? Say,
overwrite_empty_space /dev/sdb1
?– landroni
Jun 16 '14 at 18:41
Is there a command-line utility that does this for you? Say,
overwrite_empty_space /dev/sdb1
?– landroni
Jun 16 '14 at 18:41
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
@landroni, I am not aware of such a utility. You could easily put this into a BASH script, however. [if you did, I recommend instead of using "/dev/sdb1" you just give it a path to the big file. Wherever it's mounted, that's what disk it will clean] This takes a little effort, so I will not try to go into detail here. I'm sure you can find the info by searching.
– Matt
Jul 2 '14 at 19:28
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
Why not shred the tmp_file after the disk is filled up, if you really want to be sure that the file cannot be recovered?
– SPRBRN
Dec 3 '14 at 9:05
add a comment |
First, delete files with rm on the terminal or with shift-delete on nautilus.
Better yet, use srm
, from the Secure-Delete tools package.
You can install the secure delete tools like this:
apt-get install secure-delete
Second, use sfill to wipe out unused space on your disk:
sudo sfill -f <directory>
This will take some time, since it is using crypto techniques to fill out the disk.
Warning: this is going through your whole filesystem, and you are root. Use with care!
This will create a file which wipes out all previously existing data. The file will be created in <directory>
.
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
add a comment |
First, delete files with rm on the terminal or with shift-delete on nautilus.
Better yet, use srm
, from the Secure-Delete tools package.
You can install the secure delete tools like this:
apt-get install secure-delete
Second, use sfill to wipe out unused space on your disk:
sudo sfill -f <directory>
This will take some time, since it is using crypto techniques to fill out the disk.
Warning: this is going through your whole filesystem, and you are root. Use with care!
This will create a file which wipes out all previously existing data. The file will be created in <directory>
.
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
add a comment |
First, delete files with rm on the terminal or with shift-delete on nautilus.
Better yet, use srm
, from the Secure-Delete tools package.
You can install the secure delete tools like this:
apt-get install secure-delete
Second, use sfill to wipe out unused space on your disk:
sudo sfill -f <directory>
This will take some time, since it is using crypto techniques to fill out the disk.
Warning: this is going through your whole filesystem, and you are root. Use with care!
This will create a file which wipes out all previously existing data. The file will be created in <directory>
.
First, delete files with rm on the terminal or with shift-delete on nautilus.
Better yet, use srm
, from the Secure-Delete tools package.
You can install the secure delete tools like this:
apt-get install secure-delete
Second, use sfill to wipe out unused space on your disk:
sudo sfill -f <directory>
This will take some time, since it is using crypto techniques to fill out the disk.
Warning: this is going through your whole filesystem, and you are root. Use with care!
This will create a file which wipes out all previously existing data. The file will be created in <directory>
.
edited Oct 18 '15 at 20:23
syntaxerror
411412
411412
answered Aug 18 '11 at 8:34
dangonfastdangonfast
4551618
4551618
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
add a comment |
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
4
4
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
this program spends too much time. For 80 gb, I have waited approximately 18 hours. Moreover, there is no tool showing progress.
– user20296
Aug 18 '11 at 8:35
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
I forget to add ; 18 hours for just filling disk with /000.0 files
– user20296
Aug 18 '11 at 15:42
2
2
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
but it's secure and you can delete a file or directory.
– RusAlex
Aug 23 '11 at 8:37
6
6
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
I question whether this is really secure. On modern filesystems (ext2/3/4, ntfs, etc), there is a journal that helps prevent accidental data loss. So, even if you wipe the free space, you can't guarantee that the file is removed from the journal. Also, I understand that some filesystems work at high enough a level that it's difficult to guarantee that you're actually overwriting the physical disk sectors that were written to. AFAIK, the only way to securely wipe something is to wipe the entire partition and all files on it.
– Scott Severance
Aug 24 '11 at 2:48
1
1
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
It should be possible to overwrite free clusters and slack space, even in a journaling filesystem. Although for slack-space you might want to clear it on use by a new file. Anyhow, you'd have to flush the journal at start, and possibly pause normal filesystem operations for the duration.
– rsaxvc
Dec 10 '15 at 5:37
add a comment |
A GUI program for this is BleachBit (it's also in the sources). More recent (deb file) version at the BleachBit Sourceforge page.
Beyond simply deleting files, it includes advanced features such as shredding files to prevent recovery, wiping free disk space to hide traces of files deleted by other applications.
"BleachBit quickly frees disk space and tirelessly guards your privacy.
Free cache, delete cookies, clear Internet history, shred temporary
files, delete logs, and discard junk you didn't know was there.
Designed for Linux and Windows systems, it wipes clean 90 applications
including Firefox (vacuuming to make it faster), Internet Explorer,
Adobe Flash, Google Chrome, Opera, Safari and more." (from http://bleachbit.sourceforge.net/)
BleachBit has several advanced cleaners:
- Clear the memory and swap on Linux
- Delete broken shortcuts on Linux
- Delete the Firefox URL history without deleting the whole file—with optional shredding
- Find widely-scatted junk such as Thumbs.db and .DS_Store files.
- Delete the OpenOffice.org recent documents list without deleting the whole Common.xcu file
- Overwrite free disk space to hide previously files
- Vacuum Firefox, Google Chrome, Liferea, Thunderbird, and Yum databases: shrink files without removing data to save space and improve speed
- Surgically remove private information from .ini and JSON configuration files with deleting the whole file
For details on how to use Bleachbit to delete securely specific files and folders
see this answer.
add a comment |
A GUI program for this is BleachBit (it's also in the sources). More recent (deb file) version at the BleachBit Sourceforge page.
Beyond simply deleting files, it includes advanced features such as shredding files to prevent recovery, wiping free disk space to hide traces of files deleted by other applications.
"BleachBit quickly frees disk space and tirelessly guards your privacy.
Free cache, delete cookies, clear Internet history, shred temporary
files, delete logs, and discard junk you didn't know was there.
Designed for Linux and Windows systems, it wipes clean 90 applications
including Firefox (vacuuming to make it faster), Internet Explorer,
Adobe Flash, Google Chrome, Opera, Safari and more." (from http://bleachbit.sourceforge.net/)
BleachBit has several advanced cleaners:
- Clear the memory and swap on Linux
- Delete broken shortcuts on Linux
- Delete the Firefox URL history without deleting the whole file—with optional shredding
- Find widely-scatted junk such as Thumbs.db and .DS_Store files.
- Delete the OpenOffice.org recent documents list without deleting the whole Common.xcu file
- Overwrite free disk space to hide previously files
- Vacuum Firefox, Google Chrome, Liferea, Thunderbird, and Yum databases: shrink files without removing data to save space and improve speed
- Surgically remove private information from .ini and JSON configuration files with deleting the whole file
For details on how to use Bleachbit to delete securely specific files and folders
see this answer.
add a comment |
A GUI program for this is BleachBit (it's also in the sources). More recent (deb file) version at the BleachBit Sourceforge page.
Beyond simply deleting files, it includes advanced features such as shredding files to prevent recovery, wiping free disk space to hide traces of files deleted by other applications.
"BleachBit quickly frees disk space and tirelessly guards your privacy.
Free cache, delete cookies, clear Internet history, shred temporary
files, delete logs, and discard junk you didn't know was there.
Designed for Linux and Windows systems, it wipes clean 90 applications
including Firefox (vacuuming to make it faster), Internet Explorer,
Adobe Flash, Google Chrome, Opera, Safari and more." (from http://bleachbit.sourceforge.net/)
BleachBit has several advanced cleaners:
- Clear the memory and swap on Linux
- Delete broken shortcuts on Linux
- Delete the Firefox URL history without deleting the whole file—with optional shredding
- Find widely-scatted junk such as Thumbs.db and .DS_Store files.
- Delete the OpenOffice.org recent documents list without deleting the whole Common.xcu file
- Overwrite free disk space to hide previously files
- Vacuum Firefox, Google Chrome, Liferea, Thunderbird, and Yum databases: shrink files without removing data to save space and improve speed
- Surgically remove private information from .ini and JSON configuration files with deleting the whole file
For details on how to use Bleachbit to delete securely specific files and folders
see this answer.
A GUI program for this is BleachBit (it's also in the sources). More recent (deb file) version at the BleachBit Sourceforge page.
Beyond simply deleting files, it includes advanced features such as shredding files to prevent recovery, wiping free disk space to hide traces of files deleted by other applications.
"BleachBit quickly frees disk space and tirelessly guards your privacy.
Free cache, delete cookies, clear Internet history, shred temporary
files, delete logs, and discard junk you didn't know was there.
Designed for Linux and Windows systems, it wipes clean 90 applications
including Firefox (vacuuming to make it faster), Internet Explorer,
Adobe Flash, Google Chrome, Opera, Safari and more." (from http://bleachbit.sourceforge.net/)
BleachBit has several advanced cleaners:
- Clear the memory and swap on Linux
- Delete broken shortcuts on Linux
- Delete the Firefox URL history without deleting the whole file—with optional shredding
- Find widely-scatted junk such as Thumbs.db and .DS_Store files.
- Delete the OpenOffice.org recent documents list without deleting the whole Common.xcu file
- Overwrite free disk space to hide previously files
- Vacuum Firefox, Google Chrome, Liferea, Thunderbird, and Yum databases: shrink files without removing data to save space and improve speed
- Surgically remove private information from .ini and JSON configuration files with deleting the whole file
For details on how to use Bleachbit to delete securely specific files and folders
see this answer.
edited Apr 13 '17 at 12:23
Community♦
1
1
answered Aug 24 '11 at 23:21
valadaovaladao
63769
63769
add a comment |
add a comment |
If you want a solution which can't be thwarted by a pathologically obsessed individual then you should consider some combination (limited by monetary resources) of:
- degaussing -- magnetically erasing the hard drive
- physically disabling the hard drive -- i.e. industrial hole punch
- acid bath <-- you can't get bits from a pile of goo.
These solutions range drastically in cost & ingenuity. A few:
- http://www.semshred.com/hard_drive_crusher
- http://www.edrsolutions.com/solution.asp
- http://www.doc-res.com/hard-drive-destruction.shtm
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
add a comment |
If you want a solution which can't be thwarted by a pathologically obsessed individual then you should consider some combination (limited by monetary resources) of:
- degaussing -- magnetically erasing the hard drive
- physically disabling the hard drive -- i.e. industrial hole punch
- acid bath <-- you can't get bits from a pile of goo.
These solutions range drastically in cost & ingenuity. A few:
- http://www.semshred.com/hard_drive_crusher
- http://www.edrsolutions.com/solution.asp
- http://www.doc-res.com/hard-drive-destruction.shtm
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
add a comment |
If you want a solution which can't be thwarted by a pathologically obsessed individual then you should consider some combination (limited by monetary resources) of:
- degaussing -- magnetically erasing the hard drive
- physically disabling the hard drive -- i.e. industrial hole punch
- acid bath <-- you can't get bits from a pile of goo.
These solutions range drastically in cost & ingenuity. A few:
- http://www.semshred.com/hard_drive_crusher
- http://www.edrsolutions.com/solution.asp
- http://www.doc-res.com/hard-drive-destruction.shtm
If you want a solution which can't be thwarted by a pathologically obsessed individual then you should consider some combination (limited by monetary resources) of:
- degaussing -- magnetically erasing the hard drive
- physically disabling the hard drive -- i.e. industrial hole punch
- acid bath <-- you can't get bits from a pile of goo.
These solutions range drastically in cost & ingenuity. A few:
- http://www.semshred.com/hard_drive_crusher
- http://www.edrsolutions.com/solution.asp
- http://www.doc-res.com/hard-drive-destruction.shtm
answered Aug 26 '11 at 6:05
M. TibbitsM. Tibbits
75841428
75841428
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
add a comment |
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
3
3
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
Fun answer, but I think the asker would like to be able to keep using his hard drive after his deletions.
– Christopher Kyle Horton
Sep 2 '11 at 15:49
3
3
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
where's a will there's a way: why not an atomic bomb?
– user47206
Mar 14 '13 at 21:07
2
2
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
OP wants data destroyed - not his/her country! :P
– John Rix
Jul 30 '16 at 0:31
2
2
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
I find a 15lb sledgehammer quite effective...and therapeutic.
– user535733
Feb 25 '17 at 15:17
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
Thermite is another alternative for a thorough obliviation (article in German but includes cool pictures of the process).
– David Foerster
Jul 19 '18 at 10:51
add a comment |
I would say the the solution is a combination of several answers given here. For already-deleted files and partitions still in use, I agree with Matt.
Then, for the future I would suggest to start using secure-delete tools instead of simple 'rm'.
Last, when it will be possible to reformat the partition, the option of encrypt the partition should be considered. Perhaps using some approach that offers Plausible deniability like in Truecrypt
add a comment |
I would say the the solution is a combination of several answers given here. For already-deleted files and partitions still in use, I agree with Matt.
Then, for the future I would suggest to start using secure-delete tools instead of simple 'rm'.
Last, when it will be possible to reformat the partition, the option of encrypt the partition should be considered. Perhaps using some approach that offers Plausible deniability like in Truecrypt
add a comment |
I would say the the solution is a combination of several answers given here. For already-deleted files and partitions still in use, I agree with Matt.
Then, for the future I would suggest to start using secure-delete tools instead of simple 'rm'.
Last, when it will be possible to reformat the partition, the option of encrypt the partition should be considered. Perhaps using some approach that offers Plausible deniability like in Truecrypt
I would say the the solution is a combination of several answers given here. For already-deleted files and partitions still in use, I agree with Matt.
Then, for the future I would suggest to start using secure-delete tools instead of simple 'rm'.
Last, when it will be possible to reformat the partition, the option of encrypt the partition should be considered. Perhaps using some approach that offers Plausible deniability like in Truecrypt
answered Aug 26 '11 at 5:42
bitwelderbitwelder
36128
36128
add a comment |
add a comment |
For SSDs and other flash storage media
SSDs and many other flash storage media use a technique called “wear levelling” that reassigns unused blocks of storage cells based on their number of previous write cycles to prolong the drive’s life time. As a consequence overwriting block ranges doesn't work as a method to erase storage content securely (or even efficiently) like it does for hard disk drives. On the other side flash storage allows much faster and efficient secure erasure of blocks, block ranges or entire drives.
Erase the entire drive
You should use the drive's security erase feature.
Make sure the drive security supports secure erause1 and is not “frozen”. If it is, it may help to suspend and resume the computer.
$ sudo hdparm -I /dev/sdX | grep frozen
not frozen
The (filtered) command output means that this drive supports secure erasure, is ”not frozen” and you can continue.
Set a User Password (
Eins
in this example). This password is cleared too, the exact choice does not matter.
sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
Issue the ATA Secure Erase command.
sudo hdparm --user-master u --security-erase Eins /dev/sdX
See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.
(source)
If the command output in step 1 is empty the drive does not support secure erasure but may still support the TRIM command required for the section below.
Erase a drive partition
The blkdiscard(8)
2 can erase block devices securely if the drive supports it1:
sudo blkdiscard --secure /dev/sdXN
where /dev/sdXN
is the path to the block device node referring to the drive or partition to erase.
1 If your drive is inside an external casing with a USB or FireWire connection the translation chipset may block support of some optional features like secure erasure and TRIM even if the enclosed drive supports it.
2 Available and installed by default since Ubuntu Xenial Xerus (16.04).
add a comment |
For SSDs and other flash storage media
SSDs and many other flash storage media use a technique called “wear levelling” that reassigns unused blocks of storage cells based on their number of previous write cycles to prolong the drive’s life time. As a consequence overwriting block ranges doesn't work as a method to erase storage content securely (or even efficiently) like it does for hard disk drives. On the other side flash storage allows much faster and efficient secure erasure of blocks, block ranges or entire drives.
Erase the entire drive
You should use the drive's security erase feature.
Make sure the drive security supports secure erause1 and is not “frozen”. If it is, it may help to suspend and resume the computer.
$ sudo hdparm -I /dev/sdX | grep frozen
not frozen
The (filtered) command output means that this drive supports secure erasure, is ”not frozen” and you can continue.
Set a User Password (
Eins
in this example). This password is cleared too, the exact choice does not matter.
sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
Issue the ATA Secure Erase command.
sudo hdparm --user-master u --security-erase Eins /dev/sdX
See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.
(source)
If the command output in step 1 is empty the drive does not support secure erasure but may still support the TRIM command required for the section below.
Erase a drive partition
The blkdiscard(8)
2 can erase block devices securely if the drive supports it1:
sudo blkdiscard --secure /dev/sdXN
where /dev/sdXN
is the path to the block device node referring to the drive or partition to erase.
1 If your drive is inside an external casing with a USB or FireWire connection the translation chipset may block support of some optional features like secure erasure and TRIM even if the enclosed drive supports it.
2 Available and installed by default since Ubuntu Xenial Xerus (16.04).
add a comment |
For SSDs and other flash storage media
SSDs and many other flash storage media use a technique called “wear levelling” that reassigns unused blocks of storage cells based on their number of previous write cycles to prolong the drive’s life time. As a consequence overwriting block ranges doesn't work as a method to erase storage content securely (or even efficiently) like it does for hard disk drives. On the other side flash storage allows much faster and efficient secure erasure of blocks, block ranges or entire drives.
Erase the entire drive
You should use the drive's security erase feature.
Make sure the drive security supports secure erause1 and is not “frozen”. If it is, it may help to suspend and resume the computer.
$ sudo hdparm -I /dev/sdX | grep frozen
not frozen
The (filtered) command output means that this drive supports secure erasure, is ”not frozen” and you can continue.
Set a User Password (
Eins
in this example). This password is cleared too, the exact choice does not matter.
sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
Issue the ATA Secure Erase command.
sudo hdparm --user-master u --security-erase Eins /dev/sdX
See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.
(source)
If the command output in step 1 is empty the drive does not support secure erasure but may still support the TRIM command required for the section below.
Erase a drive partition
The blkdiscard(8)
2 can erase block devices securely if the drive supports it1:
sudo blkdiscard --secure /dev/sdXN
where /dev/sdXN
is the path to the block device node referring to the drive or partition to erase.
1 If your drive is inside an external casing with a USB or FireWire connection the translation chipset may block support of some optional features like secure erasure and TRIM even if the enclosed drive supports it.
2 Available and installed by default since Ubuntu Xenial Xerus (16.04).
For SSDs and other flash storage media
SSDs and many other flash storage media use a technique called “wear levelling” that reassigns unused blocks of storage cells based on their number of previous write cycles to prolong the drive’s life time. As a consequence overwriting block ranges doesn't work as a method to erase storage content securely (or even efficiently) like it does for hard disk drives. On the other side flash storage allows much faster and efficient secure erasure of blocks, block ranges or entire drives.
Erase the entire drive
You should use the drive's security erase feature.
Make sure the drive security supports secure erause1 and is not “frozen”. If it is, it may help to suspend and resume the computer.
$ sudo hdparm -I /dev/sdX | grep frozen
not frozen
The (filtered) command output means that this drive supports secure erasure, is ”not frozen” and you can continue.
Set a User Password (
Eins
in this example). This password is cleared too, the exact choice does not matter.
sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
Issue the ATA Secure Erase command.
sudo hdparm --user-master u --security-erase Eins /dev/sdX
See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.
(source)
If the command output in step 1 is empty the drive does not support secure erasure but may still support the TRIM command required for the section below.
Erase a drive partition
The blkdiscard(8)
2 can erase block devices securely if the drive supports it1:
sudo blkdiscard --secure /dev/sdXN
where /dev/sdXN
is the path to the block device node referring to the drive or partition to erase.
1 If your drive is inside an external casing with a USB or FireWire connection the translation chipset may block support of some optional features like secure erasure and TRIM even if the enclosed drive supports it.
2 Available and installed by default since Ubuntu Xenial Xerus (16.04).
edited Jul 19 '18 at 11:06
answered Jul 19 '18 at 10:47
David FoersterDavid Foerster
28.6k1367113
28.6k1367113
add a comment |
add a comment |
I use truecrypt file image for such essential data. I't handy, free, crossplatform and I don't need a full disk nor using any extra software to "really delete" the file.
Just make sure you have strong password and make make backup of the image file. I keep backup in a cloud.
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
add a comment |
I use truecrypt file image for such essential data. I't handy, free, crossplatform and I don't need a full disk nor using any extra software to "really delete" the file.
Just make sure you have strong password and make make backup of the image file. I keep backup in a cloud.
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
add a comment |
I use truecrypt file image for such essential data. I't handy, free, crossplatform and I don't need a full disk nor using any extra software to "really delete" the file.
Just make sure you have strong password and make make backup of the image file. I keep backup in a cloud.
I use truecrypt file image for such essential data. I't handy, free, crossplatform and I don't need a full disk nor using any extra software to "really delete" the file.
Just make sure you have strong password and make make backup of the image file. I keep backup in a cloud.
answered Aug 23 '11 at 20:41
Michał ŠrajerMichał Šrajer
17.8k42528
17.8k42528
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
add a comment |
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
2
2
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
– KrIsHnA
Jan 10 '16 at 12:10
2
2
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
There are various TrueCrypt derivatives that are still being maintained eg. VeraCrypt. As an aside, there was no link between Microsoft discontinuing XP and TrueCrypt development being stopped - the circumstances surrounding the latter still remain a mystery to the best of my knowledge.
– John Rix
Jul 30 '16 at 0:37
add a comment |
The first option is shred. The previous answer in regards to shred is lacking some needed details. You will not overcome the file system caching, snapshots and journaling, etc. if you run shred on the partition (as in the example of
sdc5
), and data will remain, lots of it potentially.
For shred to be effective, especially on modern SSD's etc, you must run it on the device not the partition. This would be
/dev/sdc
... without a number on the end (partition number).
You will need to do this from a live USB if the drive you wish to clean is the primary device for your computer. In this case, you will be best to add persistence to the live USB when you create it so that you can download a few extra tools to do the job properly also.
Run the command:
sudo shred -vfxz /dev/sdc
orsda
or whatever the device name is. If you are unsure of name, open Disks or GParted to identify your device, or run the command-lsblk
in the terminal and identify the name of your device there.
Adding the letters
f
andx
to the command is important as f= force permissions and x=exact size of files. Without these you may miss data that required permission to read or write, or miss data when the file is rounded up to the block size.
You can add a desired number of write passes by adding
-n
(number you desire). Example:sudo shred -vfxz -n 5 /dev/sdc
This is the first port of call to wipe your drive. It may help to run similar tools such as shrub, secure-delete and nwipe. They all work in the same way with very similar commands and slightly different methods and patterns. Go to the Linux man page or Google them to quickly become familiar with how to use the commands. It is not likely you will need more than the standard 4 shred passes, but if it is important you might as well go the extra mile as it could possibly help.
Your RAM may well have data on it. After installing secure-delete, run the command for sdmem. This will wipe your RAM memory. However the first data you ever filled the RAM with, plus any data that stayed in RAM for prolonged periods, may well have left a trace.
When buying new RAM(or HD's/SSD's for that matter), it is best to fill the drive to completion a few times. You could use shred, but dd is probably better here. Command:
sudo dd if=/dev/urandom of=/dev/ # (insert your device partion name)
It is also best with RAM to repeat this procedure before using sensitive data if you want to increase your security, and wipe sensitive data from RAM as quickly as possible afterwards. It is this time left in place that is mostly responsible for its ability to leave a trace.
The only thing left to do is create a partition or install your next distro.
Encryption - People often state this as a reliable method, but if you are going to continue to use your hard drive or pass it on to someone else, this is not an effective option. With regard to legal trouble, failing to unlock an encrypted device is often not an option and can be presumed guilt or an actual offense in many places. It may stop a thief, etc. though (stealing data only lol).
Also note, an encrypted home folder is very different and protects nothing from physically being examined on your computer, it is for online/system safety essentially and can be circumvented.
If disposing of the device - After wiping with shred, then encrypting with a long password that contains special characters like * etc. to break up the letters and numbers of your password, use shred again but you can just specify the first 10gig of the drive (depends on size, but this is a large safe number). Example:
sudo shred -vfxzs10G /dev/sdc
This is quicker and just as effective as shredding the whole drive in these circumstances.
Then to be sure, take the hard drive and RAM out, the RAM is easy to snap and destroy, SSDs are too. You can get creative and release that paranoid energy while breaking them.
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
add a comment |
The first option is shred. The previous answer in regards to shred is lacking some needed details. You will not overcome the file system caching, snapshots and journaling, etc. if you run shred on the partition (as in the example of
sdc5
), and data will remain, lots of it potentially.
For shred to be effective, especially on modern SSD's etc, you must run it on the device not the partition. This would be
/dev/sdc
... without a number on the end (partition number).
You will need to do this from a live USB if the drive you wish to clean is the primary device for your computer. In this case, you will be best to add persistence to the live USB when you create it so that you can download a few extra tools to do the job properly also.
Run the command:
sudo shred -vfxz /dev/sdc
orsda
or whatever the device name is. If you are unsure of name, open Disks or GParted to identify your device, or run the command-lsblk
in the terminal and identify the name of your device there.
Adding the letters
f
andx
to the command is important as f= force permissions and x=exact size of files. Without these you may miss data that required permission to read or write, or miss data when the file is rounded up to the block size.
You can add a desired number of write passes by adding
-n
(number you desire). Example:sudo shred -vfxz -n 5 /dev/sdc
This is the first port of call to wipe your drive. It may help to run similar tools such as shrub, secure-delete and nwipe. They all work in the same way with very similar commands and slightly different methods and patterns. Go to the Linux man page or Google them to quickly become familiar with how to use the commands. It is not likely you will need more than the standard 4 shred passes, but if it is important you might as well go the extra mile as it could possibly help.
Your RAM may well have data on it. After installing secure-delete, run the command for sdmem. This will wipe your RAM memory. However the first data you ever filled the RAM with, plus any data that stayed in RAM for prolonged periods, may well have left a trace.
When buying new RAM(or HD's/SSD's for that matter), it is best to fill the drive to completion a few times. You could use shred, but dd is probably better here. Command:
sudo dd if=/dev/urandom of=/dev/ # (insert your device partion name)
It is also best with RAM to repeat this procedure before using sensitive data if you want to increase your security, and wipe sensitive data from RAM as quickly as possible afterwards. It is this time left in place that is mostly responsible for its ability to leave a trace.
The only thing left to do is create a partition or install your next distro.
Encryption - People often state this as a reliable method, but if you are going to continue to use your hard drive or pass it on to someone else, this is not an effective option. With regard to legal trouble, failing to unlock an encrypted device is often not an option and can be presumed guilt or an actual offense in many places. It may stop a thief, etc. though (stealing data only lol).
Also note, an encrypted home folder is very different and protects nothing from physically being examined on your computer, it is for online/system safety essentially and can be circumvented.
If disposing of the device - After wiping with shred, then encrypting with a long password that contains special characters like * etc. to break up the letters and numbers of your password, use shred again but you can just specify the first 10gig of the drive (depends on size, but this is a large safe number). Example:
sudo shred -vfxzs10G /dev/sdc
This is quicker and just as effective as shredding the whole drive in these circumstances.
Then to be sure, take the hard drive and RAM out, the RAM is easy to snap and destroy, SSDs are too. You can get creative and release that paranoid energy while breaking them.
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
add a comment |
The first option is shred. The previous answer in regards to shred is lacking some needed details. You will not overcome the file system caching, snapshots and journaling, etc. if you run shred on the partition (as in the example of
sdc5
), and data will remain, lots of it potentially.
For shred to be effective, especially on modern SSD's etc, you must run it on the device not the partition. This would be
/dev/sdc
... without a number on the end (partition number).
You will need to do this from a live USB if the drive you wish to clean is the primary device for your computer. In this case, you will be best to add persistence to the live USB when you create it so that you can download a few extra tools to do the job properly also.
Run the command:
sudo shred -vfxz /dev/sdc
orsda
or whatever the device name is. If you are unsure of name, open Disks or GParted to identify your device, or run the command-lsblk
in the terminal and identify the name of your device there.
Adding the letters
f
andx
to the command is important as f= force permissions and x=exact size of files. Without these you may miss data that required permission to read or write, or miss data when the file is rounded up to the block size.
You can add a desired number of write passes by adding
-n
(number you desire). Example:sudo shred -vfxz -n 5 /dev/sdc
This is the first port of call to wipe your drive. It may help to run similar tools such as shrub, secure-delete and nwipe. They all work in the same way with very similar commands and slightly different methods and patterns. Go to the Linux man page or Google them to quickly become familiar with how to use the commands. It is not likely you will need more than the standard 4 shred passes, but if it is important you might as well go the extra mile as it could possibly help.
Your RAM may well have data on it. After installing secure-delete, run the command for sdmem. This will wipe your RAM memory. However the first data you ever filled the RAM with, plus any data that stayed in RAM for prolonged periods, may well have left a trace.
When buying new RAM(or HD's/SSD's for that matter), it is best to fill the drive to completion a few times. You could use shred, but dd is probably better here. Command:
sudo dd if=/dev/urandom of=/dev/ # (insert your device partion name)
It is also best with RAM to repeat this procedure before using sensitive data if you want to increase your security, and wipe sensitive data from RAM as quickly as possible afterwards. It is this time left in place that is mostly responsible for its ability to leave a trace.
The only thing left to do is create a partition or install your next distro.
Encryption - People often state this as a reliable method, but if you are going to continue to use your hard drive or pass it on to someone else, this is not an effective option. With regard to legal trouble, failing to unlock an encrypted device is often not an option and can be presumed guilt or an actual offense in many places. It may stop a thief, etc. though (stealing data only lol).
Also note, an encrypted home folder is very different and protects nothing from physically being examined on your computer, it is for online/system safety essentially and can be circumvented.
If disposing of the device - After wiping with shred, then encrypting with a long password that contains special characters like * etc. to break up the letters and numbers of your password, use shred again but you can just specify the first 10gig of the drive (depends on size, but this is a large safe number). Example:
sudo shred -vfxzs10G /dev/sdc
This is quicker and just as effective as shredding the whole drive in these circumstances.
Then to be sure, take the hard drive and RAM out, the RAM is easy to snap and destroy, SSDs are too. You can get creative and release that paranoid energy while breaking them.
The first option is shred. The previous answer in regards to shred is lacking some needed details. You will not overcome the file system caching, snapshots and journaling, etc. if you run shred on the partition (as in the example of
sdc5
), and data will remain, lots of it potentially.
For shred to be effective, especially on modern SSD's etc, you must run it on the device not the partition. This would be
/dev/sdc
... without a number on the end (partition number).
You will need to do this from a live USB if the drive you wish to clean is the primary device for your computer. In this case, you will be best to add persistence to the live USB when you create it so that you can download a few extra tools to do the job properly also.
Run the command:
sudo shred -vfxz /dev/sdc
orsda
or whatever the device name is. If you are unsure of name, open Disks or GParted to identify your device, or run the command-lsblk
in the terminal and identify the name of your device there.
Adding the letters
f
andx
to the command is important as f= force permissions and x=exact size of files. Without these you may miss data that required permission to read or write, or miss data when the file is rounded up to the block size.
You can add a desired number of write passes by adding
-n
(number you desire). Example:sudo shred -vfxz -n 5 /dev/sdc
This is the first port of call to wipe your drive. It may help to run similar tools such as shrub, secure-delete and nwipe. They all work in the same way with very similar commands and slightly different methods and patterns. Go to the Linux man page or Google them to quickly become familiar with how to use the commands. It is not likely you will need more than the standard 4 shred passes, but if it is important you might as well go the extra mile as it could possibly help.
Your RAM may well have data on it. After installing secure-delete, run the command for sdmem. This will wipe your RAM memory. However the first data you ever filled the RAM with, plus any data that stayed in RAM for prolonged periods, may well have left a trace.
When buying new RAM(or HD's/SSD's for that matter), it is best to fill the drive to completion a few times. You could use shred, but dd is probably better here. Command:
sudo dd if=/dev/urandom of=/dev/ # (insert your device partion name)
It is also best with RAM to repeat this procedure before using sensitive data if you want to increase your security, and wipe sensitive data from RAM as quickly as possible afterwards. It is this time left in place that is mostly responsible for its ability to leave a trace.
The only thing left to do is create a partition or install your next distro.
Encryption - People often state this as a reliable method, but if you are going to continue to use your hard drive or pass it on to someone else, this is not an effective option. With regard to legal trouble, failing to unlock an encrypted device is often not an option and can be presumed guilt or an actual offense in many places. It may stop a thief, etc. though (stealing data only lol).
Also note, an encrypted home folder is very different and protects nothing from physically being examined on your computer, it is for online/system safety essentially and can be circumvented.
If disposing of the device - After wiping with shred, then encrypting with a long password that contains special characters like * etc. to break up the letters and numbers of your password, use shred again but you can just specify the first 10gig of the drive (depends on size, but this is a large safe number). Example:
sudo shred -vfxzs10G /dev/sdc
This is quicker and just as effective as shredding the whole drive in these circumstances.
Then to be sure, take the hard drive and RAM out, the RAM is easy to snap and destroy, SSDs are too. You can get creative and release that paranoid energy while breaking them.
edited Dec 31 '17 at 12:42
karel
61k13132155
61k13132155
answered Dec 31 '17 at 11:26
JayJay
112
112
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
add a comment |
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
3
3
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
Welcome to Ask Ubuntu! :-) The OP is asking about shredding a file, not a device...
– Fabby
Dec 31 '17 at 12:22
1
1
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
Oops lol. It was badly in need of that edit from karel too. Thanks
– Jay
Dec 31 '17 at 13:50
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
@Fabby -- the OP asked about shredding all deleted files, not just one. in this case shredding the device is appropriate. ie shredding free space.
– ravery
Dec 31 '17 at 14:55
1
1
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
+1 for addressing why encryption is not a solution
– matt
Jul 16 '18 at 19:22
add a comment |
You can use DD to secure erase a file, good luck recovering it when you do that. See an example on this site.
Here is the command to secure wipe a file (Adjust the bs=xx
parameter)
dd if=/dev/urandom of=/tmp/test/myfile.txt bs=27 count=1 conv=notrunc
where bs=##
is how much random data to write to a file in bytes (must match the size of the file being overwritten, enter file size in bytes as seen in ls -l
command)
add a comment |
You can use DD to secure erase a file, good luck recovering it when you do that. See an example on this site.
Here is the command to secure wipe a file (Adjust the bs=xx
parameter)
dd if=/dev/urandom of=/tmp/test/myfile.txt bs=27 count=1 conv=notrunc
where bs=##
is how much random data to write to a file in bytes (must match the size of the file being overwritten, enter file size in bytes as seen in ls -l
command)
add a comment |
You can use DD to secure erase a file, good luck recovering it when you do that. See an example on this site.
Here is the command to secure wipe a file (Adjust the bs=xx
parameter)
dd if=/dev/urandom of=/tmp/test/myfile.txt bs=27 count=1 conv=notrunc
where bs=##
is how much random data to write to a file in bytes (must match the size of the file being overwritten, enter file size in bytes as seen in ls -l
command)
You can use DD to secure erase a file, good luck recovering it when you do that. See an example on this site.
Here is the command to secure wipe a file (Adjust the bs=xx
parameter)
dd if=/dev/urandom of=/tmp/test/myfile.txt bs=27 count=1 conv=notrunc
where bs=##
is how much random data to write to a file in bytes (must match the size of the file being overwritten, enter file size in bytes as seen in ls -l
command)
edited Feb 14 at 8:16
Mr Shunz
2,49131922
2,49131922
answered Feb 14 at 6:49
user924554user924554
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f57572%2fhow-to-delete-files-in-secure-manner%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Unfortunately bounty was awarded automatically even though no answer seems to apply to the age of SSD very tightly. With SSD bytes aren't really overwritten (unless you go for entire drive procedures) unless a drive manufacturer specific API call is made, if at all it can. See the article quoted in one of the answers.
– matt
Jul 25 '18 at 8:35