| I would support items 1 and 2 as long as T10 supports item 2...
Who can speak for T10? I know you lurkers are out there!!!
If this happens, we need to decide if this will be P1619 or P1919a (a new PAR). (I would guess the latter but I am frequently wrong.)
Thanks
jim
My understanding is that the CRC is checked by the host interface block (just after the wire) and can be checked by the formatting block (just before the platter). If encryption of the complete packet (sector plus integrity) is done, then the formatting block check can not be done, but most controllers probably have internal parity or ECC for inside the chip integrity.
In reality there are two issues:
1) How does 1619 handle non-aligned sector sizes
2) How does T10 handle encryption when there is an integrity field
For 1) we can have a solution (it seems like the cipher stealing is moving toward being a part of the spec).
For 2) we can propose that all of the sector information (data and any integrity field) be encrypted. Once the 1619 draft is accepted, then it would be up to the T10 committee to determine how best to apply it. My feeling at this time would be to encrypt all 520 bytes. This is simple because there is no parsing of the data stream.
Don
The 520 byte mode is important because it contains a CRC and other
"stuff" to determine the authenticity of the data...
If we did a mode that encrypted the extra 8 bytes using the counters
in this 8 as part of the tweak, and somehow manipulated the CRC so
that tamper anywhere in the packet will randomize the (puny 16 bit)
crc, this would be valuable? This way, the operation of the encryptor
will be validated end to end???
This would mean that the storage devices can not check the 2 CRC?
Stated another way, is it legal to have a 520 byte sector that does
conform to the extra 8 standard above the encryptor and below the
encryptor is a true 520 byte sector?
Comment?
Thanks
jim
|
