RE: LBA-to-I mapping & key scopes

[Donald . P . Matthews]

>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.

I like this idea.  I would suggest that the drive_index be more of a 16 to 20 bit value.  I could
easily see a filer that has more then 255 drives and a company may want to use all of the filer systems
that they have with each drive indexed so that all of the filers use the same key and have a different
drive_index number.

>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.

I guess I mis-communicated.  This is the point that I was trying to make.  It would not be hard to
perform this operation in hardware or in software.  It is only done at drive format (or re-format)
and the time to perform it (even though it is a simple operation) is immaterial.


Don