> 1. Why are we trying the avoid I = 0? If I=0 then T=0 and the first block encryption is not dependent on K2. This weakens the encryption for that block, because only K1 of key pair is used. As the first block is likely to have reasonably predicatable plaintext (it is as you say likely to be the MBR in a single-disk setup), and the ciphertext is visible, this opens the door for an easy attack on the AES to get K1.
I have yet to check the original LRW paper to see what it says about I=0, but I will do so. I presume there is some original reason why the current wording in $5 of the standard defines a key scope with cipher block numbers starting at 1 - most engineers would I'm sure prefer 0. > 2. Any scheme, which shifts the LBA to the left or multiply it with a > general constant, must accommodate the largest LBA size foreseeable. > If the disk is reformatted with a different LBA size, do you want the > hardware to reconfigure itself? I never envisaged this mapping being done in hardware. The interface would be the I vector, since LRW is defined like that, not in terms of LBAs. It just helps the hardware to know what the I values do between sectors - contiguous (for any power-of-two sector size) is much preferred since as you say later the next value can be prepared in advance, but in the case of odd-sized sectors the software would just have to reissue a new I block to the hardware (unless it was customised to the sector size). I am only trying to help the software form the I value from the LBA in an easy way. Someone, somewhere, has to do it, whatever the sector size. The software is likely to know more about key scopes than the hardware, so it is right that this is done there. Ideally, if the encryption of odd-sized sectors can be engineered to not use a 33rd tweak value (for example), the problem would go away. > ...the seek time can be used to compute the initial tweak, therefore, the > multiplier never takes time when the data arrives at the buffer or it > is ready to be written. That depends on whether you are doing the LRW inside or outside the disk! Outside of the disk you probably don't get the ability to start the seek for a write (but not actually do it) whilst doing a fresh multiply. > 4... It looks easier to require the key scope is always within one drive... > If we don't enforce key scopes be within single drives, > there will be pairs of blocks between different drives, which are > encrypted with the same key and tweak value, and an attacker can tell, > if the blocks are the same or not. I don't think it is a serious leak > of information, so we could just live with it. What about a RAID application which is using multiple disks for the same thing? Surely these will have to share a key scope (or perhaps not?). In this case the I value used for each disk MUST be different. So presumaby this precludes you from implementing LRW in the drive, in this scenario. How about defining the top byte of I to be a drive index, which can be programmed via a new interface command for those drives doing internal LRW (which have to have new commands for getting the key in anyway). Does this split of key scope across drives have implications for the key backup? I'm not sure this can be standardised. Maybe some guidance needs to be added to talk about the three cases (1) single scope/disk, (2) multiple scopes (partitions) or (3) one scope over multiple disks (RAID?). Colin.
