==> Shai > Even if the plaintext that results from changing the ciphertext was > truly random (and therefore had 1 in 2^n chance of remaining the same) > you could still know for sure when it was changed (because you will > never encounter this 1 in 2^n event).
You again repeat (in different words) what I wrote in my post: "for very high probability I could still tell if there was a change". > I will say this for the last time: from this aspect there is no > difference what do you use for encryption. You again repeat what I wrote: "any encryption scheme under the above restrictions will be similarly malleable". > Enough already. I agree. There was no reason for you to reword my comments, and make them look like your own. It just wastes our time and causes unnecessary email traffic. ==> readers of the reflector >> Is there any known exploit in the common encryption modes > There could be. In other words, Shai does not know any. Has anybody heard about a real attack on a cipher, in a specific mode, which encrypted its own key (except LRW)? > [encrypting own keys] never happens in systems out there. > Again, this is issue that (a) does not arise in "real world systems" > (unless they were architected by people who don't know what they are > doing), and (b) can be trivially solved if an application is unfortunate > enough to operate in such system. This discussion became fruitless, unless somebody else is going to share his views. Shai did not respond to any of my points. (a) This issue has arisen in real word systems (e.g. users store PGP disk keys in encrypted volumes), (aa) it has nothing to do with architecting the system, but with user actions, (b) it cannot be solved, because user scripts, applets, private databases are just that, private. > This is my definition of red herring. It might be Shai's definition of red herring, but it could cause loss of market, lawsuits, bad reputation, boycott, etc. > There is also nothing in the standard that prevents you from posting > your secret key to the web, or many other stupid things that you can do > with your key. Should we discuss them all on this list? Yes, there is something (but not in the standard) that prevents people from posting secret keys: common sense. What common sense reasoning could warn me to never process, or even just look at my keys in a Windows computer (because the OS might swap the memory to disk)? An average user does not know about these dangers. Only Shai wanted to discuss this problem. It has been acknowledged and documented. No discussion was ever needed. It is only a documentation issue. It has to be in the main body of the standard, if there is a real attack. > My (unprofessional) guess is that they believe it because it was > presented to them as a weakness. Or, maybe, they already encountered a similar problem in their software based encryption product. > [the quote from the annex] specifically says that there is no > authentication and explains exactly what happens when the attacker > modifies the ciphertext. An attack is when the attacker gains some direct advantage (otherwise it is sabotage). What is missing in the specific explanations is, how the attacker can modify messages in meaningful ways, and some estimates on its success (like possible, extremely unlikely...). The only relevant text is: "The behavior of the application on such random plaintext may be beneficial to the attacker." This "maybe" is not specific. The attack I described translates this obvious sentence to a real life exploit, with some very rough estimate of success. It is not "maybe", but a real threat. > I am now signing off of this argument because I have other things to do. Hopefully, somebody in the reflector attempts to understand the issues and gives real arguments. There was nothing else on the table, but how to word the explanation of shared media. The attack I described was an illustration of real threats, showing that exploits do exist. Apart from an unfortunate use of the word "random", there was no real argument about its viability. Laszlo > -------- Original Message -------- > Subject: Re: Shared media for LRW means shared cryypto access > From: Shai Halevi <[EMAIL PROTECTED]> > Date: Thu, May 25, 2006 5:07 pm > To: SISWG <[EMAIL PROTECTED]> > > > Is the plaintext randomized? > > Yes. > > > 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). > > You can do that with any mode of encryption. > > Even if the plaintext that results from changing the ciphertext was > truly random (and therefore had 1 in 2^n chance of remaining the same) > you could still know for sure when it was changed (because you will > never encounter this 1 in 2^n event). Even if you do authenticated > encryption you can still know for sure if the ciphertext has changed > (the decryption passes if the ciphertext is the same, and it fails > if it is not). > > I will say this for the last time: from this aspect there is no > difference what do you use for encryption. Therefore this aspect is > outside the scope of the current standard. Enough already. > > > 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? > > There could be. No one has looked at how well AES works in this mode > (because no one cares, this case never happens in systems out there). > Again, this is issue that (a) does not arise in "real world systems" > (unless they were architected by people who don't know what they are > doing), and (b) can be trivially solved if an application is unfortunate > enough to operate in such system. This is my definition of red herring. > > There is also nothing in the standard that prevents you from posting > your secret key to the web, or many other stupid things that you can do > with your key. Should we discuss them all on this list? > > > Some of our customers do believe that this is a real weakness of LRW > > (larger vulnerability to user errors than other tweaking schemes). > > My professional opinion is that they are wrong, as I explained above. > My (unprofessional) guess is that they believe it because it was > presented to them as a weakness. I believe that presenting this as > a weakness is misleading. > > > I did not find an explicit explanation in the D5 text. > > Did you look? Below is a quote from the annex. I don't know how to > be more explicit than that, it specifically says that there is no > authentication and explains exactly what happens when the attacker > modifies the ciphertext. > > I am now signing off of this argument because I have other things to do. > > -- Shai > > > IEEE P1619/D5 Annex C.1, page 24: > > ----------------------------------------------- > > But as mentioned above, even the best implementation of encryption by > > a sector-level storage device leaves some vulnerabilities. Three of > > these vulnerabilities are illustrated next. > > > > * Traffic analysis. Consider an attacker that is able to passively > > observe the communication between the encrypting device and the disk. > > Since encryption is deterministic, this attacker is able to observe > > when a certain sector is written back to disk with a different value > > than was previously read from disk. This capability may help the > > attacker in mounting an attack based on traffic analysis. > > > > * Replay. An attacker with read/write access to the encrypted disk can > > observe when a certain sector changes on the disk and then reset it > > to its previous value. (Notice that this attack is not specific to > > transparent encryption, it may work even when using randomized > > encryption with authentication tags.) > > > > * Randomizing a sector. Since there are no authentication tags, an > > attacker with write access to the encrypted disk can write an arbitrary > > ciphertext to any sector, causing an application that reads this > > sector to see a random plaintext instead of the value that was > > written to that sector. The behavior of the application on such > > random plaintext may be beneficial to the attacker.
