Rob, what is your point? Should the standard differentiate between SW and HW implementations? The drive does not know if part of a block is protection information or data, therefore it must encrypt everything. You say that SW encryption must be different. Why? The application decrypts the data it received and then checks if it is what it wanted. The protection fields are meant for detecting routing errors, not for directing the routing.
I am not aware of any requirements that a disk drive has to verify or needs to re-compute CRC. Also, a CRC over the encrypted data is superfluous, as the disk error rate is so low, you won't see a flipped bit within the lifetime of the drive, except if it breaks, but then everything is wrong. I thought the CRC is not there for catching random errors, but to facilitate identifying pieces of data. Laszlo > -------- Original Message -------- > Subject: RE: the extra 8 bytes.... > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > Date: Thu, December 15, 2005 7:22 pm > To: "SISWG" <[EMAIL PROTECTED]> > > > -----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
