Disk Partition

[zvrba at globalnet.hr]

On Sun, Oct 09, 2005 at 03:11:56PM +0000, cdr wrote:
> zvrba at globalnet.hr wrote:
> >The point is that the statement about deniability is misleading (or maybe I
> >I should say, close to false). 
> 
> Zeljko, deniability has its place. It could be semantics, but perhaps you
> are not be making sufficient distinction between deniability and deception.
> 
You've written some very interesting comments. I'd like to hear your
opinion on

http://web.archive.org/web/20001206202000/http://www.rubberhose.org/

and especially on

http://web.archive.org/web/20001206202000/http://www.rubberhose.org/current/src/doc/beatings.txt

This seems to be a recent replacement for rubberhose:
http://www.freenet.org.nz/phonebook/manual.html

And please comment it in the following aspect: 

>
> In jurisdictions where such rules do not apply (even Canada, for
> instance, recently suspended habeas corpus, you can be held indefinitely,
> incommunicado; thus it is reasonable to assume you can also be tortured)
> deniability is of no particular value in conflagrations with the
> government, but it will probably be of some value if one is fighting
> with one's employer.
>

I'm really interested in your opinion.

> you may not be able to deceive anyone but the most naive attacker. However,
> you can deny, and, unless broken cryptographically, such file can not be
> *proven* to be ciphertext. This can help you, but only in instances where
>
-cut-
>
> that you can be sanctioned for failing to produce the key if and only if
> it can be proven that you are in possession of encrypted material. (Note
>
this proof actually depends on the software in use. if the software in use
1. complains on "invalid file format" when applied to non-container file, and
2. complains about "invalid password" when pointed to a container file,
   but wrong password, then:
pointing it to the suspicious container AND giving a wrong password is a
proof[1] that you have encrypted data on your disk.

If either check is removed and the software blindly proceeds with
whatever consequences (crashing the kernel, corrupting data, etc..) then
nobody can actually prove that there is something encrypted in the file.
However, such tool would be very dangerous to use.

[1] Minus the very small probability of the file having the "right"
header but not being a container file. The probability decreases
exponentially with the length of the header.

If you don't want to use such a dangerous tool, you can produce many
containers having just random junk inside, some of them pseudo-secret
data like "love" emails.. Many as in 10s of thousands, and random file names.
For some of them you remember passwords, for most of them you don't (nobody
reasonable can expect you to remember 10s of thousands passwords).

In such setup it really depends how much a person is willing to endure
to keep the data secret.

> 
> In short, deniability is a valid claim, and can be a useful characteristic
> of ciphertext in specific, well-defined instances.
> 
In any case, IMHO, deceipt and deniability are much more complicated
than having a single encrypted container on your disk. Thanks for
shedding some light on the subject, but I still think that the following
sentence given on TrueCrypt's web site:

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

is a gross oversimplification of deniability and deceipt.

Thanks for your time.
Best regards,
  Zeljko.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20051009/0b50fa08/attachment-0001.pgp