>
>> 1) If you're doing analysis of a cold disk, it is ~trivial to tell
>> the difference between a sector that has been written only once and
>> a sector that has been rewritten.
>
>This is hardly trivial, you are basing your statement on the false
>assumption that one cannot or will not do anything to protect the
>encrypted image after the initialization. One can do a lot.
>
>For example, one can regularly scrub the unused areas around the
>encrypted image (padding) with dd(1) using if=/dev/{u,}random and
>similar. This can be fully automated with a cron job.
>
>One can also regularly scatter files with misleading names and
>contents. 

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

There are two plots shown in the file.  In both, the X axis is the 
entropy per sector (to two digits past the decimal point); the Y axis 
is the number of sectors that had that entropy.  The first graph is of 
the entire NetBSD partition on my laptop.  The only difference is that 
in the second, graph, I deleted the sectors with 0 entropy -- those 
were about 25% of the disk.  (The disk is 2/3 full.)  For calibration, 
I ran the same tool on 100,000 blocks of /dev/urandom output; the 
lowest entropy I got was about 7.4.  

Quantitatively, if you pick a block at random and use 7.4 as the 
cut-off for "random", you have about a 77% chance of hitting a 
non-random, i.e., plaintext block.  I have some directories which I 
suspect have files of high entropy (mp3s, jpgs, .tgz files, a cgd 
partition); if I exclude those -- a not-unreasonable move for certain 
classes of disks -- you have a 98% chance of hitting a plaintext block. 
(Caveat: that analysis is very preliminary; I have not yet actually 
measured the entropy of those file types.  Note the large hump between 
3.5 and 6 on the second graph; it may be that some of those directories 
fall in there.)

Anyway -- the moral of the story is that you really need to analyze 
your environment and your threat model when designing crypto.  The 
answer to SAN link eavesdropping might be IPsec or link encryptors; the 
answer to cleaning lady attacks might be cleared personnel, two party 
rules, or other non-crypto solutions.  But don't assume, and don't say 
"one can" or "one should".  (As a footnote, I realized that my own cgd 
"partition" (via vnd) was created from /dev/zero instead of /dev/urandom;
the result is that the entropy of the file itself reveals almost 
exactly how much of the cgd partition is in use.  I'll have to correct 
that....)

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb