Shai, Is the plaintext randomized? This is a manifestation of the language issue. If you look at the post, it should be clear what I meant: You can tell for sure, if the ciphertext was changed (knowing the original plaintext). There is nothing random in that. You imply that I said something about the information content of the deciphered new plaintext, which is not true. Was not it better to point out that this use of words could be misinterpreted (by those, who take it out of context), instead of calling it a false statement?
> [own key encryption] using a cipher such as AES in this > manner means that you operate "outside the warranty" of the cipher You repeated what I wrote. Is there any known exploit in the common encryption modes, except in LRW? > architecture that allows you to encrypt a key with itself is just wrong. I think it is not an architecture question, but policy. There is nothing in the P1619 "architecture", which prevents it, only a remark in the annex. If it is a mandatory requirement, it should appear in the main body of the text. Other encryption modes can get away with a warning about the unexplored dangers. > The specific issue with LRW that is described in the annex can be easily > handled by an application. No doubt about it, but you have to tell the writer of that application, who can be my 85 years old mother, assembling information into a database. The problem is not with the professional applications, but with an average user putting together a simple script or a database. He does not know what encryption mode his secure drive uses, if there are any restrictions about the stored information. It is common sense to use high entropy keys, but is it also common sense not to save a file with his keys on a supposedly secure disk drive? They cannot save it anywhere else, but encoding or splitting the keys is not at all obvious for them. Some of them will write a 10-line Windows script, which stores keys on disk, others may just fall victim of critical memory swapped to disk in the wrong moment. I understand, it is not your concern, since you put a sentence in the annex, but it will be our concern, if his laptop is stolen and his secrets are revealed. He will complain and may sue the disk manufacturer. Some of our customers do believe that this is a real weakness of LRW (larger vulnerability to user errors than other tweaking schemes). So far I have not heard an argument, which would convince them otherwise. > standard never suggests that LRW-AES protects fully against ciphertext > manipulation attacks, in fact the standard explicitly explain why it > does not. This is why I asked, don't take the note out of context. You react as if I was saying something new about LRW-AES, but it was in response to a proposed sentence, which could have been interpreted to say that LRW-AES does protect against ciphertext manipulation attacks. I said the same thing as you do, that it is "misleading to suggest that LRW-AES protects fully against ciphertext manipulation attacks." I did not find an explicit explanation in the D5 text. (Dependent on what you call an "attack". Destruction is not considered as one, because it does not reveal secrets and does not lead to meaningful data modification.) The sentence we were discussing showed that even if an explicit explanation was there, it was not clear for most readers, therefore, some more explicit explanations are necessary. Laszlo > -------- Original Message -------- > Subject: Re: Shared media for LRW means shared cryypto access > From: Shai Halevi <[EMAIL PROTECTED]> > Date: Thu, May 25, 2006 12:13 pm > To: SISWG <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] wrote: > > [...] The malleability of narrow block ciphers is such an issue. > > I never said it wasn't, but this is very different than claiming that > "it is not true that the plaintext is *randomized*, contrary to the > common believes." > > The plaintext is randomized, but this still leaves malleability issues > as described (for example) in the annex of the standard. Discussing when > these issues pose real problems and what can be done to counter such > problems would be valuable (both to the group and potentially to your > customers). Claiming that the plaintext is not randomized is just a false > statement which is not valuable to anyone. > > >> 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. > > I believe that I did say why in the meeting this week: An architecture > that allows you to encrypt a key with itself is just wrong. Regardless > of the mode of operation in use, using a cipher such as AES in this > manner means that you operate "outside the warranty" of the cipher. > (Ciphers are never built to be secure when they encrypt their own key.) > The specific issue with LRW that is described in the annex can be easily > handled by an application. (Just one silly example: split your key K > in two pieces, one piece is a random R and the other is R+K). But an > architecture that allows an application to face this issue should never > have been used in the first place. As a general principle, keys are > always more sensitive than data and should be handled differently. > A hierarchy is ok, but cycles should never occur. > > On a more practical level, I have seen quite a few architectures for > key management over the years, and not of them had that issue. This > is not to say that there aren't architectures out there are designed > badly enough to have this issue, but I am sure that (a) they are not > common, and (b) any design which is that bad would have also many other > problems. > > > >> 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. > > And the exact same knowledge is leaked also when you have "true > randomization" (and even when you are using a truly authenticated > encryption mode). Assuming (as I am) that in the context of this standard > we can always use truly authenticated encryption as "the best we can hope > to achieve", this means that this concern is outside the scope. Nothing > that you can do at this level can address it, so it must be addressed > at a different level (either via access control on the media or via some > encoding scheme at the application, or whatever). > > > > 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." > > This is why I spent many hours last winter writing (what I think is) a > very detailed security-analysis/rationale annex for this standard. The > standard never suggests that LRW-AES protects fully against ciphertext > manipulation attacks, in fact the standard explicitly explain why it > does not. > > -- Shai
