Re: Threat Model
A potential problem doing a traditional keyed MAC (of any sort) this is
that the block guard is intended to be generated by the application and
checked along the way. The reason this is done this way is for problem
determination. If a chain of things {1...m} of from application (1) to
application (m) potentially through many components and storage
systems, and the error occurs at stage i, then the problem is either
at stage i or stage i-1.
03-110r0.pdf used to allow "DIF stacking". Could we use this to add 2
data integrity fields, and in the inner integrity field use that for a
traditional MAC? Then we have a really ugly disk drive with a 528 or
536 byte sector?
While these solve the issues for SCSI drives, this still begs the issue
for ATA or IDE drives (>90% of the market) which will stay at 512 byte
sectors?
In a cryptographic sense, the
On Apr 14, 2004, at 12:30 PM, Donald.R.Beaver@SEAGATE.COM wrote:
> Bob Nixon wrote:
>> Actually, there is a very explicit requirement to provide the physical
>> space: to use protection information, the device must be formatted for
> it
>> (see table 30 and many like it in SBC-2 rev 13). Formatting for
> protection
>> information unconditionally adds 8 bytes to the length of every block
> (see
>> the FMTPINFO bit in the FORMAT UNIT command in SBC-2 rev 13). One
>> implication may be important to SISWG, though...The community is
> sometimes
>> willing to give up space for security.
>
> This is good news: a path forward is to see if T10 will accept more
> than one 'block guard' option.
>
> The storage device can then offer the IEEE standard.
>
> (Thanks, Bob, for correcting my mistaken impression that storage
> efficiency, rather than virtualization, was the motivation.)
>
> Best,
>
> Don