[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
