Re: the extra 8 bytes....
I agree here.
Like has been discussed before, before any encryption the "sector"
contains data plus
an 8 byte integrity field. After the ecnryption the "sector" contains 520
bytes of data.
The easiest thing to do is to encrypt the complete field. At this time
many of the ESG drive
buyers have their own integrity field, if our solution is to only encrypt
the CRC portion
of a field, then we have to know how all the customers use the field and
where the CRC
value is at. It is very easy for the encryption block to just know the
size of the
sector as formatted on the platters. With the new proposal the sector is
512 bytes of data
and 8 bytes of integrity, but as far as the formatting is concerned, the
size
is 520 bytes and it should encrypt all of it. To do otherwise would
require parsing the 520
total bytes and then there is a need for a hardware based parser and
understanding of how everyone does it.
Don
james hughes <jphughes@MAC.COM>
Sent by: stds-p1619@ieee.org
No Phone Info Available
12/20/2005 10:40 AM
To
"Elliott, Robert (Server Storage)" <Elliott@hp.com>
cc
james hughes <jphughes@MAC.COM>, SISWG <stds-p1619@IEEE.ORG>
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.
If we recalculate the CRC of the ciphertext, the end-to-end nature of
the CRC (which is why it is there in the first place) is lost since
on decrypt we need to recalculate the CRC from scratch without any
tie back to the original CRC.
As is also mentioned, this end-to-end CRC is not really used by the
drive. The drive has other protection measures. The drive -may- check
it, but it is an optional thing to do.
If we encrypt the CRC (method tbd) then the end-to-end nature can be
preserved (the drive loses the ability to check the CRC). With end-to-
end preserved, we can actually check that the encryption box didn't
make a mistake (a quiet but valuable feature).