3 ms·

There is no guarantee this goes on the same sectors on the disk. I think that would only be guaranteed by a "secure delete call" to the drive's firmware. The o

There is no guarantee this goes on the same sectors on the disk. I think that would only be guaranteed by a "secure delete call" to the drive's firmware. The only way I know to securely erase the empty space on the drive is a call like "cat /dev/urandom > file; rm file". This will error once the drive is full, then be deleted.

KC8ZKF 16y ago
Disk Utility can overwrite empty space on a device with zeros. It also has the dubious 7 and 35 pass overwrite options.
- atomical 16y ago
  Why dubious?
  - timdoug 16y ago
    http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html "In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, 'A good scrubbing with random data will do about as well as can be expected'. This was true in 1996, and is still true now."
mustpax 16y ago
Interesting. But that would only be true for journaling file systems right? Or are there consumer hard disk drives that transparently journal writes a la ssd's?
- pmorici 16y ago
  Newer generations of SSD's have a command called "TRIM". It is meant as a way to speed up SSD drives by alerting the drive to blocks that are no longer in use by the file system and can be pre erased so to speak which makes future writes to that location faster. Windows 7 and newer versions of the Linux kernel support it.
  - chrisbolt 16y ago
    That doesn't necessarily mean it will be erased, it just gets put back in the list of unallocated blocks.
    - Someone 16y ago
      No. Flash memory is sort-of write-once in the sense that a page starts with all bits in one state. From there, you can flip individual bits to the other state, but to flip them back, you have to flip back all of them. So, to update a single bit, you may have to read a block, erase it, update the in-memory block, then write the in-memory block. The trim command will do the 'erase block' part of this procedure before the block is actually needed for data. That speeds up a future write to that block.
- tzs 16y ago
  It's not just journaling that is a problem. Some filesystems and/or operating systems will move files or parts of files to improve performance. For example OS X does some automatic defragmentation of files. Some systems move files that are frequently accessed together to be near each other on the disk. When the system does such an automatic move of a file or part of a file, does it clear out the source block on the disk, or just mark it free? If the latter, then a secure erase that just overwrites the current blocks of the file will leave those other blocks untouched in the free space. If you have a file that you must truly be able to get rid of without destroying your whole hard disk, that file should be kept encrypted on the disk, and the plaintext version should never be stored on disk. Getting rid of the file is then a simple matter of forgetting the encryption key.
Someone 16y ago
"cat /dev/urandom > file" may fail before the disk is full. I have seen a system do that because it wants to have room on the disk for e.g. log files or in-file-system swap. Also, this will not work with disk quota, and you will have to make sure that you write to the same disk as where the original files lived (think mount points) Full-disk encryption will not work in all countries, as law enforcement could imprison you if you do not give them the keys (recently happened in the UK). It also would not enable you to point at your drive and say "take a look. That file isn't there" I think the only way to do this would be with support from the file system. It would have to support two things: overwriting file data (including that in on-disk snapshots), and removing evidence that a file or directory existed with a given name. Edit: I just realize that the disk must support this, too. It could have written your data, verified the write, seen it to be unreliable, and rewritten it somewhere else on the disk. I doubt disks would keep track of links to these unreliable copies. So, in short, I doubt there is any 100% reliable way to erase data from a disk. Copying what you want to a different drive and destroying the drive probably is your best option, but that may be a bit time-consuming and expensive if you want to safely erase a single file frequently.

KC8ZKF 16y ago

Disk Utility can overwrite empty space on a device with zeros. It also has the dubious 7 and 35 pass overwrite options.

atomical 16y ago
Why dubious?
- timdoug 16y ago
  http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html "In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, 'A good scrubbing with random data will do about as well as can be expected'. This was true in 1996, and is still true now."

mustpax 16y ago

Interesting. But that would only be true for journaling file systems right? Or are there consumer hard disk drives that transparently journal writes a la ssd's?

pmorici 16y ago
Newer generations of SSD's have a command called "TRIM". It is meant as a way to speed up SSD drives by alerting the drive to blocks that are no longer in use by the file system and can be pre erased so to speak which makes future writes to that location faster. Windows 7 and newer versions of the Linux kernel support it.
- chrisbolt 16y ago
  That doesn't necessarily mean it will be erased, it just gets put back in the list of unallocated blocks.
  - Someone 16y ago
    No. Flash memory is sort-of write-once in the sense that a page starts with all bits in one state. From there, you can flip individual bits to the other state, but to flip them back, you have to flip back all of them. So, to update a single bit, you may have to read a block, erase it, update the in-memory block, then write the in-memory block. The trim command will do the 'erase block' part of this procedure before the block is actually needed for data. That speeds up a future write to that block.
tzs 16y ago
It's not just journaling that is a problem. Some filesystems and/or operating systems will move files or parts of files to improve performance. For example OS X does some automatic defragmentation of files. Some systems move files that are frequently accessed together to be near each other on the disk. When the system does such an automatic move of a file or part of a file, does it clear out the source block on the disk, or just mark it free? If the latter, then a secure erase that just overwrites the current blocks of the file will leave those other blocks untouched in the free space. If you have a file that you must truly be able to get rid of without destroying your whole hard disk, that file should be kept encrypted on the disk, and the plaintext version should never be stored on disk. Getting rid of the file is then a simple matter of forgetting the encryption key.

Someone 16y ago

"cat /dev/urandom > file" may fail before the disk is full. I have seen a system do that because it wants to have room on the disk for e.g. log files or in-file-system swap. Also, this will not work with disk quota, and you will have to make sure that you write to the same disk as where the original files lived (think mount points) Full-disk encryption will not work in all countries, as law enforcement could imprison you if you do not give them the keys (recently happened in the UK). It also would not enable you to point at your drive and say "take a look. That file isn't there" I think the only way to do this would be with support from the file system. It would have to support two things: overwriting file data (including that in on-disk snapshots), and removing evidence that a file or directory existed with a given name. Edit: I just realize that the disk must support this, too. It could have written your data, verified the write, seen it to be unreliable, and rewritten it somewhere else on the disk. I doubt disks would keep track of links to these unreliable copies. So, in short, I doubt there is any 100% reliable way to erase data from a disk. Copying what you want to a different drive and destroying the drive probably is your best option, but that may be a bit time-consuming and expensive if you want to safely erase a single file frequently.