In message <200503071106.56075.soralx@cydem.org>, soralx@cydem.org writes:


>> If you want to do something like this, you want to do sectorrenaming
>> and journaling since that means you can only see that something
>> was written but not what it was that was written.
>
>So you think that just adding specially crafted, random reads/writes
>will have no significant positive impact on security of "hot" disks?

No I don't think so, because I tried it and were able to see straight
through it myself.  The trouble is that normal disk activity is not
random.

Randomness sticks out like a sore thumb in any sort of analysis, this
is why plausible denial of existence of encrypted data is so hard
that it is almost impossible when faced with a good adversary.

>> The performance cost can be considerable and the complexity formidable.
>> There are incredibly many cornercases to handle.
>
>But you do not deny that providing strong protection for "hot" disks
>is very important? After all, user protection is only available when
>the disk is hot.

It is very important, but it is also a task which is very formidable
in comparison with protecting cold disks.  (Hint: attend BSDcan2005).

>Speaking of user protection, how did you implement the procedure of
>erasing keys? Did you account for the properties of magnetic media
>and RAM that make data recovery possible? See, for example:
>http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

No I did not, because there is no reliable way to counter it from
software.

There may have been once upon a time when that paper was written
10 years ago (although I seriously doubt the actual efficiency of
the proposed schedules), but these days with Giant Magnetoresitive head
technology and Partial Response Maximum Likelyhood decoding you can
write and write and write and you will have no idea if it works or
not.  Bad sector forwarding is another issue in this area.

There are commercial companies who have specialized in recovering
deleted data from trackfringes.

-- 
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.