# shred with ext3

## BruteForce

Hi all,

I read several posts concerning the effectiveness of shred an similar tools when it comes to deletion of single files. The most spread opinion is, that it does not work as usual. But when I read the man pages of shred, they state:

 *Quote:*   

> 
> 
> In the case of ext3 file systems, the  above  disclaimer [that it don't work on journaling file systems]  applies  (and shred  is  thus  of  limited  effectiveness) only in data=journal mode, which journals file data in addition to just  metadata. In  both  the data=ordered  (default) and data=writeback modes, shred works as usual.

 

Ok, my question is: Keeps gentoo the default mode and can I look up what my system is currently using? If it is in the ordered mode, shreed should have done it's job, shouldn't it? It's strange, that nobody pointed to this man page in the other discussions. Is the information in the man page crap?

Thanks a lot,

Richard

----------

## frostschutz

The main problem regarding secure deletion on a file by file basis is not wether the filesystem is journaled or not, but wether the file was ever modified or not.

Take for example a text file. Every time you edit something and save the file, what actually happens that the old file gets deleted, and a new file with the same name takes its place. The new file is likely to be stored in a completely different physical location on the disk, meaning that the old version of the file contents still exists, even if the filesystem now sees it as free space. As files are usually something you work with, not create once and never touch again, chances are that you have several copies of your files floating around in the unallocated space of your filesystem.

What good is it, shredding the file the file system knows and sees, when old copies are still there? shred does not help you with that. 

An alternative to shred would be simply deleting the file and then overwriting all free space, however with modern harddisks and huge partition sizes this would mean that for secure deletion of no matter of how small a file, you'd have to overwrite gigabytes of free space, taking hours of time. And even then it's possible that due to filesystem structures, overhead, and root reserves, not all free space can really be allocated and thus overwritten.

Software like shred and bcwipe is not very useful in general. They lure you into a false sense of security, claiming that they deleted something, when there is actually no guarantee for that at all. The only safe way to delete is to overwrite the whole disk sector by sector, and for that you don't need a special software, you can just use 'dd if=/dev/zero of=/dev/harddisk bs=1M' once and be done with it. There is no way to restore any data after that.

----------

## simon_irl

re ordered/writeback modes: /etc/fstab tells your system how to mount its filesystems. among the options for your ext3 filesystems (options like "noatime") you want

```
data=writeback
```

to ensure your ext3 partitions are not using the slower data journalling mode.

as for frostschutz's comment, that's a good point: tools like shred overwrite existing, 'visible' files, but there may be 'deleted' versions or portions of those same files all over the disk, and so these tools probably do give a false sense of security. i suppose you can

```
cat /dev/zero > hugefile
```

and then shred hugefile when it's filled up the whole partition...but that would take a LONG time! maybe you should just keep your sensitive data on an encrypted partition and either shred or avoid using swap files/partitions? or look into steganography if you're really paranoid. better still, commit the sensitive data to (your own) memory!   :Very Happy: 

----------

## frostschutz

 *simon_irl wrote:*   

> and then shred hugefile when it's filled up the whole partition

 

No need to overwrite free space a second time... just sync (so it actually gets written) and then delete hugefile.

----------

## yabbadabbadont

Even then, modern hard drives often do sector relocation on the fly when problems are detected.  And the original sector(s) won't be overwritten by the dd command.  The only truly secure way of destroying data these days, it to physically destroy the media on which the data resides.

----------

