You should not be using K+1, K+2, etc, lest you run into related-key attacks.I am not aware of any weakness of LRW in this regard. I was proposing to use related K1 (AES) keys. [...]
Using the keys in this manner "voids the warranty" of AES. No attacks on the full AES that use this particular form are known to date, but modifying the keys in this fashion opens very powerful new avenues for cryptanalysts. We don't want to do this. The general rule-of-thumb for crypto thingies: if you need several keys, make them all independent (or derive them using a strong pseudo-random generator).
[...] I have not seen amodification of EME, which supports 520-bit LBA's.
I have a paper from about a year ago that describes an extension to EME that works on arbitrary-size strings. I called it EME*. See http://eprint.iacr.org/2004/125/
Is not it {K1,K2} = 32-byte? Only with AES-256 it would go up to
48-byte.
Didn't we mandate 256-bit AES? I forget..
If they use several different keys, then all the 48 bytes have to bechosen "at random and independently" for each of these different keys. Do you know a specific threat, or does only the security proof require this?
The proof requires it, as does "general cryto hygiene"
introduce the notion of "compartments" within the key-scope, and useexactly two indexes, namely the compartment index and the index of the block within the compartment Why not use three compartments: Drive_Index, LBA, Cipherblock_within_LBA?
The reason for two (rather than one) is that they are used differently: you expect more or less random access to compartments, but sequential access to blocks within a compartment. In this regard there is no difference between the drive and the LBA index: in both cases you do not expect sequential access, so you might as well pack them both in one "compartment index". Although this standard is specifically for disk, I still think that there is a wide variety of disks and virtualized disks out there, and I prefer not to tie the standard too much to one of them. So I prefer that the part of the standard that specifies the transform would be stated using "technology neutral" terms (such as "compartments"). We can have a different part of the standard specifying how to map the information that is available to the encrypting device in various settings into these two indexes. (Presumably you then need to talk separately about SCSI, ATA, RAID-controller, and many many other different technologies).
A different proposal is to use two 128-bit values for K2We seem to have enough bits in I for partitioning: 64-bit drive ID, 48-bit LBA (up to 140,737 TB disks with 512-byte LBAs), 16-bit cipher-block index, so one K2 key looks sufficient.
The point was that if you have two of them, you can do different
processing to the sequential index and the random-access index (i.e.,
use K2a*compartment-index and K2b*2^{block-index}). This makes it
easier to optimize in some environments.
-- Shai
