Matt & all, Although I have no problems with having the this discussion on the mailing list, I will object to having it in the standard itself. Standards are not an appropriate medium for this type of discussion. Counting "how many bits are leaked after 2^64 blocks" may be an amusing past-time, but in my view it is utterly irrelevant for anyone wanting to actually use the standard. (I will spare you the back-of-an-envelope calculation of how long does it take to send 2^64 blocks over a 100 Gbit/sec link.)
> [...] CBC mode will on average leak about 128 bits of plaintext after > 2^64 blocks [...] > From looking at LRW mode, it looks like it will probably leak > less information than ECB mode, but will likely leak more > information than CTR mode, and possibly even more information > than CBC mode. > [...] > As outlined in my previous e-mail, LRW mode will leak 128 bits of > plaintext for every detected collision. This answer your question, doesn't it? > Theoretically, the birthday limit could even be reduced with a > perfectly random K2, a certain percentage of the time. For > example, there is a 1 in 2^16 (1 in 65536) chance that the most > significant 16 bits will be zero for a perfect random number. In > this situation, the birthday limit could be reduced by as much as > 8 bits (from 2^64 to 2^56) depending on the characteristics of > the data on disk. I don't understand what you are trying to say here. It is trivial to prove that for (X,I) != (X',I'), when you pick K2 at random and compute Y = X xor K2*I and Y' = X' xor K2*I' then you get Y=Y' with probability exactly 1/2^128. Using the union bound, it then follows that if you have N such pairs (X_i,I_i), the probability that you have even a single collision is no more than (N choose 2)/2^128. (The actual probability is of course a bit lower and it depends on the exact structure of these (X,I) pairs, but the term above is an upper bound and usually a fairly accurate one.) If this is not the answer you are looking for, can you rephrase the question so I can understand what is it that you are asking? > Writing K2 to Disk > ------------------ > There is another security concern that should be outlined in the > 1619 spec: Writing K2 to the disk. I could not understand the point of this discussion. Why would you ever write your crypto key to disk? And why do you talk about K2? >From the point of view of the application that uses LRW there is no K1 and K2, only a single LRW key. > Modification attack with K2 > --------------------------- > The 1619 spec should probably mention some of the exploits > possible if the attacker acquires K2. Why? Why not specify what the attacker can do with K1? Or with the data which is encrypted with these keys? Again, we are trying to produce a standard, not a free-form discussion document. And again, there is no K1 and K2, this is just one key that the internal LRW algorithm uses. > Keeping IVs Different Across Different Vendors > ---------------------------------------------- This discussion is relevant to the tape standard, but I don't see why it would be relevant here. > There was some talk about using > a unique vendor ID, along with a drive serial number. This was raised in the context of 1619.1, not 1619. > More Comments on the LRW Alternative Mode (LRW-ECT) > --------------------------------------------------- > I wanted to revisit the alternative LRW mode and propose it as a > stronger alternative to the current LRW mode, assuming that a > user wants a stronger security level. I disagree with the "stronger". The provable bounds that you get are the same, and the exploits if the keys are guessable are almost the same. > However, I believe it is not statistically > possible for an attacker to identify such a collision, Of course there is. A collision is just as fatal, no matter what you use to process the I component. > However, if there was a need to encrypt highly > sensitive information, and extra hardware is not a problem, then > the LRW-ECT mode would provide a provably higher security level. That's very wrong. In fact, no LRW derivative will ever buy you an "adequate level of security" because it is length-preserving (and therefore cannot be randomized and cannot have an authentication tag). LRW and all the other variants give you pretty much the best you can get with length-preserving encryption. For anything more, you need length-increasing encryption (which will probably be done at the application layer, but maybe can also be done at lower levels). I didn't see any real problem in any of Matt's posts (but I also didn't understand parts of these posts), and I do not see any real difference between the security of the LRW variants. -- Shai
