Shai, > I don't enjoy this argument one bit. I am sorry to have bothered you. Maybe somebody else would answer then. I also envy you: It never mattered, if I enjoyed an argument or not, if it had to clear an issue a customer voiced. The malleability of narrow block ciphers is such an issue. I have to give them an answer, to my best knowledge. I thought I knew it, but to be sure, it looked necessary to hear the opinions of experts.
> please stop raising red-herring issues (such as "encrypting your own key") Again, I am sorry, but I have to. I get paid to clear security related questions our customers have or might have. It does not help me, if some members of the WG classify them as red-herring, without saying why. So, is there anybody in the reflector who can explain me, why the own-key encryption is a red-herring, so I can then tell our customers the story in a more polite manner? I try to guess, what issue is the red-herring. As far as I remember I raised two related points. 1. The restriction in the draft P1619 proposal, that the "LRW-AES transform should not be used to encrypt its own secret-key" (Section C.5, p.27). It poses some restrictions about the actions of the user. Other encryption modes are "only" outside of their specifications, but we have no proof about their security, so a similar action is only dangerous, but we have a known attack on LRW-AES in this case. This is a difference, is not it? 2. I thought the weakness is still there, if instead of the key, its multiples are stored on the encrypted storage device. Is this a red-herring? If the user has a database of his encryption keys, some might be stored on disk shifted, which is still bad. Or is it OK? Or does the WG think it never happens? It could, if there are multiple key scopes, and the PC is used to load the key to its encryption module. In this case the key could appear in the clear, just before it gets loaded. Care has to be taken, that the memory will not be swapped to disk by the OS. Is not it a possible problem, we have to tell at least the customer service and the software developers? We have to deal with real life security, not cryptographic problems. People make mistakes and we cannot just say, a lost secret was their fault. Also, an attack against a secure storage device is not necessarily what a theoretical cryptographer would classify as an attack. If some deliberate action of a person leads to revelation of secrets and/or data modification in a predictable manner, we call it an attack. Coming back to the "attack" problem: I think we have a simple language issue: I might not have expressed the concept clearly enough. > making false claims (such as the "one bit" claim) I never said that an attacker gets one bit information about the plaintext or the ciphertext, but the test in the file receives "one bit information: change happened". The block it checks is either 0 or not. This is one bit information about the existence of ciphertext change, with the implicit knowledge that the original content was 0. > you never described an attack You are right, it was a very informal description. I thought I can speak in terms I do with my colleagues, who deal with real-life security problems. Obviously, I was wrong. I make an attempt to put it in a little more precise setting, but I don't have time to formalize it completely. Most of the security people understood the very first, informal description, already. The attack has several steps, and relies on external knowledge, like file system, file store strategies, "normal" user behavior, etc. which is hard to assign probabilities, but there are experiments, typical cases, etc. (1) Make a snapshot of the encrypted disk. (2) Make the user to store a specially crafted file on the encrypted disk, which have two different modes. One mode is if its second 16-byte block is 0, another if this is not zero. The actual value of the block is ignored. The initial value of the second block is all 0. (3) Access the encrypted disk, to find the file. Now you can ask, what is the probability that the freshly saved file is located properly? This is a very hard mathematical problem, requiring modeling the user behavior, the OS, the environment, etc. Nobody even attempted to do it precisely. We know, that Windows stores the file, whenever it can, in contiguous sectors, in a block of empty (deleted) sectors, which is the smallest, but large enough. It means that there is a "large" chance that we find a sequence of consecutive sectors of the length of our file, which are changed from the last snapshot, and it is "very" likely our file. So, the end results of these that the probability of locating a large file, freshly saved is about, say, 10 to 30%. Hackers tell you their findings, how they come to their experimental probabilities, etc. But it is not a small probability, like 10^-19. Even a trivial estimate based on the encountered number of changed blocks give a much larger value. (4) Change the second cipher block of the just found file. The attack is complete, your special file is now in its second mode, but when it was stored, it was in the first mode. It means, specially crafted files can be changed in predictable and meaningful manner. Please point out, which step of the attack is not clear, and I will try to explain that part a little more. And also, as I said, this is only an illustrative example. Real hackers will surely can modify and improve it. And please, please, don't take the whole issue out of context. I wrote "LRW-AES is malleable in this sense. Authentication or access control would prevent this, but they are explicitly denied. I did not say, either, that LRW-AES has a special weakness, because any encryption scheme under the above restrictions will be similarly malleable. But it was misleading to suggest that LRW-AES protects fully against ciphertext manipulation attacks." > If you claim that the this mode is lacking, please provide an attack that > fails if the mode was full authenticated encryption (as in 1619.1) but > succeeds with LRW. I just attempted it with the sector change above. But again, this attack is not specific to AES or LRW-AES. Laszlo > -------- Original Message -------- > Subject: Re: Shared media for LRW means shared cryypto access > From: Shai Halevi <[EMAIL PROTECTED]> > Date: Wed, May 24, 2006 7:33 pm > To: SISWG <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] wrote: > > [...] > > Despite of your vehement denial, we say exactly the same thing. Changing > > the ciphertext makes the deciphered plaintext different. This gives you > > exactly one bit information: change happened. A true randomization > > would give you 0 information. (Of course, for very high probability I > > could still tell if there was a change.) > > Wrong again (and this time I can prove it). One can prove that if "true > randomization" gives you "zero information" then LRW gives you something > very close to zero information (certainly not "one bit"). In fact, Liskov > et al. proved it in [LRW02]. > > > You completely misunderstood the attack. > > I couldn't "misunderstand", because you never described an attack. Had > you done that, and bothered computing its success probability, you would > have discovered that it is nearly identical between the case of LRW and > the case of "true randomization". (If you are not clear on how to give a > mathematically precise description, you can go read the LRW proof and see > how they did it.) > > > Please remember that this standard defines a mode of operation for AES. > If you claim that the this mode is lacking, please provide an attack that > fails if the mode was full authenticated encryption (as in 1619.1) but > succeeds with LRW. To be sure, there are attacks like that (and several > are discussed in Annex C of the standard). Can you contribute something > new? > > > On a less technical (and more personal) note: I don't enjoy this argument > one bit. I would be very happy to discuss advantages and disadvantages of > length-preserving encryption in general and narrow-block encryption such > as LRW in particular (and I agree that there are many shortcomings). > But please stop raising red-herring issues (such as "encrypting your own > key") and making false claims (such as the "one bit" claim). I have > better things to do with my time then chasing these claims all over the > place. With all due respect, I expect more from this discussion. > > -- Shai
