Prev: Entropy of a password
Next: A Dissembler to Remember
From: Ohm on 27 Dec 2009 02:55
I am faced with the following problem.

Today I read Truecrypt manual from A-Z and I see that they recommend the
first 1024 bits of the keyfile to have enough entropy.

I have already encrypted sensitive information on a CD, that data is to be
opened
with a keyfile but I do not know if the keyfile I have chosen has enough
entropy
or not.

How can I check or approximately find out the entropy of my keyfile?

Many thanks
From: Ohm on 28 Dec 2009 19:00
> Ohm wrote:
>
>> How can I check or approximately find out the entropy of my keyfile?
>
> I'm afraid you can't. Decrypt your partition, generate a new keyfile
> using a strong
> random generator (/dev/random or similar) and re-encrypt.
>

My idea was to use an already existing keyfile that can easily be
camouflaged as an MP3 or PDF or ZIP or something like this, and not
having around a .random file exclusively used for encryption.

Truecrypt manual says that they recommend to use a compressed file as
they have more entropy but I see there is no way of working out how good
that file entropy is.
From: unruh on 28 Dec 2009 19:23
On 2009-12-29, Ohm <Ohm(a)no.no> wrote:
>> Ohm wrote:
>>
>>> How can I check or approximately find out the entropy of my keyfile?
>>
>> I'm afraid you can't. Decrypt your partition, generate a new keyfile
>> using a strong
>> random generator (/dev/random or similar) and re-encrypt.
>>
>
> My idea was to use an already existing keyfile that can easily be
> camouflaged as an MP3 or PDF or ZIP or something like this, and not
> having around a .random file exclusively used for encryption.
>
> Truecrypt manual says that they recommend to use a compressed file as
> they have more entropy but I see there is no way of working out how good
> that file entropy is.

Typically entropy is defined by a process, not an instance. There have
been attempts to define the entropy of an instance (eg, the length of
the shortest program required to output that instance. It is bounded of
course by
print(".....") where ... is the string for that instance, but there may
be a much shorter program. It of course depends on the language. The
language could contain precisely the string you want as the output, and
signaled by only a one byte instruction. That was why I said entropy is
relative.
On the other hand one can define the entropy of a string as an instance
of a process. In that case one can define the entropy of the output as
the probability of that output given a random input.


From: Ilmari Karonen on 29 Dec 2009 02:52
On 2009-12-29, Ohm <Ohm(a)no.no> wrote:
>
> My idea was to use an already existing keyfile that can easily be
> camouflaged as an MP3 or PDF or ZIP or something like this, and not
> having around a .random file exclusively used for encryption.
>
> Truecrypt manual says that they recommend to use a compressed file as
> they have more entropy but I see there is no way of working out how good
> that file entropy is.

As noted, Shannon entropy is defined for probability distributions,
not for single values. A statement like "compressed binary files have
more entropy than text files" is indeed generally true, but only in
the sense that the entropy of the distribution of (initial N byte
segments of) randomly chosen compressed binary files is typically far
higher than that of the corresponding distribution for text files,
given a sufficiently large supply of both to choose from.

However, keep in mind that, if you store your keyfile unencrypted on
your computer, an attacker can just precalculate a hash of each file
on your disk and apply them all in sequence to each password they try.
Thus, such a keyfile slows down an attacker by at most a constant
factor equal to the number of files on your computer (minus any
temporary or system files that you're not likely to use as a keyfile
since they might change unexpectedly, which reduces the number a lot).

Using multiple keyfiles does raise this factor to the N-th power,
where N is the number of keyfiles. Still, it's not a very efficient
way to add entropy to your key: picking one additional keyfile out of,
say, a collection of 1000 MP3 files makes brute forcing the key 1000
times harder -- which may sound impressive, but is actually less than
the effect of adding, say, one randomly chosen four letter English
word to your passphrase.

Of course, if the attacker doesn't have your keyfile -- say, if you
keep it on a USB stick and somehow make sure the attackers can't get
the stick -- then they're basically out of luck. But that's quite a
big if.

(BTW, I just looked up Truecrypt keyfiles on their web site. If I
understood it correctly, their design seems to make the job of an
attacker somewhat easier, since the keyfiles are first hashed and the
hashes then combined linearly with each other and the passphrase.
This means that an attacker need only precompute the hashes once and
store them, after which they no longer need the actual files. Using a
hashing scheme where all the computations depended nonlinearly on the
passphrase would deny attackers this optimization.)

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
 | 
Pages: 1
Prev: Entropy of a password
Next: A Dissembler to Remember