> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Thursday, December 15, 2005 9:49 PM > To: SISWG > Subject: RE: the extra 8 bytes.... > > Rob, what is your point?
Since the 520 topic is under discussion, I want to ensure everyone understands the difference between 520 byte formatted disks and 512+protection information formatted disks. > 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. For drives formatted with 520 byte logical blocks, that's true. For drives formatted with 512 byte + protection information logical blocks, that's not true. The drive understands the contents of the protection information. It might encrypt the extra 8 (losing compatibility with SW encryption) or it might not (maintaining compatiblity). I'm not sure compatiblity is crucial, but understanding the difference seems important. If the drive encrypts the data, then you won't be able to tell the drive "don't decrypt" and read the data for software decryption with protection information checking enabled during the read. Also, software cannot write the data encrypted for later disk drive decryption with protection information checking enabled during the write. > 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. T10 standard protection information can be checked by any device on the path from the initiator to the target (e.g. switches, routers, bridges, ...). Those devices do not know how to decrypt the data. So, the Ref Tag transmitted on the wire has to be unencrypted, the CRC has to cover the user data on the wire (which is plaintext if the disk drive is encrypting and ciphertext if the application is encrypting), and the App Tag probably has to be unencrypted. > 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. The CRC and Reference Tag (LBA) help catch frame assembly and disassembly errors. Logical blocks can be transferred over multiple frames in most transport protocols (and one frame can often hold more than one logical block). If a memory pointer in an HBA, bridge, or disk drive suffers a bit error (or a software bug) the device might select the wrong data for a frame. > > 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 >
