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
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
