Disk Partition

[zvrba at globalnet.hr]

On Sat, Oct 08, 2005 at 08:01:15PM +0400, lusfert wrote:
> zvrba at globalnet.hr wrote:
> > On Sat, Oct 08, 2005 at 04:30:41PM +0400, lusfert wrote:
> > 
> >>I know 2 cross-platform solutions: CrossCrypt
> >>
> > 
> > A quote from the CrossCrypt homepage: "Denaiablity: You will not be able
> > to tell that this file has been encrypted by filedisk as it looks
> > completely random and can have any extension you wish."
> > 
> > IMHO, There is a problem in that the data looks TOO MUCH random, i.e. it has
> > much higher entropy than would result by "normal" computer usage. Such high 
> > entropy is a strong indication that the data is encrypted.
> 
> Then you should use stenographic programs together with cryptographic. ;)
> 
The point is that the statement about deniability is misleading (or maybe I
I should say, close to false). In some scenarios (when it comes to e.g.
court cases, or even blackmails or life threats), the person using this
product in good faith (believing that the encryption really _is_ deniable)
would be in a very bad position.

Explaining a large quantity of high-entropy data in a plausible manner is
extremely hard. The presence of such data gives a strong indication of
encryption. If you argue that you used some "secure delete program",
then you're _again_ in a bad position because it implies that you have
to hide something and again raise suspicion.

So, instead of teaching me what kind of software should I use, can you
please give an example of plausible explanation for large amount of
high-entropy data on the disk? And have in mind a very determined,
knowledgeable and resourceful adversary while constructing the explanation.

Yeah, I see the smiley, but these things should be taken very seriously
and not to be joked with. There are cases where people put their freedom
(maybe even life!) in the hands (bits?) of some cryptographic SW and if
that SW actually fails to deliver what it promises, then it's very bad
for the person trusting it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20051008/cdf8b579/attachment-0001.pgp