> >>this opens the door for an easy attack on the AES to get K1.
> If there was a weakness in AES in ECB mode. None is known, so there is
> no argument against allowing I = 0.
If you have enough plaintext/ciphertext pairs with the same key, this starts
opening doors. For the
ease of avoiding I=0, I think it should be done. There is nothing in the
original "LRW" paper which
describes such a problem, but then neither does it specify the use of a GF
multiply to implement the
function T = h(I) chosen from family of hash functions H (by virtue of changing
K2). Because h(0) ==
0 whatever h (ie K2) is chosen, this may invalidate the security proof for LRW?
I don't know, this
is beyond me!
Cryptographic algorithms (such as LRW) are dangerous things. They often need
things like IVs which
need to be unique and/or random to guarantee security, but leave it up to the
user (in this case
1619 standard) to ensure this is achieved. So the 1619 standard should make
every attempt to ensure
security is not violated by defining a simple and consistent way of forming I
values in a storage
application. Otherwise, repeated or illegal I values could be used because a
vendor/implementor
doesn't understand the restrictions.
In my most recent suggestion, with the top byte defined as a drive index, this
could start at 1 for
a single/first drive thus preventing I becoming 0 even if the LBA is used
without additive offset.
The drive is then configured (by some command extension over the interface) at
power up with the key
and a "drive index within key scope". The contribution that the drive index
makes to the T values is
static and that part of the GF multiplication can be precomputed when the key
is loaded, thus
getting us back to a much reduced per-sector (or per-contiguous-sector-burst)
multiplication for
typical LBAs of ~32 bits.
I propose:
i = drive_index<<120 + LBA<<n + (0,1,2...j-1),
where n = ceil(log2(j)), and j = ceil(sector_size/16)
and drive_index is in range 1..255.
For a key scope spanning multiple drives, the index must be varied accordingly.
The controller can
program each connected drive uniquely at power up.
For a single drive with one scope, the index defaults to 1 and the LBA can be
completely unmodified
(apart from shift offset). For multiple key scopes on a single drive
(partitions?) the LBA used in
this calculation could be normalised to 0 within the partition/scope, or it
could be completely
unmodifed (easier) - just need to choose either rule and document it.
Note (for Don): n & j are both constant after the drive is formatted to a
specific sector size.
Surely it is not that much effort for internal disk software to compute this
and remember it for
internal encryption operations? Or for external controller software to query
the drive parameters
(which is probably has to do anyway) and work it out! The standard should only
define the
_composition_ of I, not the fine details of how or where it is computed.
Also, apologies for using "<<" in the equation above; we now agree that I is
defined back to front
and that the LS bit of I is on the right, to match the GF polynomial. I have
now used "i =" where i
is the integer value which gets encoded bitwise backwards into I. This is why
$5.2 needs to be
re-written very carefully!
> >>The interface would be the I vector, since LRW is defined like that, not in
> >>terms of LBAs
> Here I see a problem.
I meant interface between disk or controller software, and any encryption
acceleration module
(software subroutine or hardware), not the connector on the back of the drive.
The LRW I value
should be totally hidden from the storage user (an OS?), who only cares about
LBAs.
> >>Outside of the disk you probably don't get the ability to start the seek
> >>for a write
> It looks like I need to write a more extensive explanation, why it is
> not a good idea to implement LRW outside of the disk. I wrote about it
> several times, but it gets just ignored. So give me a couple of hours,
> I will post it.
I read this; some good points raised. I think we all agree LRW is not a
_perfect_ solution and there
are many types of attacks. But LRW is likely to be adopted by many vendors,
both outside and inside
the drives (depending on which market segment they are in), so we should at
least make it work for
both scenarios, I feel. I'm not that qualified to comment on this any more
because may main interest
is ensuring the crypto is correctly used, unambiguously defined and is easy to
implement as a
sub-module.
> >>What about a RAID application
> If the encryption is done in each individual disk drive, you just have
> to provide a different key for each. They can be K, K+1, K+2,... Since
> the encryption is transparent, the controller does not have to do
> anything different than before, except providing the keys to the drives
> at power up. If you encrypt in the controller, I will explain why the
> security is weaker.
OK, that's just more keys to manage. Changing keys in hardware accelerators (or
software, for that
matter) sometimes incurs a latency due to precomputations. So a controller
serving many disks would
probably want to use as few keys as possible? My proposal does not preclude an
implementation from
using one key per drive.
> >>How about defining the top byte of I to be a drive index
> It can be done. We need yet another new disk command, or, modify the not
> yet defined one, which transfers the keys to the drive: (K1, K2,
> Drive_index). It allows you to use the same K1 and K2 keys for
> different drives. It does not add much to the security, since you could
> always use different (but related) keys without any significant danger
> of collision.
Agreed it does not affect the security. The standard must either explicitly
state key scopes cannot
be used across multiple drives, or it must define a drive index or similar to
preclude duplicate I
values.
The working group as a whole needs to decide which way to go, before the text
of $5 can be
updated...
As the key transfer command is not yet defined, adding another parameter to it
is probably not an
issue?
