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.