> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of james hughes > Sent: Wednesday, December 14, 2005 6:19 PM > To: SISWG > Cc: james hughes > Subject: the extra 8 bytes.... > > 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?
If a disk drive is formatted with 520 byte logical blocks, then the disk drive does not know the contents of those 520 bytes and does no checking of their contents (any exception would be vendor-specific). All 520 bytes need to be encrypted - the application could even choose to put its non-user data at the beginning rather than the end. This is the reason Seagate wants LRW extended to support a CTS scheme (many Fibre Channel drives use 520 byte sectors). An application performing encryption using such a disk drive probably encrypts all 520 bytes as well. It might choose to only encrypt the user data; the disk drive doesn't know or care. If the disk drive is formatted with 512 byte logical blocks with 8 bytes of protection information enabled (per the SBC-2 standard), then the disk drive does understand the contents; it interprets the extra 8 bytes as the Guard (CRC), App Tag, Ref Tag fields. A drive with protection information needs to avoid storing the plaintext CRC; it can store the CRC of the encrypted user data instead. If it does not encrypt the Tag fields, it is compatible with an application performing encryption. An application performing encryption using a disk drive with protection information cannot encrypt the protection information; the bytes must appear on the wire with the correct values (e.g., Guard = CRC of the encrypted user data on the wire and Ref Tag = LBA). If it wants, a drive can encrypt all the protection information bytes using the CTS scheme. This makes it incompatible with an application performing encryption. -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott
