Re: Threat Model
References for the end-to-end SCSI protection include
http://www.t10.org/ftp/t10/document.03/03-307r6.pdf
http://www.t10.org/ftp/t10/document.03/03-111r0.pdf
Correct, the host to encryptor is non-cryptographic, and has a 16 bit
CRC. This is not intended for error correction since the lower layer
protections still exist. This is a "backstop" in the baseball sense to
catch errors that get through everything else. It will protect from
errors higher than the 2^-16 length of the CRC since the other 6 bytes
have expected values.
This does include a standard on how the application should check this
block.
On Apr 14, 2004, at 9:40 AM, Shai Halevi wrote:
>> If we consider the application is adding these 8 bytes and then later
>> we are EME (or similar) the entire 520 bytes, if the attacker tampers
>> with the data then the 8 byte check will be garbage and the reader
>> knows this.
>
> hmm.. EME-AES is designed for integral number of 16-byte blocks. We
> did have an extension that works for any number of bytes, but we never
> published it anywhere, and also never wrote a proof of security for it.
> (It adds only a single AES encryption operation over the current EME if
> you can fit the the tweak and the guard in one 16-byte block, and two
> AES encryptions otherwise.) Anyone knows why they decided on 64 bits?
>
>> The points along the way (between the host and the encryptor) can
> check
>> the 8 bytes for validity, and the points after the encryptor just
>> passes the bits.
>>
>> This is more coverage than just adding an 8 byte integrity field
>> because it does not protect between the encryptor and the host, it
>> only protects between the encryptor and the disk and back...
>
> The protection between the encryptor and the host is non-cryptograpic,
> though. And it is not quite "protection" until you specify precisely
> how the application should check this block.
>
> -- Shai