Date: Sun, 06 Mar 2005 12:51:46 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Steven M. Bellovin" <smb@cs.columbia.edu> Cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE Message-ID: <3367.1110109906@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 05 Mar 2005 11:19:32 EST." <20050305161932.8A9743BFF12@berkshire.machshav.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050305161932.8A9743BFF12@berkshire.machshav.com>, "Steven M. Bell ovin" writes: >etc. I think we need to be careful about phrases like "one can". I >decided to stop supposing and gather some real data, so I wrote some >analysis tools to measure the entropy of disk drives. I need to >rewrite some of my tools and do a lot more analysis, but I think the >results thus far are quite interesting. See >http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps I did something similar when I studied if more intricate sector placement hiding algorithms would be worthwhile. In addition to various UNIX disks I also analyzed disk images from windows server, windows laptop, s390/MVS volumes, archive disk images from an official government library and optical disk images from an archive of scanned documents. Overall, almost all the disks except the archive and mainframe disks had a "zero peak" with sectors never written to. The rest of the curve can have any shape you can imagine but will often have some number of distinct peaks for certain content types. The highest entropy I found was a disk-images from a public FTP server and a "not-quite-warez server" both of which extensively used file compression and the scanned image archive. The UNIX software developer disks had particularly low entropy because of vast amounts of source code in ASCII. My guess is that an attacker who would have access to these distribution curves for his target data would be very likely to also know more detailed/specific things about it, and that informatio would likely be much more helpful to his attack. Under the assumption that the disk is flushed with PRNG bits initially, and that the output of the cipher has high entropy too, I decided that trying to obscure these patterns, as well as the physical layout patterns of the storage managment (filesystem/ database) beyond the basic rotation, would just slow things down and not add any incremental security worth it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3367.1110109906>