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: stds-p1619@LISTSERV.IEEE.ORG > > [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: stds-p1619@LISTSERV.IEEE.ORG 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----- > > > ***** stds-p1619@LISTSERV.IEEE.ORG > > > [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 > > > > > > > > > >
