Re: [STDS-P1619] narrow question on IEEE 1619.0

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

On Thu, Sep 17, 2009 at 4:14 PM, Matt Ball <matthew.v.ball@xxxxxxxxx> wrote:

Hi John,

Here are my answers to the questions below. At the next working group meeting, I'd like to propose that the Security in Storage Working Group approve them as the answers from the working group.

Others in the working group -- please suggest any changes to wording based on your reading of the standard.

Also, please see NIST's draft SP 800-38E for additional guidance and restrictions when using XTS-AES as an approved mode of operation in a FIPS 140-2 cryptographic module.

Proposed answers to questions:

Q1. In section 5.1, should/must "Data Units" be of common, equal size? is this strictly enforced...

A1: Within a particular key scope (i.e., the range of data encrypted by a particular key) all data units shall be the same size. If the data units are not the same size, then the implementation is not compliant with XTS-AES. Enforcement is outside the scope of this standard.

Q2. If data units are not a multiple of 16 bytes in length (they need not be), then each data unit should do cipher-text stealing for encryption of the last two blocks (see Figure 2). Is this correct?

A2: Although the standard does not directly state it, if the size of the data unit within a particular key scope is defined as a non-multiple of 128-bits, then each data unit within the key scope shall use ciphertext stealing.

Q3: If the amount of data to be encrypted is not a multiple of the data unit size, what is typically done?

A3: XTS-AES was designed for situations in which the fundamental unit of encryption (i.e., the data unit) is fixed and it is not possible to change (example: hard disks with 512-byte sectors). In a hard disk, if a file does not fit exactly within an integer number of sectors, then the remainder of the file is typically padded out to the end of the sector, and the file size is recorded within metadata elsewhere. If you particular application allows flexibility in the data unit size, then it is more appropriate to use an authenticated encryption mode, such as those defined in IEEE Std 1619.1-2007. For example, tape drives allow variable-sized blocks, and will append a MAC (Message Authentication Code) to the end of each encrypted record.

Q4: Is the end of the data padded (best practice for padding) until it fills a complete data unit?

A4: Padding is outside the scope of IEEE Std 1619-2007. We anticipate that implementations will typically appear as a regular file system with normal file system padding and metadata. However, this could be an interesting topic to address within the scope of the newly approved PAR (project authorization request) for a revision to IEEE P1619.

Let me know if you have any more questions!

Thanks!
-Matt

On Tue, Aug 11, 2009 at 6:24 PM, John Markey wrote:

Hi All

We had a narrow technical question on the iEEE 1619.0 specification, in particular from the standard on the XTS-AES mode.

In section 5.1, should/must "Data Units" be of common, equal size? is this strictly enforced...
If data units are not a multiple of 16 bytes in length (they need not be), then each data unit should do cipher-text stealing for encryption of the last two blocks (see Figure 2). Is this correct?
If the amount of data to be encrypted is not a multiple of the data unit size, what is typically done?
Is the end of the data padded (best practice for padding) until it fills a complete data unit.

We are new to the use of this standard and we and our technology partner would like to make sure we are interpreting this correctly. Thank you very much.

John Markey

Mobile Devices

Broadcom Corp

San Diego

--
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717