Rob, You probably know much more about T10 and the requirements then I do. This is really my first time having to deal with the T10 standard. That being said, educate me if I need it (be nice). Here are my thoughts:
>> 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. Becasue the protection information is defined by the standard, you are correct in that the disc does know the difference between 520 and 512 + protection information. I think the question here is does the encryption operation need to know that difference (I will answer your arguments below). If the encryption operation has to parse the data and check/generate a CRC it will become a larger block. >> 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. Would this be realistic in that we would want to perform a read and turn off the decryption operation? I am not exactly sure how the keying information would be sent to the drive and the commands required to read without decryption, but it would seem like it would be a lot of overhead for the host to turn off the decryption operation, perform a read, and then turn the decryption operation on again. One other way to potentially perform this would be a read long type of operation (I don't know if T10 has this), but the read long would return additional information that I presume the routers would not know how to parse for the CRC check anyways. >> 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. Can you give me a better idea on how this protection information is envisioned being used? If all of the routers are going to be checking the information, then it would be a requirment that the CRC is good when it leaves the drive (either decrypted data, or CRC over encrypted data). At the same time, if the drive decryption has to be turned off, couldn't the CRC checking in the intermediate devices also be turned off (also a pain)? >> 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. I see two problems with re-calculating the CRC: 1) non-detectable read errors, 2) more logic that is not covered with checking 1) If there is a non-detectable read error (CRC is correct, but data is wrong), this data will be decrypted and a new CRC over the decrypted data will be created. This data is incorrect data. If the CRC is encrypted instead of re-calculated, then a read error that is not detectable will decrypt to a much larger error and since the CRC will decrypt to a CRC over the original plaintext, it is much less likely that a non-detectable read error would be used by the host system (isn't this why so many companies have added their own CRC values to the sector data?). 2) With the data protection information, it is possible to have the block closest to the platters check the integrity of the data and ensure that what is getting written is what was sent to the drive. Once encryption happens, it is not possible to do that. If there is an error in the encryption process it is not detectable by a CRC check. Either the CRC check can not be done (CRC is encrypted) or the CRC is correct (created over the encrypted data). On the subsequent read operation, the CRC would be re-created on the decrypted text (since there was a single bit error on the encryption operation, the decrypted text is not the plaintext), the CRC will not indicate that the data is in error. The downside of encrypting the data is that either the error may not be detected (CRC re-calculation) or that the corrupted data will not be detected until it gets to the host system (wasted network utilization). On of the reasons to have the drive controller check the CRC is so that it can perform a retry operation before using the link (FC, SAS, SCSI). Encryption will change that. Don
