Re: Loop-AES vs. PPDD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> On Wed, 9 Jun 2004 20:57:38 +0200, "newbie" <tacron@xxxxxxx> said:

[ ... ]

tacron> Could you please answer the question?

> Sorry, my guess is that the question is pointless/unanswerable. [...]

tacron> The "could you please answer the question" referred to 17 keys
tacron> ppdd vs. 64 keys loop-aes.

Yes, and I replied precisely on that point (wans't it throughly clear?).

I reckon that 17 vs. 64 question is pointless and unanswerable because
of all the reasons I have already given, mostly that without knowing
that kind of attacks etc. such small details are very difficult
evaluate.

>> Consider this argument, which is not necessarily good, but to me seems
>> to have some merit in some cases: having many keys, no matter whether 17
>> or 64, means that probably they cannot be easily memorized. If they
>> cannot, they have to be stored _somewhere_, encrypted with a key that
>> has to be memorized (all this said with a particular but obvious family
>> of cryptosystem architectures in mind).
>> 
>> Does this improve or reduce ``security'' whatever that is? It's not so
>> obvious, and may depend quite a bit on the threat model, because it
>> seems to me that it trades off some data crypto hazards for some key
>> management hazards.

tacron> I guess it improves. Even if you use 17 or 64 keys and not one
tacron> for encrypting the sectors, you still have an incredibly large
tacron> amount of data for statistical, differential or probabilistic
tacron> attacks in the future.

Looks like a rather wild guess to me, because I think it is more or less
pointless to make any guess as to such details without making some
assumptions about the cryptosystem and the threat model, and the costs.

For example, switching from 1 to N>>1 keys means that key management
becomes a bigger task, and this may lead to reduced ``security'' under
some plausible threat scenarios (see below).

>> Maybe if you have a single not too complex key you can just hold it
>> in your head. Given that some plausible threat models are mostly
>> about key management mishaps, this might be more ``secure'' than
>> storing the vector of real encryption keys somewhere outside your
>> head, and keeping in your head just the passphrase with which you
>> encrypt that.

tacron> Hmm, maybe you're getting something wrong here. Having more keys
tacron> to encrypt the sectors seems to be better than just using one
tacron> key or 17 or 64 keys.

Under which assumption? Under the assumption that you will never ever
have key management issues/threats? Encrypting the data is a small part
of a cryptosystem, and if one strengthens that at the expense of other
aspects perhaps there is an overall loss.

So, is it worth trading off the possibility of a linear (17, 64, ...)
factor of improved data ``security'' against the possibility of much
bigger problems with key ``security''? It all depends on cryptosystem
architecture, threat model and costs.

For example, suppose that part of the threat model is that the
adversary's goals are to gain access to the plaintext, or else *to deny
that access to you*.

The adversary has the added opportunity to impair/steal/destroy the
medium on which you have stored the many keys to achieve success, which
might be also much easier than trying to decrypt.

Is it worth to make it possibly harder for the adversary to gain access
to the plaintext if the price it to make it possibly easier for her to
deny that access to you? It all depends...

[ ... ]

  tacron> becomes only a problem when encrypting every sector with a
  tacron> single key.

>> This statement seems to me to be based on the assumption that what is
>> relevant is block size vs. *percentage* (100% vs. 5.9% or 1.5% or ...,
>> depending on the number of keys) instead of absolute quantity (and
>> likelyhood of known plaintext in it) of ciphertext potentially available
>> to an adversary. [ ... ]

tacron> No. it relates to "although the 64-bit block size is now
tacron> considered too short, because encrypting more than 232 data
tacron> blocks can begin to leak information about the plaintext"
tacron> http://en.wikipedia.org/wiki/Blowfish_%28cipher%29 However, I
tacron> don't know when this 2^32 (around 4 billion) blocks is reached.

But this does say that the issue with block size is related not to
percentage of ciphertext encrypted with one key, but to the _absolute_
amount of ciphertext encrypted with one key. With a 64 bit block size
there is a high probability of exploitable (``birthday'' attack) repeats
after 2^(64/2) 8 byte blocks (a bit over 30GB) have been encrypted:

  http://LASECWWW.EPFL.CH/birthday.shtml

What matters is not how many keys have been used (that is, the
percentage of data encrypted with one key), but whether each key has
been used to encrypt more than 2^(64/2) blocks.

Having multiple keys for much larger partitions reduces the _absolute_
quantity of data encrypted with one key for a given _absolute_ size of
the partition, but that's an indirect effect.

If the total amount of data is less than 30GB then "encrypting every
sector with a single key" is not that big a problem wrt to ``birthday''
attacks; conversely, even with multiple keys, if each key is used to
encrypt more than 32GB there might be problems.

Note also that the leakage might be described as pretty small (a few
bytes out of 30GB), and might not matter that much compared to other
problems caused by the very large amount of data available, and to the
high likelyhood that in a filesystem there is known plaintext at known
sector offsets.

Also, in disk encryptors there may be a different IV per sector (its not
quite CBC mode), which perhaps makes things different, and the plaintext
may not have easily guessable statistical properties (much of it may be
compressed or other binaries), so I don't really know if the possibility
of ``birthday attacks'' is that relevant. As usual, it all depends on
the context...

Sure,, every little helps an adversary, but again what matters is to get
a ``sufficient'' level of ``security'', given expected cryptosystem,
threats and costs.

As a personal opinion, the 64-bit block issue with Blowfish is so
pointless, because there are significant reasons to go with AES
regardless, similar to those described here:

  http://groups.Google.com/groups?selm=bug3qh%24281q%241%40agate.berkeley.edu

[ ... ]


-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux