The CRC is 16 bits, not 32. I suggested once that the LBA be included in the calculation so the 4 byte Reference Tag field could be reclaimed for other purposes, but the proponents (Seagate/Intel/LSI/Agilent and IBM) didn't like that idea. I never heard a secure hash suggested; there was debate about checksum vs. CRC, though.
The field is called the LOGICAL BLOCK GUARD field, not the CRC field; another algorithm option could be proposed to T10 (IBM browbeat the others into dropping the checksum option, so it might not be well received). -- 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:40 AM > To: SISWG > Subject: RE: the extra 8 bytes.... > > >>I think that if each block and each extra 8 bytes was > encrypted using > an independent random codebook, this would turn the CRC check into a > validation check. I think that some extension of LRW can > essentially > do this (we'd need to have the last LRW block be a 24-byte block). > For sure XCB does this. > > One of my critic to the SCSI protection information was the use of a > stupid CRC. It ought to be a secure hash with LBA included, > and maybe a > random IV. That we could store on disk unchanged, without leaking too > much information. Also, 32 bits are too short, there would be likely > collisions already in 64K blocks (within a single 32MB file), and > information leaks, too. We have to live with it for now, but buy no > means should a disk drive replace the protection info with anything > else internally. > > Laszo > > > -------- Original Message -------- > > Subject: Re: the extra 8 bytes.... > > From: David McGrew <[EMAIL PROTECTED]> > > Date: Tue, December 20, 2005 9:11 am > > To: james hughes <[EMAIL PROTECTED]> > > Cc: SISWG <[EMAIL PROTECTED]> > > > > Hi Jim, > > > > On Dec 14, 2005, at 4:18 PM, james hughes wrote: > > > > > The 520 byte mode is important because it contains a CRC > and other > > > "stuff" to determine the authenticity of the data... > > > > there may be confidentiality motivations for encrypting the > CRC, in > > addition to the authentication method that you mention below. > > Consider the case in which an attacker knows 508 bytes of > plaintext, > > but not the full 512 bytes of plaintext. If there is a > four-byte CRC > > of the plaintext in the clear, then the attacker can > recover all of > > the information. (Of course, if the CRC is over the ciphertext > > rather than the plaintext, then this concern doesn't apply.) > > > > > > > > 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??? > > > > I think that if each block and each extra 8 bytes was > encrypted using > > an independent random codebook, this would turn the CRC > check into a > > validation check. I think that some extension of LRW can > essentially > > do this (we'd need to have the last LRW block be a 24-byte > block). > > For sure XCB does this. > > > > > > > > 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? > > > > I'm not quite sure what you mean. Sorry, but my ignorance of disk > > systems is showing ;-) > > > > David > > > > > > > > Comment? > > > > > > Thanks > > > > > > jim >
