>>if you decrypt with the wrong key, the CRC will be wrong... Does the WG >>expect to be able to make a copy or an image backup of a disk without >>knowledge of the key? As I repeatedly tried to explain, the drive must not return any data if the wrong key is given. It would allow traffic analysis, where LRW is especially weak.
Laszlo > -------- Original Message -------- > Subject: RE: the extra 8 bytes.... > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > Date: Tue, December 20, 2005 12:49 pm > To: "SISWG" <[EMAIL PROTECTED]> > > 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 > >
