I agree here. Like has been discussed before, before any encryption the "sector" contains data plus an 8 byte integrity field. After the ecnryption the "sector" contains 520 bytes of data. The easiest thing to do is to encrypt the complete field. At this time many of the ESG drive buyers have their own integrity field, if our solution is to only encrypt the CRC portion of a field, then we have to know how all the customers use the field and where the CRC value is at. It is very easy for the encryption block to just know the size of the sector as formatted on the platters. With the new proposal the sector is 512 bytes of data and 8 bytes of integrity, but as far as the formatting is concerned, the size is 520 bytes and it should encrypt all of it. To do otherwise would require parsing the 520 total bytes and then there is a need for a hardware based parser and understanding of how everyone does it.
Don james hughes <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] No Phone Info Available 12/20/2005 10:40 AM To "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> cc james hughes <[EMAIL PROTECTED]>, SISWG <[EMAIL PROTECTED]> Subject Re: the extra 8 bytes.... > [...]The drive needs to encrypt the 512 bytes > of user data, calculate the CRC of the encrypted data, and store > that value rather than the plaintext CRC. If we recalculate the CRC of the ciphertext, the end-to-end nature of the CRC (which is why it is there in the first place) is lost since on decrypt we need to recalculate the CRC from scratch without any tie back to the original CRC. As is also mentioned, this end-to-end CRC is not really used by the drive. The drive has other protection measures. The drive -may- check it, but it is an optional thing to do. If we encrypt the CRC (method tbd) then the end-to-end nature can be preserved (the drive loses the ability to check the CRC). With end-to- end preserved, we can actually check that the encryption box didn't make a mistake (a quiet but valuable feature).
