Rob, This is a nice summary of the differences between P1619 and P1619.2. I see a few points differently, though:
> LRW was designed to protect against this shared use of the crypto "oracle". It does not protect against it. LRW prevents copy-and-paste attacks, and the manipulation of the plaintext or the ciphertext will not result in *fully* predictable changes of the other. However, being a one-to-one mapping, one important manipulation is still possible: changing the ciphertext will cause the deciphered plaintext to be different. Therefore, it is not true, that the plaintext is *randomized*, contrary to the common believes. > Because of the environment being protected, there was the additional > requirement that LRW be length-preserving. I don't think this requirement has anything to do with environment protection ;-) . It is only a practical convenience, and its importance is controversial. > Access to the crypto will be equivalent to access to the entire disk. If you can plug the cable from the disk to another (non-encrypting) controller, you have full access to the ciphertext, but no access to the crypto. The difference is here, if you can tie the crypto to the medium, you can have controlled access, otherwise we have shared media. Laszlo > -------- Original Message -------- > Subject: Shared media for LRW means shared cryypto access > From: "Rob Ewan" <[EMAIL PROTECTED]> > Date: Wed, May 24, 2006 10:01 am > To: <[EMAIL PROTECTED]> > Cc: "Rob Ewan" <[EMAIL PROTECTED]> > > In terms of the way LRW was designed, shared access is considered to be > multiple agents having plaintext access to different zones of the > protected media. The threat model assumes that the attacker is an agent > who has plaintext access to part of the media and ciphertext access to > the entire media. Depending on the specific attack (confidentiality or > integrity breach), the attacker may need read/write access to the > ciphertext, or simply read access to the ciphertext. > > LRW was designed to protect against this shared use of the crypto > "oracle", which is why it provides a tweak on both sides of the AES and > why the tweak key must be part of the secret. > > Because of the environment being protected, there was the additional > requirement that LRW be length-preserving, but this is a practical > matter, as opposed to a security matter. > > Note: If the attacker does not have any plaintext access to any portion > of the media (i.e. if the attacker cannot use the crypto "oracle"), > which I believe is the case for 1619.2, the threat model changes. Since > the attacker has no access to the crypto "oracle", he will not be able > to read any data. Access to the crypto will be equivalent to access to > the entire disk. This means the crypto mode could be simpler than LRW in > that case. > > ..Rob
