>>Would it help to include that value [World Wide Name] in the upper bits of I? It would prevent user errors, simplifies the key loading command, but makes the initial multiplication more costly (fewer 0's). It might be a factor of 2 slower. One could hash this value down to 16 bit (with some secret included), if performance was critical. In a huge network of disk there will be collisions, but an attacker would not know, which disk share the same IV, so there are no easy exploits.
Laszlo > -------- Original Message -------- > Subject: RE: LBA-to-I mapping & key scopes > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > Date: Fri, December 16, 2005 10:59 am > To: <[EMAIL PROTECTED]> > > SCSI disk drives usually include a 64-bit NAA IEEE Registered identifier > that is unique for the drive (the logical unit name in the INQUIRY > command Device Identification VPD page); ATA disk drives optionally > include such an identifier (the World Wide Name field in IDENTIFY DEVICE > data). > > Would it help to include that value in the upper bits of I? > -- > Rob Elliott, [EMAIL PROTECTED] > Hewlett-Packard Industry Standard Server Storage Advanced Technology > https://ecardfile.com/id/RobElliott > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of [EMAIL PROTECTED] > > Sent: Friday, December 16, 2005 9:51 AM > > To: [EMAIL PROTECTED] > > Subject: RE: LBA-to-I mapping & key scopes > > > > >>If you have enough plaintext/ciphertext pairs with the same key > > You don't. Users must you different keys for different drives to avoid > > comparison attacks, so you only see one AES plaintext-ciphertext pair > > per key. Even if K1 is reused and I=0 is allowed you see only as many > > plaintext-ciphertext pairs as disk drives you put on spin stands. Very > > few. This is not an issue. > > > > >>that's just more keys to manage. [K, K+1, K+2...] > > No. It is still just one key, plus an offset (~drive index). > > > > >>a controller serving many disks would probably want to use > > as few keys as possible > > True. This is a slight advantage of using drive-indices instead of > > incremented keys. For the majority of the applications it just > > complicates things without improving the security. If a user is dumb > > enough to use the same key on many drives, why do you think he won't > > set all the drive indices to 0? > > > > >>LRW is not a _perfect_ solution > > It does improve the security of data at rest. For the cases, where > > traffic analysis is a feasible attack, P1619 should revive one of the > > long block encryption modes. Since the proposed standard does not > > include one, implementers have no choice. If they face > > traffic analysis > > type attacks, they have to add extra proprietary measures, leading to > > many incompatible solutions. > > > > Laszlo > > > > > -------- Original Message -------- > > > Subject: RE: LBA-to-I mapping & key scopes > > > From: "Colin Sinclair" <[EMAIL PROTECTED]> > > > Date: Fri, December 16, 2005 7:22 am > > > To: <[EMAIL PROTECTED]> > > > > > > > >>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? > >
