Rob, The threat models, the performance requirements and the allowable costs are fundamentally different.
Although length preserving is not a requirement, it is still desirable. This is why 4 of the 5 encryption modes proposed in the document do not extend the length of the data, and the fifth mode adds only 2 bits to sector. In a disk drive we cannot afford to loose much more than that. >From a tape you can get the encrypted data. This raw data access presents problems for disk drives: traffic analysis type attacks become possible, and the secure storage device can be used as a high-speed encryptor by the bad guys. This later feature would prevent us from selling secure drives in many markets, or manufacture them in certain countries, unless some extra measures are taken. Disk drives also have performance issues. If you spend more than a few dozen nanoseconds in encryption, sequential LBA accesses will miss the next sector, and we have to wait for a whole disk revolution, causing a hundred fold performance hit. Laszlo > -------- Original Message -------- > Subject: Is p1619.NR covered under p1619.1? > From: "Rob Ewan" <[EMAIL PROTECTED]> > Date: Tue, May 16, 2006 9:35 am > To: <[EMAIL PROTECTED]> > Cc: "Rob Ewan" <[EMAIL PROTECTED]> > > Is p1619.NR covered under p1619.1? > > From the last teleconference, I understood that the size-maintaining > characteristic of p1619 was not a requirement for p1619.NR. If that is true, > have you considered simply using p1619.1 (the variable-block format) rather > than 1619? In the note on page 3 of the current draft (D6), P1619.1 states > that "it is not necessary for a conforming implementation to support > arbitrarily sized records", and goes on to suggest use in a disk environment. > Does this satisfy all of your requirements? > > ..Rob >
