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