full-disclosure - Secure Delete for Windows

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200601172215.k0HMFtoC027938@turing-police.cc.vt.edu>
Date: Tue Jan 17 22:16:09 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Secure Delete for Windows 

On Tue, 17 Jan 2006 22:12:38 +0100, GroundZero Security said:

> Our application has not only the DOD wiping standard, but also peter gutmanns algorythm 
> with 38 random overwrites, which is the most secure wiping methode we know of.

Or as Peter Gutmann says himself:

  "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."

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060117/b8de357f/attachment.bin