OK, sorry if the subject line is misleading.
Is LRW really intended only for "removable sector based storage
devices"??
That's certainly not what the current draft says!
Here's a quote from the Intro page:
Introduction
The purpose of IEEE1619 standard is to describe the method of
encryption
for data-at-rest in sector-based devices. In particular, the
standard specifies
the encryption transform and a method for exporting/importing
encryption keys
for compatibility between different implementations. Encryption of
data-in-flight
is not covered by this standard.
This standard defines the LRW-AES tweakable block cipher and its use
for
encryption of sector-based storage.
I never understood the LRW discussions were only for removable media.
I suspect that many others, including industry folks who have not
participated
in the P1619 discussions directly, have the same (mis?) understanding.
> -----Original Message-----
> From: [email protected]
> [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> Sent: Monday, March 27, 2006 12:49 PM
> To: [EMAIL PROTECTED]
> Subject: RE: P1619 - non-removable
>
> Doug,
>
> I fully agree with your critics on LRW-AES, although the subject line
> (non-removable) is a bit misleading. Landon and I raised this
> lack of documentation issue several times in the reflector,
> but there seems to be no volunteer to fix the problem.
> Seagate, my employer is not involved in the tape business,
> nor in removable sector based storage devices (where LRW is
> applicable), so I cannot justify the time necessary for
> writing such a document. Somebody with vested interest in
> CD/DVD/Zip drives or external encryption boxes, controllers
> should take the task to clear things up.
>
> There are constraints, which were never explained, like why
> length preserving is an absolute requirement, why one must
> not encrypt more than 2^50 bits with one key, etc. These
> should all go into a Backgrounds document, maybe together
> with the threat models, attack scenarios.
>
> Laszlo
>
> > -------- Original Message --------
> > Subject: RE: P1619 - non-removable
> > From: "Doug Whiting" <[EMAIL PROTECTED]>
> > Date: Mon, March 27, 2006 3:17 pm
> > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> >
> > > Do you mean Chapter 8, Attack Scenarios, is not precise, not
> > > complete or incomprehensible? Please suggest
> improvements, additions
> > > to it.
> >
> > I mean for the LRW stuff. I wasn't commenting on your doc, which is
> > perhaps a good start (but it's less than two pages long). However,
> > there's nowhere I know of that addresses how LRW deals with
> these (or
> > other) threats.
> >
> > > What threat do you see? If read access is only provided with full
> > > authentication, or it requires destruction of the drive, only one
> > > snapshot can be taken.
> >
> > In your model, that may be true. But for LRW, I don't know
> that that
> > is the model we are providing or assuming. My point is, I
> don't know
> > what model we are assuming.
> >
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> > > Sent: Monday, March 27, 2006 12:02 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: P1619 - non-removable
> > >
> > > Doug,
> > >
> > > >> careful about considering any variant of counter mode for
> > > >> update-in-place storage applications
> > >
> > > What threat do you see? If read access is only provided with full
> > > authentication, or it requires destruction of the drive, only one
> > > snapshot can be taken.
> > >
> > > >> I'm still not quite sure that I fully understand what
> > > threats we are
> > > >> trying to protect against
> > >
> > > Do you mean Chapter 8, Attack Scenarios, is not precise, not
> > > complete or incomprehensible? Please suggest
> improvements, additions
> > > to it.
> > >
> > > >> we owe the world a careful and coherent threat model document
> > >
> > > Chapter 8 was meant as a draft for it. If it ever gets cleaned up
> > > enough, we can put it in a separate document, but I
> thought it could
> > > remain a chapter in the Backgrounds document.
> > >
> > > Laszlo
> > >
> > > > -------- Original Message --------
> > > > Subject: RE: P1619 - non-removable
> > > > From: "Doug Whiting" <[EMAIL PROTECTED]>
> > > > Date: Mon, March 27, 2006 1:13 pm
> > > > To: "Matt Ball" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
> > > > <[EMAIL PROTECTED]>
> > > >
> > > > RE: P1619 - non-removable
> > > >
> > > > FWIW, I think we should be extremely careful about
> > > considering any variant of counter mode for
> update-in-place storage
> > > applications (e.g., disk). While GCM can be used
> securely, the GCM
> > > IV has to be unique not only across blocks and vendors, but also
> > > across rewrites. Thus, you need a unique IV stored within
> the block
> > > itself (e.g., a write counter). So it adds even more
> overhead to the
> > > block. While this may be acceptable, it must be very explicitly
> > > considered and specified, as a "naive" application of GCM
> (e.g., IV
> > > = sector number + vendor ID) has serious potential security
> > > problems.
> > > >
> > > > But of course all of this gets back somewhat to the threat
> > > model. I'm still not quite sure that I fully understand
> what threats
> > > we are trying to protect against. While I understand that a
> > > standards document perhaps should specify only "what to
> write" and
> > > not necessarily the underlying rationale, I remain uncomfortable
> > > with the lack of an accompanying threat model document (or have I
> > > missed it?). Clearly, non-expanding encryption like LRW
> would NEVER
> > > be recommended by a cryptographer in a vaccum, but the
> constraints
> > > here are very tight so we have littte choice. Thus, I
> think we owe
> > > the world a careful and coherent threat model document, or the
> > > industry will misunderstand and possibly misuse the
> > > standard(s) that we produce.
> > > >
> > > >
> > > >
> > > > From: [email protected] on behalf of Matt Ball
> > > > Sent: Mon 3/27/2006 9:25 AM
> > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > > Subject: RE: P1619 - non-removable
> > > >
> > > >
> > > >
> > > >
> > > > I'm resending this message because it was rejected by
> the e-mail
> > > > server. I noticed that this has happened to other
> people as well.
> > > > Here is an error message that Jim forwarded to me after the last
> > > > meeting:
> > > >
> > > > The enclosed message, found in the STDS-P1619
> > > mailbox and shown under the spool
> > > > ID 2510543 in the system log, has been identified
> > > as a possible delivery error
> > > > notice for the following reason: "Sender:",
> > > "From:" or "Reply-To:" field
> > > > pointing to the list has been found in mail body.
> > > >
> > > > I suspect that it's necessary to delete instances of
> > > certain strings
> > > > within the message body. I've gone through and deleted all
> > > instances
> > > > of the string 'From:' in hopes that this won't get bounced.
> > > >
> > > > -Matt
> > > >
> > > > -----Original Message-----
> > > > ***** Matt Ball
> > > > Sent: Monday, March 27, 2006 9:27 AM
> > > > To: 'laszlo'; [EMAIL PROTECTED]
> > > > Subject: RE: P1619 - non-removable
> > > >
> > > >
> > > > Hi Lazlo,
> > > >
> > > > I recommended the GCM mode of P1619.1 because it would also
> > > be well-
> > > > suited to a hard disk implementation. Although the scope
> > > for P1619.1
> > > > states that it is "an architecture for protection of data in
> > > > variable-length block storage devices", the solution is equally
> > > > applicable to fixed-block storage devices such as disk drives.
> > > >
> > > > The only requirement for a 1619.1-compliant disk drive
> is that the
> > > > drive appends a 16-byte MAC to each 'record'. Since many
> > > disk drives
> > > > already have provisions for supporting a CRC, it would
> not be too
> > > > difficult to replace this with a cryptographically
> secure Message
> > > > Authentication Code.
> > > >
> > > > GCM mode in particular would be an excellent solution
> for a disk
> > > > drive. The hardware complexity is roughly equivalent to
> > > that of LRW
> > > > (one AES-encr block, and one 128-bit Galois multiplier).
> > > >
> > > > Here are a couple of other useful features for GCM:
> > > > - Uses a 128-bit message authentication code (MAC)
> > > > - Uses counter (CTR) mode encryption, allowing any size for
> > > the plaintext
> > > > and ciphertext.
> > > > - Allows Additional Authenticated Data (AAD), which is included
> > > > in the MAC computation, but is not encrypted
> > > > - It is possible to incrementally compute the MAC because of the
> > > > linear nature of the Galois field multiplier. This allows for
> > > > parallel implementations (GCM essentially uses GMAC)
> > > > - NIST is nearly ready to approve GCM mode for FIPS 140-2
> > > (or FIPS 140-3).
> > > >
> > > > Since most new disk drives will begin support 4096-byte
> sectors,
> > > > it would be possible to add a 16-byte MAC to each
> sector without
> > > > incurring too much overhead (overhead = 0.4% for
> 4096-byte sector).
> > > >
> > > > The only trick with GCM mode is that it is much more
> > > important to make
> > > > sure the IV is unique across different vendors. The
> > > P1619.1-D5 draft
> > > > current mitigates this problem by providing a standard
> > > key-transform
> > > > algorithm, or imposes requirements for an IV that is
> derived from
> > > > a cryptographically-secure pseudo-random number generator.
> > > >
> > > > See the latest P1619.1-D5 draft for more details. Let me
> > > know if you
> > > > have any other questions!
> > > >
> > > > -Matt
> > > >
> > > >
> > > > -----Original Message-----
> > > > ***** [email protected]
> > > > [mailto:[EMAIL PROTECTED] Behalf Of laszlo
> > > > Sent: Friday, March 24, 2006 7:31 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: RE: P1619 - non-removable
> > > >
> > > >
> > > > Matt,
> > > >
> > > > >> Have you considered using the GCM mode of P1619.1 for
> > > your disk drives?
> > > >
> > > > We are not involved in the tape business, so I did not pay
> > > attention.
> > > > Could you tell in a nutshell, what are the advantages of
> > > GCM over the
> > > > simple AES counter mode?
> > > >
> > > > >> I can't see any reason to make any more changes to P1619
> > > at this time.
> > > >
> > > > In the last teleconference I expressed my concerns that the
> > > WG would
> > > > not take the security of non-removable storage seriously. I was
> > > > promised that the WG would fully support it. The last two weeks
> > > > and your comment show the opposite. I only voted for submitting
> > > the draft
> > > > for editorial review, because I believed that
> alternatives would
> > > > be added to it. I cannot change my cast vote, but it
> proved to be
> > > > a mistake. I can only repeat, what I have said several
> times: the
> > > > current proposal is useless for the overwhelming majority of
> > > > secure storage applications. I thought it was a damn good reason
> > > for changing the draft.
> > > >
> > > > Laszlo
> > > >
> > > > > -------- Original Message --------
> > > > > Subject: RE: P1619 - non-removable
> > > > > ***** "Matt Ball"
> > > > > Date: Fri, March 24, 2006 6:42 pm
> > > > > To: laszlo, stds-p1619
> > > > >
> > > > > Hi Lazlo,
> > > > >
> > > > > Have you considered using the GCM mode of P1619.1 for
> > > your disk drives?
> > > > > I think it has most or all the features you're looking for.
> > > > >
> > > > > I skimmed through your document, and it looks like
> > > there's a lot of
> > > > > stuff in there that has already been covered by the SATA
> > > spec (like
> > > > > master passwords and such), or will likely be covered by
> > > the Trusted
> > > > > Computing Group (user authentication and access control).
> > > > > These things are beyond the scope of this working group.
> > > > >
> > > > > The other complaints are basically handled by the GCM mode.
> > > > >
> > > > > I can't see any reason to make any more changes to
> P1619 at this
> > > > > time.
> > > > >
> > > > > -Matt
> > > >
> > > >
> > >
> > >
>
>
