> >>if you need several keys, make them all independent (or derive
> >>them using a strong pseudo-random generator).
> You did not comment on my real proposal of using AES keys K1, K1+K2,
> K1+K2^2,..., if you want to differentiate between disk drives.
Why do that? What's wrong with AES(K; 0), AES(K; 1), ...
as different keys?
> K2^k looks strong enough pseudorandom.
Maybe, but then again maybe not. This is highly non-standard, so why
use it?
> >>an extension to EME that works on arbitrary-size strings...
> Could you compare it to XCB or ABL?
Not of the top of my head (and I don't have enough time right now to
look into it carefully). Let's get the current standards out and then
go back to dealing with the other modes.
> Also, I might have missed the licensing status. Could you update us?
The short answer is "don't know". What I do know is that neither I not
IBM have any IP claims on it. As for the rest of the world, your guess
is as good as mine.
> >>more or less random access to compartments, but sequential access to
> >>blocks within a compartment
> The drive index is a constant ID,
If it really is a constant then why do you need it? I thought that someone
mentioned a RAID environment where there were many disks, each with its
own disk index (maybe Colin?)
> >>if you have two of them, you can do different processing to the
> >>sequential index and the random-access index
> You can do different processing for each part of the I field, as well.
How?
> For notebook drives, an extra 128-bit key and an extra Galois
> multiplication for each LBA access could be prohibitive.
You don't have an extra multiplication for an LBA. There is just one real
multiplication per LBA, namely K2a * LBA-index. The other multiplication
(K2b * 2^{block-index)) is just K2b for the first block, 2*K2b for the
second, 4*K2b for the 3rd, etc. Computing this is just one shift and one
conditional xor per block.
The only additional cost is keeping 16 more bytes of key. I will be (very)
surprised if this turns out to be a significant cost (even for digital
cameras, let alone laptops).
Bottom line, the tradeoff is keeping 16 more bytes of key vs. doing the
carry-bit processing that is needed to go from K2*i to K2*(i+1). I don't
have a strong feeling either way, we just need to pick one of them.
-- Shai
