>>What's wrong with AES(K; 0), AES(K; 1), ...as different keys?
We have two HW engines in an encrypting disk drive, AES and the Galois
Multiplier. I had a bad feeling about using a cipher to randomize its
own keys (any slight non-randomness could be amplified). This is why I
proposed using the very different multiplier for whitening key
sequences, but, if we could agree using a disk ID, we won't need any of
these: the tweak values would be different on different drives. Dave had
a valid point, that cracking one drive should not compromise others
(should be added to the design goals section in the white paper), so we
ought to mandate that even in an array, each disk drive must be assigned
at least one of its keys independent-randomly.
>>[different processing for each part of the I field] How?
The polynomial T = I*K2 = (Drive_Index*x^64 + LBA*x^16 + index)*K2. We
can pre-compute Drive_Index*x^64 * K2, and simply XOR it to T'
(polynomial addition). Within an LBA: LBA*x^16 * K2 is also constant,
to be XOR-ed, so only the index*K2 needs to be computed (or taken from
a pre-computed table).
>>The only additional cost is keeping 16 more bytes of key
Although secure memory, integrated to the same chip as the crypto
engines, is not cheap, you are right, it alone is not a significant
cost. The HW development, debug time; the extra infrastructure to
manage the third keys: to generate, transfer and archive them is more
costly, and I don't see a significant improvement in security.
Laszlo
> -------- Original Message --------
> Subject: RE: p1619 (disk): ciphertext-stealing, tweak-mapping, other
> From: "Shai Halevi" <[EMAIL PROTECTED]>
> Date: Tue, December 20, 2005 10:41 pm
> To: "SISWG" <[EMAIL PROTECTED]>
>
> > >>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
