>>this opens the door for an easy attack on the AES to get K1. If there was a weakness in AES in ECB mode. None is known, so there is no argument against allowing I = 0.
>>never envisaged this mapping being done in hardware In software what is the difference if you use a long or a short shift? They just need a different pre-computed constant. >>The interface would be the I vector, since LRW is defined like that, not in >>terms of LBAs Here I see a problem. I always assumed that an encrypted disk drive behaves like a huge file, where you modify blocks, the LBA's. If you want to transfer I, or any other index than LBA together with a block of data, there is no chance it would ever be implemented. We need a new ATA/SCSI command syntax, which has to be accepted by T10/T13, and which syntax has no advantage over the existing one, but breaks compatibility with old drives. If it is really the intention of the standard, we can stop right now, saving our time on discussing something a disk manufacturer cannot implement. >>if the encryption of odd-sized sectors can be engineered to not use a 33rd >>tweak value (for example), the problem would go away No. LBA's can have any size, not only a power of two. The problem is not with 33, but with any odd size LBA. The 520 byte LBA was just an example, which is often used. >>Outside of the disk you probably don't get the ability to start the seek for >>a write It looks like I need to write a more extensive explanation, why it is not a good idea to implement LRW outside of the disk. I wrote about it several times, but it gets just ignored. So give me a couple of hours, I will post it. >>What about a RAID application If the encryption is done in each individual disk drive, you just have to provide a different key for each. They can be K, K+1, K+2,... Since the encryption is transparent, the controller does not have to do anything different than before, except providing the keys to the drives at power up. If you encrypt in the controller, I will explain why the security is weaker. >>How about defining the top byte of I to be a drive index It can be done. We need yet another new disk command, or, modify the not yet defined one, which transfers the keys to the drive: (K1, K2, Drive_index). It allows you to use the same K1 and K2 keys for different drives. It does not add much to the security, since you could always use different (but related) keys without any significant danger of collision. Laszlo > -------- Original Message -------- > Subject: RE: LBA-shift, extra bytes > From: "Colin Sinclair" <[EMAIL PROTECTED]> > Date: Thu, December 15, 2005 1:10 pm > To: <[EMAIL PROTECTED]> > > > 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.
