1. Why are we trying the avoid I = 0? I think it has to be documented in the introduction of the standard, or in an Appendix, to avoid questions like mine. Help me figure out the issue. If we start with I = 0 at LBA = 0 (the master boot record) an attacker might know the tweak value of its first 16 bytes (0). What can he do with this information? The block is still encrypted, and there will be no other block with 0 tweak, so what is the problem here?
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? How do you think the multiplier should optimally use this changing parameter? Even if formatting is done in the factory, different LBA sizes could be used for different drives, and the encryption HW has to be customized accordingly. It adds significant costs to the manufacturing. Otherwise (with large shift), the LBA length is just a counter value, with a possible branch at the end to handle odd sizes. 3. With a shift of 16, or a multiplier = 39, whatever, there is still no speed problem with handling consecutive LBA's: while the encryption is performed on the data, the Galois multiplier can pre-compute the tweak value for LBA+1, in case it would be needed. If not LBA+1 follows, 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. The only issue here, as I wrote, is the slight reduction in power consumption in the cases, when contiguous LBA ranges are accessed. 4. Colin wrote: >>The index variable should always be "sector number within key scope"<< How can a disk drive know this? It receives a read or write command with an LBA and the data. It looks like we would need yet another new disk command, the offset from the physical LBA to the logical LBA, which is only known by the controller in case the key scope spans more than one disk. The writing application, even the OS might not know this offset (which is the result of the internal mapping of the controller), therefore, there is a need to modify the controller, too, to provide this information. I don't think it is feasible. It looks easier to require the key scope is always within one drive and that drive shall use its physical LBA. It also necessitates some re-wording of the standard, as the index is not file dependent, but drive dependent, and the mapping is performed by the OS (the file system) and the controller. 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. 5. Encryption and decryption must be transparent, so for the outside world it does not matter if the drive internally encrypts the 8-byte protection information or not. The issue is purely security: an attacker, reading the unencrypted CRC could get some information about the data, and modifying the application field might cause some exploitable behavior of the application affected. This is why we must encrypt the extra 8-byte protection info. The issue is rather, do we need to protect against bit flipping or not in this field? If the CRC is destroyed, the data would look invalid, the same as if the block was overwritten with garbage. It is not a big deal. However, we don't know what happens if the application field is modified. If the application does not recognize its data, it is the same as destroying it, not an issue. But, if some other application receives this block and thinks it was its data, it might trigger some unwanted actions. Since we don't know, we have to provide the option for nonmalleable encryption for the 8-byte protection field. Laszlo
