full-disclosure - Gutmann's research paper today

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: <200602071507.k17F7cQq008368@turing-police.cc.vt.edu>
Date: Tue Feb  7 15:07:46 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Gutmann's research paper today 

On Tue, 07 Feb 2006 15:44:37 +0100, gimeshell@....de said:

> Am i misunderstanding something or you can really say, if you're
> writing to a modern disk, forget all special scrubbing technologies,
> don't use Gutmann, don't use DoS 5220.22M or other pattern writing
> technologies, only a few passes of random scrubbing will do the job?

DoD 5220.22M only requires 3 passes and verify of each pass - all zeros, all
ones, and all "the same character" (for instance, 'AAAAAAA..' or similar).
That's good for sanitizing disks up to Secret.  For anything higher, physical
destruction is mandated. A "few passes of random scrubbing" is probably
equivalent to 5220.22M for any realistic usage.

One place where "random scrubbing" falls down is the requirement to *verify*
that the blocks were written.  If you wrote a disk full of zeros, it's a
trivial matter to read it back and verify that all the bytes are zeros.  If you
wrote a whole disk of pseudo-random, then you have to regenerate the entire
pseudo-random data stream in order to compare it....

And yes, the verify step is important - I've had more than one disk drive that
was still perfectly readable, but suffered hardware damage to the write hardware.
Writing 3 passes of anything and failing to verify on such a disk would result
in a disclosure of the entire disk's contents.  Yes Virginia, there *are* disk
drive failures that will report a successful write but not actually work... ;)
-------------- 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/20060207/4da0c5b5/attachment.bin