| 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
| ||
|
Date: Tue Feb 7 16:16:47 2006 From: frank at knobbe.us (Frank Knobbe) Subject: Gutmann's research paper today On Tue, 2006-02-07 at 10:07 -0500, Valdis.Kletnieks@...edu wrote: > 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.... Shouldn't you be able to do that cluster by cluster? Grab 1024 or random, write it, then read it and verify? Alternatively, more stream based, you could dd /dev/random, tee that to the drive and pipe the other stream into md5. Take note of the hash. At the end, dd the drive into md5 and compare the resulting hash. I'm performing backups where the stream is tee'ed to the drive and into md5 for hash creation. Works great with tapes, should work for drives too. Cheers, Frank -- It is said that the Internet is a public utility. As such, it is best compared to a sewer. A big, fat pipe with a bunch of crap sloshing against your ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060207/2a0c9b98/attachment.bin
Powered by blists - more mailing lists