RE: LBA-shift, extra bytes

[Donald . P . Matthews]

>> 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).

It should not be that hard to have a register that would indicate the shift value to the hardware.  
In reality it should not be that hard to perform the ceiling function
(n = ceil(log2(j)), and j = ceil(sector_size/16)) in hardware.  If the hardware only supports 512 byte
to 4K byte sectors, then this is really one 4 shift amounts.  If the data integrity is added, then the 4K
actually becomes 4K = 8 bytes and a 5 shift amount would be needed.  It is not hard to take the LBA and
place it into an initial I register shifted by the correct amount.

>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.

For most drives, the data from the host system is placed into a buffer and that data can not be stalled
except on fixed boundaries.  If the encryption is before the buffer, the seek time does not give the
encryption engine additional time to do computations.  If the encryption engine is after the buffer,
then the seek time is available.

>> 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?

It would seem like there needs to be a new command to get intial information to the drive.  There is
a pair of new T10 and T14 commands called Trusted Send and Trusted Receive.  It may be possible to
use these commands, but that is up to T10 and T14 not P1619.

As long as we need the keying information, it would not be that hard to add an additional "offset"
amount that would indicate which drive this is in the system.  An example (From Colin's proposal):
                 I = ["offset" || (LBA+1)]<<n + (0,1,2...j-1), where n = ceil(log2(j)), and j = ceil(sector_size/16)
 (PS - Where do I get a copy of the manual of standard notation so that I can write these equations with
       "normal" speak?)
In fact, it may be possible to have the command specify the n value also.


>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.

Don