The drive could just not store anything in the field, and calculate the CRC during the read command based on whatever data is being transmitted. This means the CRC just has value for transmission purposes, not storage.
Encrypting the CRC, on the other hand, preserves some value for storage purposes. However, if you decrypt with the wrong key, the CRC will be wrong. This would complicate reading data from a disk if you don't know the key - you'd have to disable CRC checking in the read command. Does the WG expect to be able to make a copy or an image backup of a disk without knowledge of the key? -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Tuesday, December 20, 2005 11:19 AM > To: SISWG > 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. > > As I said several times, there is no need for a CRC over the encrypted > data. The disk drive has internal error correction, so more powerful > measures are taken in the background, anyway. Also, this CRC is > meaningless for the decrypted data, which is provided by the drive, so > it is useless. Furthermore, the firmware is not fast enough for a CRC > so computing this useless information would necessitate further HW > changes. > > Laszlo > > > -------- Original Message -------- > > Subject: RE: the extra 8 bytes.... > > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > > Date: Tue, December 20, 2005 10:35 am > > To: "SISWG" <[EMAIL PROTECTED]> > > > > > -----Original Message----- > > > From: David McGrew [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, December 20, 2005 8:18 AM > > > To: Elliott, Robert (Server Storage) > > > Cc: SISWG > > > Subject: Re: the extra 8 bytes.... > > > > > > Robert, > > > > > > On Dec 15, 2005, at 8:44 PM, Elliott, Robert (Server > Storage) wrote: > > > > > > > > > > >> -----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 extra 8 bytes is left unencrypted, would that mean > that there > > > is a CRC of the plaintext that is left in the clear? > > > > > > thanks, > > > > > > David > > > > > > > Correct - and that leaks information. That's why (as mentioned > > earlier in the thread) 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. > > > > From several messages earlier: > > > >>> 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. > > > > -- > > Rob Elliott, [EMAIL PROTECTED] > > Hewlett-Packard Industry Standard Server Storage Advanced Technology > > https://ecardfile.com/id/RobElliott >
