Home > IEEE P1619™/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices

IEEE P1619™/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices

Page 1
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1619™/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices
Prepared by the Security in Storage Working Group of the IEEE Computer Society Committee Copyright © 2007 by the Institute of Electrical and Electronics Engineers, Inc. Three Park Avenue New York, New York 10016-5997, USA All rights reserved. This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department. Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department. IEEE Standards Activities Department Standards Licensing and Contracts 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA

Page 2
IEEE 1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
ii Abstract: This standard specifies cryptographic transform and key archival methods for protection of data in sector-level storage devices. Keywords: Security, Storage, Encryption, Key Management

Page 3
IEEE 1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
ii
Introduction
(This introduction is not part of IEEE P1619/D16, Draft Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices.) The purpose of this standard is to describe a method of encryption for data stored in sector-based devices where the threat model includes possible access to stored data by the attacker. The standard specifies the encryption transform and a method for exporting/importing encryption keys for compatibility between different implementations. Encryption of data in transit is not covered by this standard. This standard defines the XTS-AES tweakable block cipher and its use for encryption of sector-based storage. XTS-AES is a tweakable block cipher that acts on data units of 128 bits or more and uses the AES block cipher as a subroutine. The key material for XTS-AES consists of a data encryption key (used by the AES block cipher) as well as a ��tweak key�� that is used to incorporate the logical position of the data block into the encryption. XTS-AES is a concrete instantiation of the class of tweakable block ciphers described in reference [XEX04]. The XTS-AES addresses threats such as copy-and-paste and dictionary attacks, while allowing parallelization and pipelining in cipher implementations.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents or patent applications for which a license may be required to implement an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.
Participants
The Security in Storage Working Group operated under the following sponsorship: Sponsor: John L. Cole, Information Assurance Standards Committee Co-Sponsor: Curtis Anderson, Storage Systems Standards Committee When work on this draft standard began and until January 2007, the Security in Storage Working Group had the following officers: James P. Hughes, Chair Serge Plotkin, Vice-chair Fabio Maino, Secretary At the time this draft standard was completed, Security in Storage Working Group had the following officers: Matthew V. Ball, Chair Eric Hibbard, Vice-chair Fabio Maino, Secretary

Page 4
IEEE 1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
ii At the time this draft standard was completed, the P1619 Task Group had the following membership: Serge Plotkin, Task Group Chair and Technical Editor
Gideon Avida Matthew V. Ball David L. Black Russel Dietz Rob Elliott Hal Finney John Geldman Robert Griffin Cyril Guyot Shai Halevi Laszlo Hars Eric A. Hibbard Larry D. Hofer Walt Hubis James P. Hughes Glen Jaquette Curt Kolovson Robert A. Lockhart Fabio Maino Charlie Martin David A. McGrew Dalit Naor Landon Curt Noll Jim Norton Scott Painter David Sheehy Robert N. Snively Douglas L. Whiting
This document was edited by Serge Plotkin, Shai Halevi and Dalit Naor. Special thanks to Doug Whiting, Brian Gladman, and Rob Elliott. The following members of the balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. (to be supplied by IEEE)

Page 5
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
iv CONTENTS 1. Overview .................................................................................................................................................... 1  1.1 Scope ................................................................................................................................................... 1  1.2 Purpose ................................................................................................................................................ 1  1.3 Related work ........................................................................................................................................ 1  2. References .................................................................................................................................................. 2  3. Definitions, acronyms and abbreviations ................................................................................................... 2  3.1 Definitions ........................................................................................................................................... 2  3.2 Acronyms and abbreviations ............................................................................................................... 2  4. Special Terms ............................................................................................................................................. 3  4.1 Numerical values ................................................................................................................................. 3  4.2 Letter symbols ..................................................................................................................................... 3  5. The XTS-AES transform ............................................................................................................................ 3  5.1 Data units and tweaks .......................................................................................................................... 3  5.2 Multiplication by a primitive element �� .............................................................................................. 4  5.3 The XTS-AES Encryption Procedure .................................................................................................. 4  5.4 The XTS-AES Decryption Procedure .................................................................................................. 6  6. Using XTS-AES-128 and XTS-AES-256 for Encryption of Storage ......................................................... 8  7. Exporting and Archiving XTS-AES-128 and XTS-AES-256 keys ............................................................ 9  7.1 Key Backup Structure .......................................................................................................................... 9  7.2 XML Format ...................................................................................................................................... 11  7.3 Encryption of Key Backup material .................................................................................................. 13  Annex A (informative) Bibliography ........................................................................................................... 15  Annex B (informative) Test Vectors ............................................................................................................ 16  Annex C (informative) Pseudocode for XTS-AES-128 and XTS-AES-256 Encryption ............................. 25  C.1 Encryption of a data unit with a size that is a multiple of 16 bytes ................................................... 25  C.2 Encryption of a data unit with a size that is not a multiple of 16 bytes ............................................. 26  Annex D (informative) Rationale and Design Choices ................................................................................ 27  D.1 Purpose ............................................................................................................................................. 27  D.2 Transparent Encryption ..................................................................................................................... 27  D.3 Wide vs. Narrow Block Tweakable Encryption ............................................................................... 28  D.4 The XEX Construction ..................................................................................................................... 29  D.5 Sector-size that is not a multiple of 128 bits ..................................................................................... 32 

Page 6
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
v D.6 Miscellaneous ................................................................................................................................... 32 

Page 7
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
1
Standard for Cryptographic Protection of Data on
1
Block-Oriented Storage Devices
2 1. Overview 3
1.1 Scope
4 5
This standard specifies elements of an architecture for cryptographic protection of data on block-oriented
6
storage devices, describing the methods, algorithms, and modes of data protection to be used.
7 8
1.2 Purpose
9
This standard defines specific elements of an architecture for cryptographically protecting data stored in
10
constant length blocks. Specification of such a mechanism provides an additional and improved tool for
11
implementation of secure and interoperable protection of data residing in storage.
12 13
The XTS-AES transform defined in this standard is intended for encryption of storage where the threat
14
model includes possible access to stored data by the attacker, data to be protected is presented in fixed-size
15
units (sectors, logical disk blocks, etc.), and each unit must be processed separately, independently of other
16
data units. XTS-AES is a length-preserving transform, meaning that the ciphertext length produced by
17
XTS-AES is equal to the length of the plaintext. These two properties allow the use of XTS-AES as
18
transparent encryption: an encryption/decryption module may be added to an existing system without
19
having to modify the data layout of any of the existing components.1
20 21
This standard includes the description of the XTS-AES transform itself (in both encryption and decryption
22
modes) and a specification of how it should be used for encryption of stored data. This standard also
23
contains a description of a key-export format. The goal is to facilitate a scenario where a standard-
24
conformant device that encrypts data using XTS-AES can export the key in a way that will allow
25
construction of another standard-conformant device that is able to import this key and decrypt the data.
26 27
1.3 Related work
28
1 It is noted that the requirement for transparent encryption implies some inherent limitations on the level of
security that can be achieved by such a transform, and these limitations should be carefully considered by an application that uses this standard.

Page 8
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
2 The formal definition of the security goal of a tweakable block-cipher is due to Liskov, Rivest, and Wagner
1
[LRW02], where they also show how tweakable ciphers can be built from standard block ciphers. An
2
earlier work by Schroeppel suggested the idea of a tweakable block-cipher, by designing a cipher that
3
natively incorporates a tweak [S98].
4 2. References 5
The following referenced documents are indispensable for the application of this document. For dated
6
references, only the edition cited applies. For undated references, the latest edition of the referenced
7
document (including any amendments or corrigenda) applies.
8
NIST FIPS-197, Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard
9
(AES).2
10
REC-xml, W3C Extensible Markup Language (XML) 1.0 (Fourth Edition). (http://www.w3.org/TR/REC-
11
xml/).
12 13 3. Definitions, acronyms and abbreviations 14
3.1 Definitions
15 16
For the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary
17
of IEEE Standards, Seventh Edition, should be referenced for terms not defined in this clause.
18 19
3.1.1 key scope: Data encrypted by a particular key, divided into equal-sized data units (see 3.3). The key
20
scope is identified by three non-negative integers: tweak value corresponding to the first data unit, the data
21
unit size, and the length of the data.
22
3.1.2 tweak value: The 128-bit value used to represent the logical position of the data being encrypted or
23
decrypted with XTS-AES.
24
3.1.3 data unit: Within IEEE Std 1619, 128 or more bits of data within a key scope. The first data unit in a
25
key scope starts with the first bit of the key scope; each subsequent data unit starts with the bit after the end
26
of the previous data unit. Data units within a key scope are of equal sizes. A data unit does not necessarily
27
correspond to a physical block on the storage device.
28
3.2 Acronyms and abbreviations
29
AES advanced encryption standard
30
DTD document type definition
31
FIPS Federal Information Processing Standard
32
GF Galois field, see reference [Crypto-HBook].
33
2 FIPS publications are available from the National Technical Information Service (NTIS), 5285 Port Royal
Road, Springfield, VA 22661, USA. FIPS-197 is also available on-line from http://csrc.nist.gov/publications/fips/index.

Page 9
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
3 LBA logical block address
1
XML extensible markup language
2
XTS XEX encryption mode with tweak and ciphertext stealing
3
Base64 Encoding according to [RFC3548].
4 4. Special Terms 5
4.1 Numerical values
6
Decimal and binary numbers are used within this document. For clarity, decimal numbers are generally
7
used to represent counts and binary numbers are used to describe bit patterns.
8
Decimal numbers are represented in their usual 0, 1, 2, ... format. Binary numbers are represented by a
9
string of one or more bits followed by the subscript 2. Thus the decimal number 26 may also be represented
10
as 000110102.
11
4.2 Letter symbols
12
The following symbols are used in equations and figures:
13
⊕ Bit-wise exclusive-OR operation
14
⊗ Modular multiplication of two polynomials over the binary field GF(2), modulo
15
x128+x7+x2+x+1, where GF stands for Galois Field (see [Crypto-HBook]).
16
�� A primitive element of GF(2128) that corresponds to polynomial x (i.e., 0000��0102),
17
where GF stands for Galois Field (see [Crypto-HBook]).
18
�� Assignment of a value to a variable
19
| Concatenation (e.g., if K1=0012 and K2=1010102, then K1|K2=0011010102).
20
// Start of a comment. Comment ends at end of line.
21
x⎦ Floor of x (e.g. ⎣7/3⎦=2).
22 23 5. The XTS-AES transform 24
5.1 Data units and tweaks
25
This standard applies to encryption of data stream divided into consecutive equal-size data units, where the
26
data stream refers to the information that has to be encrypted and stored on the storage device. Information
27
that is not to be encrypted is considered to be outside of the data stream.
28 29

Page 10
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
4 The data unit size shall be at least 128 bits. The number of 128-bit blocks in the data unit shall not exceed
1
2128-2. The number of 128-bit blocks should not exceed 220. Each data unit is assigned a tweak value which
2
is a non-negative integer. The tweak values are assigned consecutively, starting from an arbitrary non-
3
negative integer. When encrypting tweak value using AES, the tweak is first converted into a little-endian
4
byte array. For example, tweak value 123456789A16 corresponds to byte array 9a16,7816,5616,3416,1216 .
5 6
The mapping between the data unit and the transfer, placement and composition of data on the storage
7
device is beyond the scope of this standard. Devices compliant with this standard should include
8
documentation describing this mapping. In particular, single data unit does not necessarily correspond to a
9
single logical block on the storage device. For example, several logical blocks might correspond to a single
10
data unit. Data stream, as used in this standard, does not necessarily refer to all of the bits sent to be stored
11
in the storage device. In particular, if only part of a logical block is encrypted, only the encrypted bytes are
12
viewed as the data stream, i.e. input to the encryption algorithm in this standard.
13
5.2 Multiplication by a primitive element ��
14
The encryption and decryption procedures described in the following section use multiplication of a 16-
15
byte value (the result of AES encryption or decryption) by j-th power of ��, a primitive element of GF(2128).
16
The input value is first converted into a byte array a0[k], k = 0,1,...,15. In particular, the 16-byte result of
17
AES encryption or decryption is treated as a byte array, where a0[0] is the first byte of the AES block.
18 19
This multiplication is defined by the following procedure.
20 21
Input: j is the power of ��
22
byte array a0[k], k = 0,1,...,15
23
Output: byte array aj[k], k = 0,1,...,15
24 25
The output array is defined recursively by the following formulas where i is iterated from 0 to j:
26 27
ai+1[0] �� (2 (ai[0] mod 128)) ⊕ (135 ⎣ai[15]/128⎦)
28
ai+1[k] �� (2 (ai[k] mod 128)) ⊕ ⎣ai[k-1]/128⎦, k = 1,2,��,15
29 30
Note - Conceptually, the operation is a left shift of each byte by one bit with carry propagating from one
31
byte to the next one. Also, if the 15th (last) byte shift results in a carry, a special value (decimal 135) is xor-
32
ed into the first byte. This value is derived from the modulus of the Galois Field (polynomial
33
x128+x7+x2+x+1). See Annex C for an alternative way to implement the multiplication by ��j.
34
5.3 The XTS-AES Encryption Procedure
35
5.3.1 XTS-AES-blockEnc Procedure, Encryption of a Single 128-bit Block
36
The XTS-AES encryption procedure for a single 128-bit block is modeled with this equation:
37
C �� XTS-AES-blockEnc(Key, P, i, j)
38
where:
39
Key is the 256 or 512 bit XTS-AES key
40
P is a block of 128 bits (i.e., the plaintext)
41
i is the value of the 128-bit tweak (see 5.1)
42
j is the sequential number of the 128-bit block inside the data unit
43
C is the block of 128 bits of ciphertext resulting from the operation
44
The key is parsed as a concatenation of two fields of equal size called Key1 and Key2 such that: Key = Key1 |
45
Key2.
46

Page 11
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
5 The ciphertext shall then be computed by the following or an equivalent sequence of steps (see Figure 1):
1
1.
T �� AES-enc(Key2 , i) ⊗ ��j
2
2.
PP �� P T
3
3.
CC �� AES-enc(Key1 , PP)
4
4.
C �� CC T
5 6
AES-enc(K,P) is the procedure of encrypting plaintext P using AES algorithm with key K, according to
7
FIPS-197. The multiplication and computation of power in step 1 is executed in GF(2128), where �� is the
8
primitive element defined in 4.2 (see 5.2).
9 10
Figure 1 — Diagram of XTS-AES blockEnc procedure
11 12 13
5.3.2 XTS-AES Encryption of a data unit
14
The XTS-AES encryption procedure for a data unit of plaintext of 128 or more bits is modeled with this
15
equation:
16
C �� XTS-AES-Enc (Key, P, i)
17
Where:
18
Key is the 256 or 512 bit XTS-AES key
19
P is the plaintext
20
i is the value of the 128-bit tweak (see 5.1)
21
C is the ciphertext resulting from the operation, of the same bit-size as P
22
The plaintext data unit is first partitioned into m+1 blocks:
23
P = P0 |�� |Pm1|Pm
24
where m is the largest integer such that 128m is no more than the bit-size of P, the first m blocks P0,��, Pm−1
25
are each exactly 128 bits long, and the last block Pm is between 0 and 127 bits long (Pm could be empty, i.e.
26
0 bits long). The key is parsed as a concatenation of two fields of equal size called Key1 and Key1 such that:
27
Key = Key1 | Key2. The ciphertext C is then computed by the following or an equivalent sequence of steps:
28

Page 12
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
6
1. for q �� 0 to m-2 do
1
a) Cq �� XTS-AES-blockEnc(Key, Pj, i, q)
2
2. b �� bit-size of Pm
3
3. if b=0 then do
4
a) Cm-1 �� XTS-AES-blockEnc(Key, Pm-1, i, m-1)
5
b) Cm �� empty
6
4. else do
7
a) CC �� XTS-AES-blockEnc(Key, Pm-1, i, m-1)
8
b) Cm �� first b bits of CC
9
c) CP �� last (128-b) bits of CC
10
d) PP �� Pm | CP
11
e) Cm-1 �� XTS-AES-blockEnc(Key, PP, i, m)
12
5. C �� C0|�� |Cm-1|Cm
13 14
An illustration of encrypting the last two blocks Pm-1Pm in the case that Pm is a partial block (b>0) is
15
provided in Figure 2.
16 17
Figure 2 —XTS-AES encryption of last two blocks when last block is 1 to 127 bits
18 19 20 21
5.4 The XTS-AES Decryption Procedure
22
5.4.1 XTS-AES-blockDec Procedure, Decryption of a Single 128-bit Block
23
The XTS-AES decryption procedure of a single 128-bit block is modeled with this equation:
24
P �� XTS-AES-blockDec(Key, C, i)
25
where:
26
Key is the 256 or 512-bit XTS-AES key
27
C the 128-bit block of ciphertext
28
i is the value of the 128-bit tweak (see 5.1)
29
j is the sequential number of the 128-bit block inside the data unit
30 i, m−1 CP Cm
XTS- AES- blockEnc
Pm-1 Key
XTS- AES- blockEnc
Key i, m CC CP Pm Cm-1 PP Cm-1 Cm

Page 13
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
7 P is the 128-bit block of plaintext resulting from the operation
1
The key is parsed as a concatenation of two fields of equal size called Key1 and Key2 such that:
2
Key = Key1 | Key2. The plaintext shall then be computed by the following or an equivalent sequence of steps
3
(see Figure 3):
4
1.
T �� AES-enc(Key2 , i) ⊗ ��j
5
2.
CC �� C T
6
3.
PP �� AES-dec(Key1 , CC)
7
4.
P �� PP T
8 9
AES-dec(K,C) is the procedure of decrypting ciphertext C using AES algorithm with key K, according to
10
FIPS-197. The multiplication and computation of power in step 1 is executed in GF(2128), where �� is the
11
primitive element defined in 4.2 (see 5.2).
12 13
Figure 3 — Diagram of XTS-AES blockDec procedure
14 15 16
5.4.2 XTS-AES Decryption of a Data Unit
17
The XTS-AES decryption procedure for a data unit ciphertext of 128 or more bits is modeled with this
18
equation:
19
C �� XTS-AES-Dec(Key, C, i)
20
where:
21
Key is the 256 or 512-bit XTS-AES key
22
C is the ciphertext corresponding to the data unit
23
i is the value of the 128-bit tweak (see 5.1)
24
P is the plaintext data unit resulting from the operation, of the same bit-size as C
25
The ciphertext is first partitioned into m+1 blocks:
26
C = C0 |�� |Cm1|Cm
27

Page 14
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
8 where m is the largest integer such that 128m is no more than the bit-size of C, the first m blocks C0,��,
1
Cm−1 are each exactly 128 bits long, and the last block Cm is between 0 and 127 bits long (Pm could be
2
empty, i.e. 0 bits long). The key is parsed as a concatenation of two fields of equal size called Key1 and
3
Key1 such that: Key = Key1 | Key2. The plaintext P is then computed by the following or an equivalent
4
sequence of steps:
5
1. for q �� 0 to m-2 do
6
a) Pq �� XTS-AES-blockDec(Key, Cj, i, q)
7
2. b �� bit-size of Cm
8
3. if b=0 then do
9
a) Pm-1 �� XTS-AES-blockDec(Key, Cm-1, i, m-1)
10
b) Pm �� empty
11
4. else do
12
a) PP �� XTS-AES-blockDec(Key, Cm-1, i, m)
13
b) Pm �� first b bits of PP
14
c) CP �� last (128-b) bits of PP
15
d) CC �� Cm | CP
16
e) Pm-1 �� XTS-AES-blockDec(Key, CC, i, m-1)
17
5. P �� P0 |�� |Pm-1|Pm
18 19
An illustration of the decrypting the last two blocks Cm-1Cm in the case that Cm is a partial block (b>0) is
20
provided in Figure 4.
21 22
Figure 4 —XTS-AES decryption of last two blocks when last block is 1 to 127 bits
23 24 25 6. Using XTS-AES-128 and XTS-AES-256 for Encryption of Storage 26
The encryption and decryption procedures described in 5.3.2 and 5.4.2 use AES as the basic building block.
27
If the XTS-AES key consists of 256 bits, the procedures use 128-bit AES; if XTS-AES key consists of 512
28
bits, the procedures use 256-bit AES. For completeness, the first mode shall be referred to as XTS-AES-
29
128 and the second as XTS-AES-256. To be compliant with the standard, the implementation shall support
30
at least one of the above modes.
31 i, m CP Pm
XTS- AES- blockDec
Cm-1 Key
XTS- AES- blockDec
Key PP CP Cm Pm-1 CC Pm-1 Pm i, m−1

Page 15
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
9
1 2 3
Key scope defines the range of data encrypted with a single XTS-AES key. As defined in 7.1.4, the Key
4
Scope is represented by three integers: value of the tweak associated with the first data unit in the sequence
5
of data units encrypted by this key, the size in bits of each data unit, and the number of units to be
6
encrypted/decrypted under the control of this key. An implementation compliant with this standard may or
7
may not support multiple data unit sizes.
8 9
In an application of this standard to sector-level encryption of a disk, data unit typically corresponds to a
10
logical block, the key scope typically includes a range of consecutive logical blocks on the disk, and the
11
tweak value associated with the first data unit in the scope typically corresponds to the Logical Block
12
Address (LBA) associated with the first logical block in the range.
13 14
An XTS-AES key shall not be associated with more than one key scope. The reason is that encrypting more
15
than one block with the same key and the same index introduces security vulnerabilities that might
16
potentially be used in an attack on the system. In particular, key reuse enables trivial cut-and-paste attacks.
17 18 7. Exporting and Archiving XTS-AES-128 and XTS-AES-256 keys 19
7.1 Key Backup Structure
20
7.1.1 Key Backup Structure Overview
21 22
The system surrounding a device compliant with this standard should support the Key Backup structure
23
defined in this clause. XML representation of Key Backup structure is presented in 7.2. The Key Backup
24
structure provides all the information that is needed in order to decrypt an integral number of data units that
25
were encrypted with XTS-AES-[128,256]. These data units are assumed to be a contiguous sequence, with
26
a given tweak value (KeyScopeStart element in Table 4) associated with the first data unit.3. For example,
27
if the input data units are on a single physical medium, the initial tweak value can correspond to the first
28
data unit on this medium that is encrypted with the given XTS-AES-[128,256] key. Note that ��size�� field in
29
the following tables refers to the size of the element and not to the size of the encoding.
30
3 The inclusion of initial tweak value facilitates use of several different keys for a single physical medium.
For example, each key can correspond to a different sequence of LBAs residing on a physical disk drive. Another situation where ability to specify initial tweak value is needed is when only part of encrypted data (contiguous sequence of data units starting at some offset) is archived together with the corresponding Key Backup structure. It is impossible to decrypt this data without knowledge of the initial tweak value i.e., the tweak value that corresponds to the first data unit in the archive.

Page 16
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
10 Table 1 lists the elements of the key backup structure.
1 2
Table 1 Key Backup Structure
3 Element Description Reference
StructureID Identifier of current structure Table 2 Standard Standard identifier Table 3 KeyScope Key scope Table 4 Transform Transform description Table 5 KeyMaterial Key material and its length Table 7
4 5 6
7.1.2 Structure ID
7
Table 2 defines the StructureID element, which contains the information needed to uniquely identify a
8
particular instance of a key backup structure.
9
Table 2 StructureID
10 Element Size XML Encoding Description
ID 16 bytes Base64 General identifier for the key backup structure. Comment Up to 1024 bytes Text A text description provided by the vendor.
11
7.1.3 Standard
12
Table 3 defines the Standard element, which contains information about the standard to which the data
13
units were encrypted.
14
Table 3 Standard
15 Element Size XML Encoding Description
StandardNumber Up to 128 bytes Text Number of the Standard used. Shall be IEEE STD 1619-2007. StandardComment Up to 256 bytes Text Any additional standard- related information.
16
7.1.4 Key Scope
17
The KeyScope specifies the scope of the key material that is identified in the key backup structure. The
18
KeyScope is an ordered sequence of data units, numbered consecutively starting at a certain position. Table
19
4 defines the KeyScope element.
20

Page 17
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
11 Table 4 KeyScope
1 Element Size XML Encoding Description
KeyScopeStart 16 bytes Integer Value of the tweak associated with the first data unit in the scope. DataUnitSize 16 bytes Integer The number of bits in one data unit that is covered by the current key. KeyScopeLength 16 bytes Integer The number of data units that are covered by the current key.
2
7.1.5 Transform
3
Table 5 defines the TransformName element.
4
Table 5 Transform
5 Element Size XML Encoding Description
TransformName Up to 16 bytes Text The transform name.
6
The transform name shall be one of the supported strings, as specified in Table 6 below.
7 8
Table 6 Supported Transforms
9
String Description XTS-AES-128 The XTS-AES-128 transform as defined in this standard. XTS-AES-256 The XTS-AES-256 transform as defined in this standard.
10
7.1.6 Key Material
11
Table 7 defines the KeyMaterial element. All key material is secret.
12
Table 7 KeyMaterial
13 Element Size XML Encoding Description
KeyLength 2 bytes Integer Length (in bits) of the key. Allowed values are 256 (for XTS-AES-128) and 512 (for XTS- AES-256). KeyValue variable Base64 The value of the key.
7.2 XML Format
14
The Key Backup structure is encoded in XML, to facilitate a unified format and allow an application
15
independent way of sharing key material. This also provides an automatic generation and parsing of Key
16
backup structures. Document Type Definition (DTD) for Key Backup Format is shown in Figure 5.
17 18

Page 18
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
12 Figure 5 —DTD for Key Backup format
1 2 3 4 5
An example of an XML document containing a key for a single key scope is shown in Figure 6.
6 7
Figure 6 —XML document containing a key for a single key scope.
8 9 10 11 12 13
<!ELEMENT KeyBackup (StructureID, Standard, KeyScope, Transform, KeyMaterial)> <!ELEMENT StructureID (ID, Comment?)> <!ELEMENT ID (#PCDATA)> <!ATTLIST ID Encoding CDATA #FIXED "Base64"> <!ELEMENT Comment (#PCDATA)> <!ELEMENT Standard (StandardNumber, StandardComment?)> <!ELEMENT StandardNumber (#PCDATA)> <!ELEMENT StandardComment (#PCDATA)> <!ELEMENT KeyScope (KeyScopeStart, DataUnitSize, KeyScopeLength)> <!ELEMENT KeyScopeStart (#PCDATA)> <!ATTLIST KeyScopeStart Encoding CDATA #FIXED "Integer"> <!ELEMENT DataUnitSize (#PCDATA)> <!ATTLIST DataUnitSize Encoding CDATA #FIXED "Integer"> <!ELEMENT KeyScopeLength (#PCDATA)> <!ATTLIST KeyScopeLength Encoding CDATA #FIXED "Integer"> <!ELEMENT Transform (TransformName)> <!ELEMENT TransformName (#PCDATA)> <!ELEMENT KeyMaterial (KeyLength, KeyValue)> <!ELEMENT KeyLength (#PCDATA)> <!ATTLIST KeyLength Encoding CDATA #FIXED "Integer"> <!ELEMENT KeyValue (#PCDATA)> <!ATTLIST KeyValue Encoding CDATA #FIXED "Base64"> <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE KeyBackup SYSTEM "keybackup.dtd"> <KeyBackup> <StructureID> <ID Encoding="Base64">YUBlJHJqMDNhWjFAJCVwXQ==</ID> <Comment>Comment text here</Comment> </StructureID> <Standard> <StandardNumber>IEEE STD 1619-2007</StandardNumber> <StandardComment>Disk</StandardComment> </Standard> <KeyScope> <KeyScopeStart Encoding="Integer">0</KeyScopeStart> <DataUnitSize Encoding="Integer">4096</DataUnitSize> <KeyScopeLength Encoding="Integer">1083</KeyScopeLength> </KeyScope> <Transform> <TransformName>XTS-AES-256</TransformName> </Transform> <KeyMaterial> <KeyLength Encoding="Integer">512</KeyLength> <KeyValue Encoding="Base64"> IUApKFQlWEpHJCkoVypUJVgoKU5UJV dYKShXJVhOSlJFR0gpSCgjJWd0eDk3 d3h0NW03NTNobXR4ISNkZjRzZw== </KeyValue> </KeyMaterial> </KeyBackup>

Page 19
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
13
7.3 Encryption of Key Backup material
1
A Key backup structure may be protected as follows. The actual key material (KeyMaterial from Table 7)
2
shall be wrapped encrypted with xml-enc [XML-ENC, http://www.w3.org/TR/xmlenc-core/]] and
3
embedded within the XML key backup structure. [XML-ENC] does not mandate any single key wrapping
4
algorithm, but implementations compliant with this standard shall support NIST AES CBC 256 (see
5
http://www.w3.org/2001/04/xmlenc#aes256-cbc). Other key wrap algorithms allowed by [XML-ENC] may
6
be used.
7 8
The keys that are used to wrap the key elements (KEK) may be referenced with xkms [XML-KMS]. The
9
location of wrapping keys is not specified by this standard. The cryptographic strength of wrapping keys
10
should be at least equivalent to the strength of the storage encryption keys wrapped (see reference [KEY-
11
MGMT]). For example, an AES-256 bit key should be used to wrap an XTS-AES-512 key. The
12
implementation should provide integrity for the key file, using standard methods.
13 14
In the example in Figure 7, the KeyMaterial is encrypted using AES-256 Key Wrap, whose wrapping key,
15
referenced by the KeyInfo element, has identifier ��WrapKey��. (This xml example corresponds to the un-
16
wrapped example in Figure 6.)
17 18
Base64 encoding of the wrapping key used in the example is:
19
9s7VKp6PYKOXtYjs5OFBoqCDA3MmFd5tTqYnZv+PVro= .
20 21

Page 20
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
14
1
Figure 7 —XML for Key Scope of Figure 6 with key wrapped using AES-256 Key Wrap.
2 3 4 5 6 7 8
<KeyBackup> <StructureID> <ID Encoding="Base64">YUBlJHJqMDNhWjFAJCVwXQ==</ID> <Comment>Comment text here</Comment> </StructureID> <Standard> <StandardNumber>IEEE STD 1619-2007</StandardNumber> <StandardComment>Disk</StandardComment> </Standard> <KeyScope> <KeyScopeStart Encoding="Integer">0</KeyScopeStart> <DataUnitSize Encoding="Integer">4096</DataUnitSize> <KeyScopeLength Encoding="Integer">1083</KeyScopeLength> </KeyScope> <Transform> <TransformName>XTS-AES-256</TransformName> </Transform> <KeyMaterial> <KeyLength Encoding="Integer">512</KeyLength> <KeyValue Encoding="Base64"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> WrapKey </ds:KeyName> </ds:KeyInfo> <xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:CipherValue xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> M1uzVD5PGeoneuFP0bgG3o1bzGVRr CLG5pR00ER/eTyBTRNSEdmOyT3Q/2 ZGdNn4plzIAml5QYgCKjOTJMPWxzZFZH75/S3SHA haOYhy4DXovhf+LiiXvThqxWcGaIXS6a4+X82vBgT8j2JRqPe/+A== </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </KeyValue> </KeyMaterial> </KeyBackup>

Page 21
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
15
Annex A 1 (informative) 2 Bibliography 3
[MM82] C.H. Meyer and S. M. Matyas, ��Cryptography: a New Dimension in Computer Data Security.��
4
John Wiley & Sons, 1982.
5 6
[NR98] M. Naor and O. Reingold. ��A pseudo-random encryption mode.�� Manuscript. Available on-line
7
from http://www.wisdom.weizmann.ac.il/~naor/PAPERS/nr-mode.ps.
8 9
[LRW02] M. Liskov, R. Rivest, and D. Wagner. ��Tweakable block ciphers.�� In Advances in Cryptology –
10
CRYPTO '02. Lecture Notes in Computer Science, vol 2442, pages 31-46. Springer-Verlag, 2002.
11 12
[XEX04] P. Rogaway. ��Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes
13
OCB and PMAC��. Advances in Cryptology - Asiacrypt 2004. Lecture Notes in Computer Science, vol.
14
3329, pages 16-31. Springer-Verlag, 2004.
15 16
[S98] R. Schroeppel. ��The Hasty Pudding cipher.�� The first AES conference, NIST, 1998.
17
Available from http://www.cs.arizona.edu/~rcs/hpc.
18
(See http://csrc.nist.gov/CryptoToolkit/aes/round1/conf1/aes1conf.htm.)
19 20
[HR03] S. Halevi and P. Rogaway. ��A tweakable enciphering mode.�� In Advances in Cryptology –
21
CRYPTO '03. Lecture Notes in Computer Science, vol. 2729, pages 482-499. Springer-Verlag, 2003.
22 23
[HR04] S. Halevi and P. Rogaway. ��A parallelizable enciphering mode.�� The RSA conference -
24
Cryptographer's track, RSA-CT '04. Lecture Notes in Computer Science, vol. 2964, pages 292-304.
25
Springer-Verlag, 2004.
26 27
[H04] S. Halevi. ��EME*: extending EME to handle arbitrary-length messages with associated data,��
28
INDOCRYPT 2004, Lecture Notes in Computer Science, vol. 3348, pages 315-327. Springer-Verlag, 2004.
29 30
[KEY-MGMT] NIST Key Management Guidelines SP800-57.
31
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf and
32
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf
33 34
[XML-ENC] XML Encryption Syntax and Processing. W3C.
35
http://www.w3.org/TR/xmlenc-core
36 15 37
[XML-KMS] XML Key Management Specification (XKMS). W3C.
38
http://www.w3.org/TR/xkms
39 40
[Crypto-HBook] A. Menezes, P. Oorshot and S. Vanstone. ��Handbook of Applied Cryptography,�� CRC
41
Press, 1997.
42 43
[RFC3548] The Base16, Base32, and Base64 Data Encodings. IETF Network Working Group, July 2003.
44
http://www.ietf.org/rfc/rfc3548.txt
45 46 47

Page 22
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
16
Annex B 1 (informative) 2 Test Vectors 3 4
This Annex lists several examples of applying XTS-AES-128 and XTS-AES-256. All numbers in this
5
Annex are hexadecimal. For readability, the examples explicitly parse the XTS-AES key into Key1 and
6
Key2. All outputs are byte arrays (as opposed to hexadecimal numbers).
7 8
• PTX prefix denotes plaintext;
9
• CTX prefix denotes ciphertext.
10
• TWK prefix denotes the mask computed in step 1 in 5.3.1.
11 12
XTS-AES applied for a data unit of 32 bytes, 32 bytes key material.
13 14
Vector 1
15
Key1 00000000000000000000000000000000
16
Key2 00000000000000000000000000000000
17
Data Unit Sequence number 0
18
PTX 0000000000000000000000000000000000000000000000000000000000000000
19
TWK 66e94bd4ef8a2c3b884cfa59ca342b2eccd297a8df1559761099f4b39469565c
20
CTX 917cf69ebd68b2ec9b9fe9a3eadda692cd43d2f59598ed858c02c2652fbf922e
21 22
Vector 2
23
Key1 11111111111111111111111111111111
24
Key2 22222222222222222222222222222222
25
Data Unit Sequence number 3333333333
26
PTX 4444444444444444444444444444444444444444444444444444444444444444
27
TWK 3f803bcd0d7fd2b37558419f59d5cda6f900779a1bfea467ebb0823eb3aa9b4d
28
CTX c454185e6a16936e39334038acef838bfb186fff7480adc4289382ecd6d394f0
29 30
Vector 3
31
Key1 fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0
32
Key2 22222222222222222222222222222222
33
Data Unit Sequence number 3333333333
34
PTX 4444444444444444444444444444444444444444444444444444444444444444
35
TWK 3f803bcd0d7fd2b37558419f59d5cda6f900779a1bfea467ebb0823eb3aa9b4d
36
CTX af85336b597afc1a900b2eb21ec949d292df4c047e0b21532186a5971a227a89
37 38
XTS-AES-128 applied for a data unit of 512 bytes
39 40
Vector 4
41
Key1 27182818284590452353602874713526
42
Key2 31415926535897932384626433832795
43
Data Unit Sequence number 0
44 45
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
46
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
47
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
48
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
49
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
50
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
51
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
52
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
53
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
54
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
55

Page 23
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
17
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
1
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
2
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
3
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
4
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
5
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
6
CTX 27a7479befa1d476489f308cd4cfa6e2a96e4bbe3208ff25287dd3819616e89c
7
CTX c78cf7f5e543445f8333d8fa7f56000005279fa5d8b5e4ad40e736ddb4d35412
8
CTX 328063fd2aab53e5ea1e0a9f332500a5df9487d07a5c92cc512c8866c7e860ce
9
CTX 93fdf166a24912b422976146ae20ce846bb7dc9ba94a767aaef20c0d61ad0265
10
CTX 5ea92dc4c4e41a8952c651d33174be51a10c421110e6d81588ede82103a252d8
11
CTX a750e8768defffed9122810aaeb99f9172af82b604dc4b8e51bcb08235a6f434
12
CTX 1332e4ca60482a4ba1a03b3e65008fc5da76b70bf1690db4eae29c5f1badd03c
13
CTX 5ccf2a55d705ddcd86d449511ceb7ec30bf12b1fa35b913f9f747a8afd1b130e
14
CTX 94bff94effd01a91735ca1726acd0b197c4e5b03393697e126826fb6bbde8ecc
15
CTX 1e08298516e2c9ed03ff3c1b7860f6de76d4cecd94c8119855ef5297ca67e9f3
16
CTX e7ff72b1e99785ca0a7e7720c5b36dc6d72cac9574c8cbbc2f801e23e56fd344
17
CTX b07f22154beba0f08ce8891e643ed995c94d9a69c9f1b5f499027a78572aeebd
18
CTX 74d20cc39881c213ee770b1010e4bea718846977ae119f7a023ab58cca0ad752
19
CTX afe656bb3c17256a9f6e9bf19fdd5a38fc82bbe872c5539edb609ef4f79c203e
20
CTX bb140f2e583cb2ad15b4aa5b655016a8449277dbd477ef2c8d6c017db738b18d
21
CTX eb4a427d1923ce3ff262735779a418f20a282df920147beabe421ee5319d0568
22 23
Vector 5
24
Key1 27182818284590452353602874713526
25
Key2 31415926535897932384626433832795
26
Data Unit Sequence Number 01
27 28
PTX 27a7479befa1d476489f308cd4cfa6e2a96e4bbe3208ff25287dd3819616e89c
29
PTX c78cf7f5e543445f8333d8fa7f56000005279fa5d8b5e4ad40e736ddb4d35412
30
PTX 328063fd2aab53e5ea1e0a9f332500a5df9487d07a5c92cc512c8866c7e860ce
31
PTX 93fdf166a24912b422976146ae20ce846bb7dc9ba94a767aaef20c0d61ad0265
32
PTX 5ea92dc4c4e41a8952c651d33174be51a10c421110e6d81588ede82103a252d8
33
PTX a750e8768defffed9122810aaeb99f9172af82b604dc4b8e51bcb08235a6f434
34
PTX 1332e4ca60482a4ba1a03b3e65008fc5da76b70bf1690db4eae29c5f1badd03c
35
PTX 5ccf2a55d705ddcd86d449511ceb7ec30bf12b1fa35b913f9f747a8afd1b130e
36
PTX 94bff94effd01a91735ca1726acd0b197c4e5b03393697e126826fb6bbde8ecc
37
PTX 1e08298516e2c9ed03ff3c1b7860f6de76d4cecd94c8119855ef5297ca67e9f3
38
PTX e7ff72b1e99785ca0a7e7720c5b36dc6d72cac9574c8cbbc2f801e23e56fd344
39
PTX b07f22154beba0f08ce8891e643ed995c94d9a69c9f1b5f499027a78572aeebd
40
PTX 74d20cc39881c213ee770b1010e4bea718846977ae119f7a023ab58cca0ad752
41
PTX afe656bb3c17256a9f6e9bf19fdd5a38fc82bbe872c5539edb609ef4f79c203e
42
PTX bb140f2e583cb2ad15b4aa5b655016a8449277dbd477ef2c8d6c017db738b18d
43
PTX eb4a427d1923ce3ff262735779a418f20a282df920147beabe421ee5319d0568
44
CTX 264d3ca8512194fec312c8c9891f279fefdd608d0c027b60483a3fa811d65ee5
45
CTX 9d52d9e40ec5672d81532b38b6b089ce951f0f9c35590b8b978d175213f329bb
46
CTX 1c2fd30f2f7f30492a61a532a79f51d36f5e31a7c9a12c286082ff7d2394d18f
47
CTX 783e1a8e72c722caaaa52d8f065657d2631fd25bfd8e5baad6e527d763517501
48
CTX c68c5edc3cdd55435c532d7125c8614deed9adaa3acade5888b87bef641c4c99
49
CTX 4c8091b5bcd387f3963fb5bc37aa922fbfe3df4e5b915e6eb514717bdd2a7407
50
CTX 9a5073f5c4bfd46adf7d282e7a393a52579d11a028da4d9cd9c77124f9648ee3
51
CTX 83b1ac763930e7162a8d37f350b2f74b8472cf09902063c6b32e8c2d9290cefb
52
CTX d7346d1c779a0df50edcde4531da07b099c638e83a755944df2aef1aa31752fd
53
CTX 323dcb710fb4bfbb9d22b925bc3577e1b8949e729a90bbafeacf7f7879e7b114
54
CTX 7e28ba0bae940db795a61b15ecf4df8db07b824bb062802cc98a9545bb2aaeed
55
CTX 77cb3fc6db15dcd7d80d7d5bc406c4970a3478ada8899b329198eb61c193fb62
56
CTX 75aa8ca340344a75a862aebe92eee1ce032fd950b47d7704a3876923b4ad6284
57
CTX 4bf4a09c4dbe8b4397184b7471360c9564880aedddb9baa4af2e75394b08cd32
58
CTX ff479c57a07d3eab5d54de5f9738b8d27f27a9f0ab11799d7b7ffefb2704c95c
59
CTX 6ad12c39f1e867a4b7b1d7818a4b753dfd2a89ccb45e001a03a867b187f225dd
60 61
Vector 6
62
Key1 27182818284590452353602874713526
63
Key2 31415926535897932384626433832795
64

Page 24
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
18
Data Unit Sequence Number 02
1 2
PTX 264d3ca8512194fec312c8c9891f279fefdd608d0c027b60483a3fa811d65ee5
3
PTX 9d52d9e40ec5672d81532b38b6b089ce951f0f9c35590b8b978d175213f329bb
4
PTX 1c2fd30f2f7f30492a61a532a79f51d36f5e31a7c9a12c286082ff7d2394d18f
5
PTX 783e1a8e72c722caaaa52d8f065657d2631fd25bfd8e5baad6e527d763517501
6
PTX c68c5edc3cdd55435c532d7125c8614deed9adaa3acade5888b87bef641c4c99
7
PTX 4c8091b5bcd387f3963fb5bc37aa922fbfe3df4e5b915e6eb514717bdd2a7407
8
PTX 9a5073f5c4bfd46adf7d282e7a393a52579d11a028da4d9cd9c77124f9648ee3
9
PTX 83b1ac763930e7162a8d37f350b2f74b8472cf09902063c6b32e8c2d9290cefb
10
PTX d7346d1c779a0df50edcde4531da07b099c638e83a755944df2aef1aa31752fd
11
PTX 323dcb710fb4bfbb9d22b925bc3577e1b8949e729a90bbafeacf7f7879e7b114
12
PTX 7e28ba0bae940db795a61b15ecf4df8db07b824bb062802cc98a9545bb2aaeed
13
PTX 77cb3fc6db15dcd7d80d7d5bc406c4970a3478ada8899b329198eb61c193fb62
14
PTX 75aa8ca340344a75a862aebe92eee1ce032fd950b47d7704a3876923b4ad6284
15
PTX 4bf4a09c4dbe8b4397184b7471360c9564880aedddb9baa4af2e75394b08cd32
16
PTX ff479c57a07d3eab5d54de5f9738b8d27f27a9f0ab11799d7b7ffefb2704c95c
17
PTX 6ad12c39f1e867a4b7b1d7818a4b753dfd2a89ccb45e001a03a867b187f225dd
18
CTX fa762a3680b76007928ed4a4f49a9456031b704782e65e16cecb54ed7d017b5e
19
CTX 18abd67b338e81078f21edb7868d901ebe9c731a7c18b5e6dec1d6a72e078ac9
20
CTX a4262f860beefa14f4e821018272e411a951502b6e79066e84252c3346f3aa62
21
CTX 344351a291d4bedc7a07618bdea2af63145cc7a4b8d4070691ae890cd65733e7
22
CTX 946e9021a1dffc4c59f159425ee6d50ca9b135fa6162cea18a939838dc000fb3
23
CTX 86fad086acce5ac07cb2ece7fd580b00cfa5e98589631dc25e8e2a3daf2ffdec
24
CTX 26531659912c9d8f7a15e5865ea8fb5816d6207052bd7128cd743c12c8118791
25
CTX a4736811935eb982a532349e31dd401e0b660a568cb1a4711f552f55ded59f1f
26
CTX 15bf7196b3ca12a91e488ef59d64f3a02bf45239499ac6176ae321c4a211ec54
27
CTX 5365971c5d3f4f09d4eb139bfdf2073d33180b21002b65cc9865e76cb24cd92c
28
CTX 874c24c18350399a936ab3637079295d76c417776b94efce3a0ef7206b151105
29
CTX 19655c956cbd8b2489405ee2b09a6b6eebe0c53790a12a8998378b33a5b71159
30
CTX 625f4ba49d2a2fdba59fbf0897bc7aabd8d707dc140a80f0f309f835d3da54ab
31
CTX 584e501dfa0ee977fec543f74186a802b9a37adb3e8291eca04d66520d229e60
32
CTX 401e7282bef486ae059aa70696e0e305d777140a7a883ecdcb69b9ff938e8a42
33
CTX 31864c69ca2c2043bed007ff3e605e014bcf518138dc3a25c5e236171a2d01d6
34 35
Vector 7
36
Key1 27182818284590452353602874713526
37
Key2 31415926535897932384626433832795
38
Data Unit Sequence Number fd
39 40
PTX 8e41b78c390b5af9d758bb214a67e9f6bf7727b09ac6124084c37611398fa45d
41
PTX aad94868600ed391fb1acd4857a95b466e62ef9f4b377244d1c152e7b30d731a
42
PTX ad30c716d214b707aed99eb5b5e580b3e887cf7497465651d4b60e6042051da3
43
PTX 693c3b78c14489543be8b6ad0ba629565bba202313ba7b0d0c94a3252b676f46
44
PTX cc02ce0f8a7d34c0ed229129673c1f61aed579d08a9203a25aac3a77e9db6026
45
PTX 7996db38df637356d9dcd1632e369939f2a29d89345c66e05066f1a3677aef18
46
PTX dea4113faeb629e46721a66d0a7e785d3e29af2594eb67dfa982affe0aac058f
47
PTX 6e15864269b135418261fc3afb089472cf68c45dd7f231c6249ba0255e1e0338
48
PTX 33fc4d00a3fe02132d7bc3873614b8aee34273581ea0325c81f0270affa13641
49
PTX d052d36f0757d484014354d02d6883ca15c24d8c3956b1bd027bcf41f151fd80
50
PTX 23c5340e5606f37e90fdb87c86fb4fa634b3718a30bace06a66eaf8f63c4aa3b
51
PTX 637826a87fe8cfa44282e92cb1615af3a28e53bc74c7cba1a0977be9065d0c1a
52
PTX 5dec6c54ae38d37f37aa35283e048e5530a85c4e7a29d7b92ec0c3169cdf2a80
53
PTX 5c7604bce60049b9fb7b8eaac10f51ae23794ceba68bb58112e293b9b692ca72
54
PTX 1b37c662f8574ed4dba6f88e170881c82cddc1034a0ca7e284bf0962b6b26292
55
PTX d836fa9f73c1ac770eef0f2d3a1eaf61d3e03555fd424eedd67e18a18094f888
56
CTX d55f684f81f4426e9fde92a5ff02df2ac896af63962888a97910c1379e20b0a3
57
CTX b1db613fb7fe2e07004329ea5c22bfd33e3dbe4cf58cc608c2c26c19a2e2fe22
58
CTX f98732c2b5cb844cc6c0702d91e1d50fc4382a7eba5635cd602432a2306ac4ce
59
CTX 82f8d70c8d9bc15f918fe71e74c622d5cf71178bf6e0b9cc9f2b41dd8dbe441c
60
CTX 41cd0c73a6dc47a348f6702f9d0e9b1b1431e948e299b9ec2272ab2c5f0c7be8
61
CTX 6affa5dec87a0bee81d3d50007edaa2bcfccb35605155ff36ed8edd4a40dcd4b
62
CTX 243acd11b2b987bdbfaf91a7cac27e9c5aea525ee53de7b2d3332c8644402b82
63
CTX 3e94a7db26276d2d23aa07180f76b4fd29b9c0823099c9d62c519880aee7e969
64

Page 25
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
19
CTX 7617c1497d47bf3e571950311421b6b734d38b0db91eb85331b91ea9f61530f5
1
CTX 4512a5a52a4bad589eb69781d537f23297bb459bdad2948a29e1550bf4787e0b
2
CTX e95bb173cf5fab17dab7a13a052a63453d97ccec1a321954886b7a1299faaeec
3
CTX ae35c6eaaca753b041b5e5f093bf83397fd21dd6b3012066fcc058cc32c3b09d
4
CTX 7562dee29509b5839392c9ff05f51f3166aaac4ac5f238038a3045e6f72e48ef
5
CTX 0fe8bc675e82c318a268e43970271bf119b81bf6a982746554f84e72b9f00280
6
CTX a320a08142923c23c883423ff949827f29bbacdc1ccdb04938ce6098c95ba6b3
7
CTX 2528f4ef78eed778b2e122ddfd1cbdd11d1c0a6783e011fc536d63d053260637
8 9
Vector 8
10
Key1 27182818284590452353602874713526
11
Key2 31415926535897932384626433832795
12
Data Unit Sequence Number fe
13 14
PTX d55f684f81f4426e9fde92a5ff02df2ac896af63962888a97910c1379e20b0a3
15
PTX b1db613fb7fe2e07004329ea5c22bfd33e3dbe4cf58cc608c2c26c19a2e2fe22
16
PTX f98732c2b5cb844cc6c0702d91e1d50fc4382a7eba5635cd602432a2306ac4ce
17
PTX 82f8d70c8d9bc15f918fe71e74c622d5cf71178bf6e0b9cc9f2b41dd8dbe441c
18
PTX 41cd0c73a6dc47a348f6702f9d0e9b1b1431e948e299b9ec2272ab2c5f0c7be8
19
PTX 6affa5dec87a0bee81d3d50007edaa2bcfccb35605155ff36ed8edd4a40dcd4b
20
PTX 243acd11b2b987bdbfaf91a7cac27e9c5aea525ee53de7b2d3332c8644402b82
21
PTX 3e94a7db26276d2d23aa07180f76b4fd29b9c0823099c9d62c519880aee7e969
22
PTX 7617c1497d47bf3e571950311421b6b734d38b0db91eb85331b91ea9f61530f5
23
PTX 4512a5a52a4bad589eb69781d537f23297bb459bdad2948a29e1550bf4787e0b
24
PTX e95bb173cf5fab17dab7a13a052a63453d97ccec1a321954886b7a1299faaeec
25
PTX ae35c6eaaca753b041b5e5f093bf83397fd21dd6b3012066fcc058cc32c3b09d
26
PTX 7562dee29509b5839392c9ff05f51f3166aaac4ac5f238038a3045e6f72e48ef
27
PTX 0fe8bc675e82c318a268e43970271bf119b81bf6a982746554f84e72b9f00280
28
PTX a320a08142923c23c883423ff949827f29bbacdc1ccdb04938ce6098c95ba6b3
29
PTX 2528f4ef78eed778b2e122ddfd1cbdd11d1c0a6783e011fc536d63d053260637
30
CTX 72efc1ebfe1ee25975a6eb3aa8589dda2b261f1c85bdab442a9e5b2dd1d7c395
31
CTX 7a16fc08e526d4b1223f1b1232a11af274c3d70dac57f83e0983c498f1a6f1ae
32
CTX cb021c3e70085a1e527f1ce41ee5911a82020161529cd82773762daf5459de94
33
CTX a0a82adae7e1703c808543c29ed6fb32d9e004327c1355180c995a07741493a0
34
CTX 9c21ba01a387882da4f62534b87bb15d60d197201c0fd3bf30c1500a3ecfecdd
35
CTX 66d8721f90bcc4c17ee925c61b0a03727a9c0d5f5ca462fbfa0af1c2513a9d9d
36
CTX 4b5345bd27a5f6e653f751693e6b6a2b8ead57d511e00e58c45b7b8d005af792
37
CTX 88f5c7c22fd4f1bf7a898b03a5634c6a1ae3f9fae5de4f296a2896b23e7ed43e
38
CTX d14fa5a2803f4d28f0d3ffcf24757677aebdb47bb388378708948a8d4126ed18
39
CTX 39e0da29a537a8c198b3c66ab00712dd261674bf45a73d67f76914f830ca014b
40
CTX 65596f27e4cf62de66125a5566df9975155628b400fbfb3a29040ed50faffdbb
41
CTX 18aece7c5c44693260aab386c0a37b11b114f1c415aebb653be468179428d43a
42
CTX 4d8bc3ec38813eca30a13cf1bb18d524f1992d44d8b1a42ea30b22e6c95b199d
43
CTX 8d182f8840b09d059585c31ad691fa0619ff038aca2c39a943421157361717c4
44
CTX 9d322028a74648113bd8c9d7ec77cf3c89c1ec8718ceff8516d96b34c3c614f1
45
CTX 0699c9abc4ed0411506223bea16af35c883accdbe1104eef0cfdb54e12fb230a
46 47
Vector 9
48
Key1 27182818284590452353602874713526
49
Key2 31415926535897932384626433832795
50
Data Unit Sequence Number ff
51 52
PTX 72efc1ebfe1ee25975a6eb3aa8589dda2b261f1c85bdab442a9e5b2dd1d7c395
53
PTX 7a16fc08e526d4b1223f1b1232a11af274c3d70dac57f83e0983c498f1a6f1ae
54
PTX cb021c3e70085a1e527f1ce41ee5911a82020161529cd82773762daf5459de94
55
PTX a0a82adae7e1703c808543c29ed6fb32d9e004327c1355180c995a07741493a0
56
PTX 9c21ba01a387882da4f62534b87bb15d60d197201c0fd3bf30c1500a3ecfecdd
57
PTX 66d8721f90bcc4c17ee925c61b0a03727a9c0d5f5ca462fbfa0af1c2513a9d9d
58
PTX 4b5345bd27a5f6e653f751693e6b6a2b8ead57d511e00e58c45b7b8d005af792
59
PTX 88f5c7c22fd4f1bf7a898b03a5634c6a1ae3f9fae5de4f296a2896b23e7ed43e
60
PTX d14fa5a2803f4d28f0d3ffcf24757677aebdb47bb388378708948a8d4126ed18
61
PTX 39e0da29a537a8c198b3c66ab00712dd261674bf45a73d67f76914f830ca014b
62
PTX 65596f27e4cf62de66125a5566df9975155628b400fbfb3a29040ed50faffdbb
63
PTX 18aece7c5c44693260aab386c0a37b11b114f1c415aebb653be468179428d43a
64

Page 26
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
20
PTX 4d8bc3ec38813eca30a13cf1bb18d524f1992d44d8b1a42ea30b22e6c95b199d
1
PTX 8d182f8840b09d059585c31ad691fa0619ff038aca2c39a943421157361717c4
2
PTX 9d322028a74648113bd8c9d7ec77cf3c89c1ec8718ceff8516d96b34c3c614f1
3
PTX 0699c9abc4ed0411506223bea16af35c883accdbe1104eef0cfdb54e12fb230a
4
CTX 3260ae8dad1f4a32c5cafe3ab0eb95549d461a67ceb9e5aa2d3afb62dece0553
5
CTX 193ba50c75be251e08d1d08f1088576c7efdfaaf3f459559571e12511753b07a
6
CTX f073f35da06af0ce0bbf6b8f5ccc5cea500ec1b211bd51f63b606bf6528796ca
7
CTX 12173ba39b8935ee44ccce646f90a45bf9ccc567f0ace13dc2d53ebeedc81f58
8
CTX b2e41179dddf0d5a5c42f5d8506c1a5d2f8f59f3ea873cbcd0eec19acbf32542
9
CTX 3bd3dcb8c2b1bf1d1eaed0eba7f0698e4314fbeb2f1566d1b9253008cbccf45a
10
CTX 2b0d9c5c9c21474f4076e02be26050b99dee4fd68a4cf890e496e4fcae7b70f9
11
CTX 4ea5a9062da0daeba1993d2ccd1dd3c244b8428801495a58b216547e7e847c46
12
CTX d1d756377b6242d2e5fb83bf752b54e0df71e889f3a2bb0f4c10805bf3c59037
13
CTX 6e3c24e22ff57f7fa965577375325cea5d920db94b9c336b455f6e894c01866f
14
CTX e9fbb8c8d3f70a2957285f6dfb5dcd8cbf54782f8fe7766d4723819913ac7734
15
CTX 21e3a31095866bad22c86a6036b2518b2059b4229d18c8c2ccbdf906c6cc6e82
16
CTX 464ee57bddb0bebcb1dc645325bfb3e665ef7251082c88ebb1cf203bd779fdd3
17
CTX 8675713c8daadd17e1cabee432b09787b6ddf3304e38b731b45df5df51b78fcf
18
CTX b3d32466028d0ba36555e7e11ab0ee0666061d1645d962444bc47a38188930a8
19
CTX 4b4d561395c73c087021927ca638b7afc8a8679ccb84c26555440ec7f10445cd
20 21 22
XTS-AES-256 applied for a data unit of 512 bytes
23 24
Vector 10
25
Key1 2718281828459045235360287471352662497757247093699959574966967627
26
Key2 3141592653589793238462643383279502884197169399375105820974944592
27
Data Unit Sequence Number ff
28 29
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
30
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
31
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
32
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
33
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
34
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
35
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
36
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
37
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
38
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
39
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
40
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
41
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
42
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
43
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
44
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
45
CTX 1c3b3a102f770386e4836c99e370cf9bea00803f5e482357a4ae12d414a3e63b
46
CTX 5d31e276f8fe4a8d66b317f9ac683f44680a86ac35adfc3345befecb4bb188fd
47
CTX 5776926c49a3095eb108fd1098baec70aaa66999a72a82f27d848b21d4a741b0
48
CTX c5cd4d5fff9dac89aeba122961d03a757123e9870f8acf1000020887891429ca
49
CTX 2a3e7a7d7df7b10355165c8b9a6d0a7de8b062c4500dc4cd120c0f7418dae3d0
50
CTX b5781c34803fa75421c790dfe1de1834f280d7667b327f6c8cd7557e12ac3a0f
51
CTX 93ec05c52e0493ef31a12d3d9260f79a289d6a379bc70c50841473d1a8cc81ec
52
CTX 583e9645e07b8d9670655ba5bbcfecc6dc3966380ad8fecb17b6ba02469a020a
53
CTX 84e18e8f84252070c13e9f1f289be54fbc481457778f616015e1327a02b140f1
54
CTX 505eb309326d68378f8374595c849d84f4c333ec4423885143cb47bd71c5edae
55
CTX 9be69a2ffeceb1bec9de244fbe15992b11b77c040f12bd8f6a975a44a0f90c29
56
CTX a9abc3d4d893927284c58754cce294529f8614dcd2aba991925fedc4ae74ffac
57
CTX 6e333b93eb4aff0479da9a410e4450e0dd7ae4c6e2910900575da401fc07059f
58
CTX 645e8b7e9bfdef33943054ff84011493c27b3429eaedb4ed5376441a77ed4385
59
CTX 1ad77f16f541dfd269d50d6a5f14fb0aab1cbb4c1550be97f7ab4066193c4caa
60
CTX 773dad38014bd2092fa755c824bb5e54c4f36ffda9fcea70b9c6e693e148c151
61
GEN
62 63

Page 27
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
21
Vector 11
1
Key1 2718281828459045235360287471352662497757247093699959574966967627
2
Key2 3141592653589793238462643383279502884197169399375105820974944592
3
Data Unit Sequence Number ffff
4 5
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
6
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
7
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
8
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
9
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
10
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
11
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
12
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
13
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
14
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
15
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
16
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
17
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
18
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
19
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
20
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
21
CTX 77a31251618a15e6b92d1d66dffe7b50b50bad552305ba0217a610688eff7e11
22
CTX e1d0225438e093242d6db274fde801d4cae06f2092c728b2478559df58e837c2
23
CTX 469ee4a4fa794e4bbc7f39bc026e3cb72c33b0888f25b4acf56a2a9804f1ce6d
24
CTX 3d6e1dc6ca181d4b546179d55544aa7760c40d06741539c7e3cd9d2f6650b201
25
CTX 3fd0eeb8c2b8e3d8d240ccae2d4c98320a7442e1c8d75a42d6e6cfa4c2eca179
26
CTX 8d158c7aecdf82490f24bb9b38e108bcda12c3faf9a21141c3613b58367f922a
27
CTX aa26cd22f23d708dae699ad7cb40a8ad0b6e2784973dcb605684c08b8d6998c6
28
CTX 9aac049921871ebb65301a4619ca80ecb485a31d744223ce8ddc2394828d6a80
29
CTX 470c092f5ba413c3378fa6054255c6f9df4495862bbb3287681f931b687c888a
30
CTX bf844dfc8fc28331e579928cd12bd2390ae123cf03818d14dedde5c0c24c8ab0
31
CTX 18bfca75ca096f2d531f3d1619e785f1ada437cab92e980558b3dce1474afb75
32
CTX bfedbf8ff54cb2618e0244c9ac0d3c66fb51598cd2db11f9be39791abe447c63
33
CTX 094f7c453b7ff87cb5bb36b7c79efb0872d17058b83b15ab0866ad8a58656c5a
34
CTX 7e20dbdf308b2461d97c0ec0024a2715055249cf3b478ddd4740de654f75ca68
35
CTX 6e0d7345c69ed50cdc2a8b332b1f8824108ac937eb050585608ee734097fc090
36
CTX 54fbff89eeaeea791f4a7ab1f9868294a4f9e27b42af8100cb9d59cef9645803
37 38
Vector 12
39
Key1 2718281828459045235360287471352662497757247093699959574966967627
40
Key2 3141592653589793238462643383279502884197169399375105820974944592
41
Data Unit Sequence Number ffffff
42 43
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
44
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
45
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
46
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
47
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
48
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
49
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
50
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
51
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
52
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
53
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
54
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
55
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
56
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
57
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
58
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
59
CTX e387aaa58ba483afa7e8eb469778317ecf4cf573aa9d4eac23f2cdf914e4e200
60
CTX a8b490e42ee646802dc6ee2b471b278195d60918ececb44bf79966f83faba049
61
CTX 9298ebc699c0c8634715a320bb4f075d622e74c8c932004f25b41e361025b5a8
62
CTX 7815391f6108fc4afa6a05d9303c6ba68a128a55705d415985832fdeaae6c8e1
63
CTX 9110e84d1b1f199a2692119edc96132658f09da7c623efcec712537a3d94c0bf
64

Page 28
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
22
CTX 5d7e352ec94ae5797fdb377dc1551150721adf15bd26a8efc2fcaad56881fa9e
1
CTX 62462c28f30ae1ceaca93c345cf243b73f542e2074a705bd2643bb9f7cc79bb6
2
CTX e7091ea6e232df0f9ad0d6cf502327876d82207abf2115cdacf6d5a48f6c1879
3
CTX a65b115f0f8b3cb3c59d15dd8c769bc014795a1837f3901b5845eb491adfefe0
4
CTX 97b1fa30a12fc1f65ba22905031539971a10f2f36c321bb51331cdefb39e3964
5
CTX c7ef079994f5b69b2edd83a71ef549971ee93f44eac3938fcdd61d01fa71799d
6
CTX a3a8091c4c48aa9ed263ff0749df95d44fef6a0bb578ec69456aa5408ae32c7a
7
CTX f08ad7ba8921287e3bbee31b767be06a0e705c864a769137df28292283ea81a2
8
CTX 480241b44d9921cdbec1bc28dc1fda114bd8e5217ac9d8ebafa720e9da4f9ace
9
CTX 231cc949e5b96fe76ffc21063fddc83a6b8679c00d35e09576a875305bed5f36
10
CTX ed242c8900dd1fa965bc950dfce09b132263a1eef52dd6888c309f5a7d712826
11 12
Vector 13
13
Key1 2718281828459045235360287471352662497757247093699959574966967627
14
Key2 3141592653589793238462643383279502884197169399375105820974944592
15
Data Unit Sequence Number ffffffff
16 17
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
18
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
19
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
20
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
21
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
22
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
23
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
24
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
25
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
26
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
27
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
28
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
29
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
30
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
31
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
32
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
33
CTX bf53d2dade78e822a4d949a9bc6766b01b06a8ef70d26748c6a7fc36d80ae4c5
34
CTX 520f7c4ab0ac8544424fa405162fef5a6b7f229498063618d39f0003cb5fb8d1
35
CTX c86b643497da1ff945c8d3bedeca4f479702a7a735f043ddb1d6aaade3c4a0ac
36
CTX 7ca7f3fa5279bef56f82cd7a2f38672e824814e10700300a055e1630b8f1cb0e
37
CTX 919f5e942010a416e2bf48cb46993d3cb6a51c19bacf864785a00bc2ecff15d3
38
CTX 50875b246ed53e68be6f55bd7e05cfc2b2ed6432198a6444b6d8c247fab941f5
39
CTX 69768b5c429366f1d3f00f0345b96123d56204c01c63b22ce78baf116e525ed9
40
CTX 0fdea39fa469494d3866c31e05f295ff21fea8d4e6e13d67e47ce722e9698a1c
41
CTX 1048d68ebcde76b86fcf976eab8aa9790268b7068e017a8b9b749409514f1053
42
CTX 027fd16c3786ea1bac5f15cb79711ee2abe82f5cf8b13ae73030ef5b9e4457e7
43
CTX 5d1304f988d62dd6fc4b94ed38ba831da4b7634971b6cd8ec325d9c61c00f1df
44
CTX 73627ed3745a5e8489f3a95c69639c32cd6e1d537a85f75cc844726e8a72fc00
45
CTX 77ad22000f1d5078f6b866318c668f1ad03d5a5fced5219f2eabbd0aa5c0f460
46
CTX d183f04404a0d6f469558e81fab24a167905ab4c7878502ad3e38fdbe62a4155
47
CTX 6cec37325759533ce8f25f367c87bb5578d667ae93f9e2fd99bcbc5f2fbba88c
48
CTX f6516139420fcff3b7361d86322c4bd84c82f335abb152c4a93411373aaa8220
49 50
Vector 14
51
Key1 2718281828459045235360287471352662497757247093699959574966967627
52
Key2 3141592653589793238462643383279502884197169399375105820974944592
53
Data Unit Sequence Number ffffffffff
54 55
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
56
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
57
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
58
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
59
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
60
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
61
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
62
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
63
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
64

Page 29
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
23
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
1
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
2
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
3
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
4
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
5
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
6
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
7
CTX 64497e5a831e4a932c09be3e5393376daa599548b816031d224bbf50a818ed23
8
CTX 50eae7e96087c8a0db51ad290bd00c1ac1620857635bf246c176ab463be30b80
9
CTX 8da548081ac847b158e1264be25bb0910bbc92647108089415d45fab1b3d2604
10
CTX e8a8eff1ae4020cfa39936b66827b23f371b92200be90251e6d73c5f86de5fd4
11
CTX a950781933d79a28272b782a2ec313efdfcc0628f43d744c2dc2ff3dcb66999b
12
CTX 50c7ca895b0c64791eeaa5f29499fb1c026f84ce5b5c72ba1083cddb5ce45434
13
CTX 631665c333b60b11593fb253c5179a2c8db813782a004856a1653011e93fb6d8
14
CTX 76c18366dd8683f53412c0c180f9c848592d593f8609ca736317d356e13e2bff
15
CTX 3a9f59cd9aeb19cd482593d8c46128bb32423b37a9adfb482b99453fbe25a41b
16
CTX f6feb4aa0bef5ed24bf73c762978025482c13115e4015aac992e5613a3b5c2f6
17
CTX 85b84795cb6e9b2656d8c88157e52c42f978d8634c43d06fea928f2822e465aa
18
CTX 6576e9bf419384506cc3ce3c54ac1a6f67dc66f3b30191e698380bc999b05abc
19
CTX e19dc0c6dcc2dd001ec535ba18deb2df1a101023108318c75dc98611a09dc48a
20
CTX 0acdec676fabdf222f07e026f059b672b56e5cbc8e1d21bbd867dd9272120546
21
CTX 81d70ea737134cdfce93b6f82ae22423274e58a0821cc5502e2d0ab4585e94de
22
CTX 6975be5e0b4efce51cd3e70c25a1fbbbd609d273ad5b0d59631c531f6a0a57b9
23 24
XTS-AES-128 applied for a data unit that is not a multiple of 16 bytes
25 26
Vector 15
27
Key1 fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0
28
Key2 bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0
29
Data unit sequence number 9a78563412
30 31
PTX 000102030405060708090a0b0c0d0e0f10
32
CTX 6c1625db4671522d3d7599601de7ca09ed
33 34
Vector 16
35
Key1 fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0
36
Key2 bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0
37
Data unit sequence number 9a78563412
38 39
PTX 000102030405060708090a0b0c0d0e0f1011
40
CTX d069444b7a7e0cab09e24447d24deb1fedbf
41 42
Vector 17
43
Key1 fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0
44
Key2 bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0
45
Data unit sequence number 9a78563412
46 47
PTX 000102030405060708090a0b0c0d0e0f101112
48
CTX e5df1351c0544ba1350b3363cd8ef4beedbf9d
49 50
Vector 18
51
Key1 fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0
52
Key2 bfbebdbcbbbab9b8b7b6b5b4b3b2b1b0
53
Data unit sequence number 9a78563412
54 55
PTX 000102030405060708090a0b0c0d0e0f10111213
56
CTX 9d84c813f719aa2c7be3f66171c7c5c2edbf9dac
57 58
Vector 19
59
Key1 e0e1e2e3e4e5e6e7e8e9eaebecedeeef
60
Key2 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
61
Data unit sequence number 21436587a9
62 63
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
64

Page 30
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
24
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
1
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
2
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
3
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
4
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
5
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
6
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
7
PTX 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
8
PTX 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
9
PTX 404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f
10
PTX 606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f
11
PTX 808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f
12
PTX a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
13
PTX c0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedf
14
PTX e0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff
15
CTX 38b45812ef43a05bd957e545907e223b954ab4aaf088303ad910eadf14b42be6
16
CTX 8b2461149d8c8ba85f992be970bc621f1b06573f63e867bf5875acafa04e42cc
17
CTX bd7bd3c2a0fb1fff791ec5ec36c66ae4ac1e806d81fbf709dbe29e471fad3854
18
CTX 9c8e66f5345d7c1eb94f405d1ec785cc6f6a68f6254dd8339f9d84057e01a177
19
CTX 41990482999516b5611a38f41bb6478e6f173f320805dd71b1932fc333cb9ee3
20
CTX 9936beea9ad96fa10fb4112b901734ddad40bc1878995f8e11aee7d141a2f5d4
21
CTX 8b7a4e1e7f0b2c04830e69a4fd1378411c2f287edf48c6c4e5c247a19680f7fe
22
CTX 41cefbd49b582106e3616cbbe4dfb2344b2ae9519391f3e0fb4922254b1d6d2d
23
CTX 19c6d4d537b3a26f3bcc51588b32f3eca0829b6a5ac72578fb814fb43cf80d64
24
CTX a233e3f997a3f02683342f2b33d25b492536b93becb2f5e1a8b82f5b88334272
25
CTX 9e8ae09d16938841a21a97fb543eea3bbff59f13c1a18449e398701c1ad51648
26
CTX 346cbc04c27bb2da3b93a1372ccae548fb53bee476f9e9c91773b1bb19828394
27
CTX d55d3e1a20ed69113a860b6829ffa847224604435070221b257e8dff783615d2
28
CTX cae4803a93aa4334ab482a0afac9c0aeda70b45a481df5dec5df8cc0f423c77a
29
CTX 5fd46cd312021d4b438862419a791be03bb4d97c0e59578542531ba466a83baf
30
CTX 92cefc151b5cc1611a167893819b63fb8a6b18e86de60290fa72b797b0ce59f3
31

Page 31
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
25
Annex C 1 (informative) 2 Pseudocode for XTS-AES-128 and XTS-AES-256 Encryption 3
C.1 Encryption of a data unit with a size that is a multiple of 16 bytes
4
#define GF_128_FDBK 0x87
5
#define AES_BLK_BYTES 16
6
void XTS_EncryptSector
7
(
8
AES_Key &k2, // key used for tweaking
9
AES_Key &k1, // key used for "ECB" encryption
10
u64b S, // data unit number (64 bits)
11
uint N, // sector size, in bytes
12
const u08b *pt, // plaintext sector input data
13
u08b *ct // ciphertext sector output data
14
)
15
{
16
uint i,j; // local counters
17
u08b T[AES_BLK_BYTES]; // tweak value
18
u08b x[AES_BLK_BYTES]; // local work value
19
u08b Cin,Cout; // "carry" bits for LFSR shifting
20 21
assert(N % AES_BLK_BYTES == 0); // data unit is multiple of 16 bytes
22 23
for (j=0;j<AES_BLK_BYTES;j++)
24
{ // convert sector number to tweak plaintext
25
T[j] = (u08b) (S & 0xFF);
26
S = S >> 8; // also note that T[] is padded with zeroes
27
}
28 29
AES_ECB_Encrypt(k2,T); // encrypt the tweak
30 31
for (i=0;i<N;i+=AES_BLK_BYTES) // now encrypt the data unit, AES_BLK_BYTES at a time
32
{
33
// merge the tweak into the input block
34
for (j=0;j<AES_BLK_BYTES;j++)
35
x[j] = pt[i+j] ^ T[j];
36 37
// encrypt one block
38
AES_ECB_Encrypt(k1,x);
39 40
// merge the tweak into the output block
41
for (j=0;j<AES_BLK_BYTES;j++)
42
ct[i+j] = x[j] ^ T[j];
43 44
// Multiply T by ��
45
Cin = 0;
46
for (j=0;j<AES_BLK_BYTES;j++)
47
{
48
Cout = (T[j] >> 7) & 1;
49
T[j] = ((T[j] << 1) + Cin) & 0xFF;
50
Cin = Cout;
51
}
52
if (Cout)
53
T[0] ^= GF_128_FDBK;
54
}
55
}
56 57 58

Page 32
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
26
C.2 Encryption of a data unit with a size that is not a multiple of 16 bytes
1
#define GF_128_FDBK 0x87
2
#define AES_BLK_BYTES 16
3 4
void XTS_EncryptSector
5
(
6
AES_Key &k2, // key used for generating sector "tweak"
7
AES_Key &k1, // key used for "ECB" encryption
8
u64b S, // sector number (64 bits)
9
uint N, // sector size, in bytes
10
const u08b *pt, // plaintext sector input data
11
u08b *ct // ciphertext sector output data
12
)
13
{
14
uint i,j; // local counters
15
u08b T[AES_BLK_BYTES]; // tweak value
16
u08b x[AES_BLK_BYTES]; // local work value
17
u08b Cin,Cout; // "carry" bits for LFSR shifting
18 19
assert(N >= AES_BLK_BYTES); // need at least a full AES block
20 21
for (j=0;j<AES_BLK_BYTES;j++)
22
{ // convert sector number to tweak plaintext
23
T[j] = (u08b) (S & 0xFF);
24
S = S >> 8; // also note that T[] is padded with zeroes
25
}
26 27
AES_ECB_Encrypt(k2,T); // encrypt the tweak
28
for (i=0;i+AES_BLK_BYTES <= N;i+=AES_BLK_BYTES)
29
{ // now encrypt the sector data
30
// merge the tweak into the input block
31
for (j=0;j<AES_BLK_BYTES;j++)
32
x[j] = pt[i+j] ^ T[j];
33 34
// encrypt one block
35
AES_ECB_Encrypt(k1,x);
36 37
// merge the tweak into the output block
38
for (j=0;j<AES_BLK_BYTES;j++)
39
ct[i+j] = x[j] ^ T[j];
40 41
// LFSR "shift" the tweak value for the next location
42
Cin = 0;
43
for (j=0;j<AES_BLK_BYTES;j++)
44
{
45
Cout = (T[j] >> 7) & 1;
46
T[j] = ((T[j] << 1) + Cin) & 0xFF;
47
Cin = Cout;
48
}
49
if (Cout)
50
T[0] ^= GF_128_FDBK;
51
}
52
if (i < N) // is there a final partial block to handle?
53
{
54
for (j=0;i+j<N;j++)
55
{
56
x[j] = pt[i+j] ^ T[j]; // copy in the final plaintext bytes
57
ct[i+j] = ct[i+j-AES_BLK_BYTES]; // and copy out the final ciphertext bytes
58
}
59
for (;j<AES_BLK_BYTES;j++) // "steal" ciphertext to complete the block
60
x[j] = ct[i+j-AES_BLK_BYTES] ^ T[j];
61
// encrypt the final block
62
AES_ECB_Encrypt(k1,x);
63 64
// merge the tweak into the output block
65
for (j=0;j<AES_BLK_BYTES;j++)
66
ct[i+j-AES_BLK_BYTES] = x[j] ^ T[j];
67
}
68
}
69

Page 33
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
27
Annex D 1 (informative) 2 Rationale and Design Choices 3
D.1 Purpose
4
This Annex provides some background material regarding design choices that were made in XTS-AES and
5
the rationale behind these choices.
6
D.2 Transparent Encryption
7
The starting point for this standard is a requirement that the transform be usable as transparent encryption.
8
That is, it should be possible to insert an encryption/decryption module into existing data paths without
9
having to change the data layout or message formats of other components on these data paths. In particular,
10
transparent encryption can be implemented to occur in the host, along the data path from host to storage
11
device, and inside the storage device, all without the need to modify the data transmission protocols or the
12
layout of the data on the media. In the context of encryption by sector-level storage devices, this
13
requirement translates into the following two constraints:
14
1. The transform must be length-preserving, namely the length of the ciphertext must equal that of
15
the plaintext. This means that the transform must be deterministic, and that it cannot store an
16
authentication tag along with the ciphertext.
17
2. The transform must be applicable to individual data-units (or sectors) independently of other data-
18
units and in arbitrary order. This means that no chaining between different data-units is possible.
19
This requirement stems from the need to support random access to the encrypted data. For
20
example, encryption mode that chains multiple data units requires reading of several data units to
21
decrypt a single unit.
22 23
Two solutions that were rejected by the group as insecure were to use either counter (CTR) mode or cipher
24
block chaining (CBC) mode, deriving the IV from the sector number.
25
• Using CTR without authentication tags is trivially malleable, and an attacker with write access to
26
the encrypted media can flip any bit of the plaintext simply by flipping the corresponding ciphertext
27
bit.
28
• For CBC, an attacker with read/write access to the encrypted disk can copy a ciphertext sector from
29
one position to another, and an application reading the sector off the new location will still get the
30
same plaintext sector (except perhaps the first 128 bits). For example, this means that an attacker
31
that is allowed to read a sector from the second position but not the first can find the content of the
32
sector in first position by manipulating the ciphertext.
33 • For CBC, an attacker can flip any bit of the plaintext by flipping the corresponding ciphertext bit of 34
the previous block, with the side-effect of ��randomizing�� the previous block.
35 36
The XTS-AES transform was chosen because it offers better protection against ciphertext manipulations
37
and cut-and-paste attacks. It is important to realize, however, that regardless of the method used for
38
encryption, the constraints above imply some inherent limitations on the level of security that can be
39

Page 34
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
28 achieved by such transform. As shown below, these constraints imply that the best achievable security is
1
essentially what can be obtained by using ECB mode with a different key per block (and using a cipher
2
with wide blocks).
3 4
Specifically, since there are no authentication tags then any ciphertext (original or modified by attacker)
5
will be decrypted as some plaintext and there is no built-in mechanism to detect alterations. The best that
6
can be done is to ensure that any alternation of the ciphertext will completely randomize the plaintext, and
7
rely on the application that uses this transform to include sufficient redundancy in its plaintext to detect and
8
discard such random plaintexts.
9 10
Also, since this transform is deterministic, then encrypting the plaintext twice with the key and the same
11
position will necessarily yield the same ciphertext. Moreover, since there is no chaining then an attacker
12
can ��mix and match�� ciphertext units and get the same ��mix and match�� of their corresponding plaintext
13
units. (Namely, if C0C1��Cm is encryption of P0P1��Pm and C��0C��1��C��m is encryption of P��0P��1��P��m then
14
C0C��1��Cm is encryption of P0P��1��Pm.)
15 16
The above ��mix and match�� weakness can be mitigated to some extent by using some context information
17
in the encryption and decryption processes. In the case of sector-level encryption, the only context
18
information that can be assumed to be available at both encryption and decryption is the (logical) position
19
of the current data unit (as seen by the encryption/decryption module).4 Incorporating the position
20
information into the encryption and decryption routines makes it possible to cryptographically hide the fact
21
that the same unit is written in two different places, and also prevents ��mix and match�� between different
22
positions. But as mentioned above, even the best implementation of encryption by a sector-level storage
23
device leaves several vulnerabilities. Three of these vulnerabilities are illustrated next.
24
Traffic analysis. Consider an attacker that is able to passively observe the communication
25
between the encrypting device and the disk. Since encryption is deterministic, this attacker is able to
26
observe when a certain sector is written back to disk with a different value than was previously read
27
from disk. This capability may help the attacker in mounting an attack based on traffic analysis.
28
Replay. An attacker with read/write access to the encrypted disk can observe when a certain sector
29
changes on the disk and then reset it to any one of its previous values. (Notice that this attack is not
30
specific to transparent encryption, it may work even when using randomized encryption with
31
authentication tags.)
32
Randomizing a sector. Since there are no authentication tags, an attacker with write access to
33
the encrypted disk can write an arbitrary ciphertext to any sector, causing an application that reads this
34
sector to see a ��random�� plaintext instead of the value that was written to that sector. The behavior of
35
the application on such ��random�� plaintext may be beneficial to the attacker.
36 37
When using transparent encryption, one must therefore address these vulnerabilities by means outside the
38
scope of this standard.
39
D.3 Wide vs. Narrow Block Tweakable Encryption
40
In light of the discussion above, the interfaces of the transform that is required are encryption and
41
decryption routines:
42 43
C = Enc(K, P, i) and P = Dec(K, C, i),
44 45
4 On the other hand, parameters like ��time of encryption�� cannot be used as context information, since the
decryption procedure typically has no way of obtaining that information.

Page 35
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
29 where the plaintext P and ciphertext C have the same length (i.e., the length of a single sector), K is the
1
secret encryption key, and i represents the position information.
2 3
The best security that one can hope for with such transform is that it looks to an attacker like a block cipher
4
with block size equal to the sector size, and with different and independent keys for different values of i.
5
Such a construct is called a ��tweakable cipher�� in the cryptographic literature. It was first defined formally
6
by Liskov et al. in [LRW02].
7 8
Several constructions that achieve these properties exist in the cryptographic literature (e.g., [HR03],
9
[HR04], [H04], and a construction based on [NR98]). All these constructions, however, are rather
10
expensive, requiring buffering of at least one sector worth of intermediate results and at least two passes
11
over the entire sector.5 A cheaper alternative can be obtained by relaxing the requirement that the transform
12
looks like a cipher with a wide (e.g. sector-length) block-size. Instead, one can work with narrow blocks of
13
128 bits, but still insist that different blocks (whether in the same or in different sectors) look to an attacker
14
like they were encrypted with different independent keys.
15 16
Giving up the dependencies between different 128-bit blocks allows greater efficiency. The price for that,
17
however, is that the attacks described in C.1 are now possible with better granularity. Namely, whereas the
18
attacker against a wide-block encryption scheme can do traffic analysis or replay with granularity of one
19
sector, the attacker against a narrow-block encryption scheme can work with granularity of 128-bit blocks.
20
Still, the consensus in the group was the added efficiency warrants this additional risk. Since these risks
21
exist even with wide-block encryption – albeit with a coarser granularity – then one would anyway need
22
some other mechanisms for addressing them, and in many cases the same mechanisms can be used also for
23
addressing these risks in their fine-grained form.
24 25
D.4 The XEX Construction
26
D.4.1 General XEX transform
27 28
In [XEX04], Rogaway described a construction of a narrow-block tweakable cipher from a standard cipher
29
such as AES. That construction works as follows: The tweakable cipher uses two keys, K1 and K2, both
30
used as keys for the underlying cipher Enc(K, data)/Dec(K, data). Given a plaintext block P and the tweak
31
value, the tweak is parsed as a pair (s,t) (s can be thought of as the sector number and t as the block number
32
within the sector). The construction first computes a mask value T using the following expression:
33 34
T = Enc(K2, s) ⊗ ��t
35 36
where the multiplication is in GF(2n) (with n being the block-size of the underlying cipher) and �� is a
37
primitive element of GF(2n). Given plaintext P, ciphertext C is produced by the following formula:
38 39
C = Enc(K1, P ⊕ T) ⊕ T
40 41
Given ciphertext C, the plaintext P is produced by the following formula:
42 43
P = Dec(K1, C ⊕ T) ⊕ T.
44 45
5 At least some of this overhead appears to be inherent: Since these schemes insist on a block cipher with
��wide block�� (i.e., as wide as an entire sector), then every bit of ciphertext must ��strongly depend�� on every bit of plaintext and vice versa. This means in particular that no bit of output can be produced until all the input bits were processed by the block cipher.

Page 36
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
30 D.4.2 Security of general XEX transform
1 2
The security analysis of generic XEX transform in [XEX04] shows that this mode is secure as long as the
3
number of blocks that are encrypted under the same key is sufficiently smaller than the birthday bound
4
value of 2n/2, where n is the block size in bits of the underlying block cipher. Some attacks become possible
5
when the number of blocks approaches the 2n/2 value,.
6 7
The attacker analyzed in [XEX04] can make arbitrary encryption and decryption queries to the tweakable
8
cipher, using arbitrary tweak values. These queries are answered either by the construction above, or by a
9
truly random collection of permutations and their inverses over {0,1}n (a different, independent
10
permutation for every value of the tweak), and the attacker��s goal is to determine which is the case.
11
Rogaway proved in [XEX04, Theorem 8] that an attacker that makes at most q such queries cannot
12
distinguish these two cases with advantage more than 4.5 q2/2n + �� over a random guess (where �� is an error
13
term that expresses the advantage of distinguishing the underlying cipher from a random permutation using
14
q queries and n is the block size in bits of the underlying block cipher).
15 16
To explain the relevance of this analysis to the security of a real-world usage of the XTS-AES transform,
17
we first argue that no realistic attacker would have more information than the attacker in the attack model
18
that is described in the analysis. This follows from the fact that attacker in [XEX04] is assumed to be able
19
to choose all the plaintext and ciphertext that is fed to the construction. Since the theorem [XEX04,
20
Theorem 8] says that no attacker in that model can distinguish the construction from a collection of random
21
permutations, it follows that no realistic attacker can distinguish between these cases with any significant
22
advantage. This, in turn, means that whatever attack we are facing would be just as successful if we were
23
using a collection of truly random permutations, one per each 128-bit block, to encrypt our data rather than
24
using XEX.
25 26
It follows that when analyzing the security of an application that uses the above scheme, we can think of
27
the encryption as if it was done using a collection of truly random 128-bit permutations. When faced with
28
such a collection of truly random permutations, the only information that the attacker has is the following:
29 30
• The same plaintext with the same tweak value will always be encrypted to the same ciphertext (cf.
31
the traffic analysis attack from above).
32
• The same ciphertext with the same tweak value will always be decrypted to the same plaintext (cf.
33
the replay attack from above).
34
• Any other ciphertext (plaintext) will be decrypted (encrypted) to a random value (cf. the
35
randomizing attack from above).
36 37
In other words, the proof in [XEX04] implies that except for the "error term" of 4.5 q2/2n + ��, the only
38
attacks that are possible against XEX are the ones that are inherent from the use of transparent encryption
39
with the granularity of n-bit blocks, where n is the block size in bits of the underlying cipher.
40 41
Some attacks against XEX are possible when the number of blocks q approaches the birthday bound. For
42
example, consider a known-plaintext attack where the attacker sees q tuples of tweak, plaintext, and
43
ciphertext. For each such tuple ((si,ti), Pi, Ci), denote by Ti the mask value that is computed from the tweak
44
(si,ti).
45 46
From the birthday bound it follows that when q approaches 2n/2, there is a non-negligible probability that
47
for some i,j there is a collision of the following form:
48 49
Pi ⊕ Ti = Pj ⊕ Tj.
50 51
In this case it also holds that:
52 53
Ci ⊕ Ti = Enc(K1, Pi ⊕ Ti) = Enc(K1, Pj ⊕ Tj) = Cj ⊕ Tj. (Equation 1)
54

Page 37
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
31
1
Summing these two equalities implies
2 3
Pi ⊕ Ci = Pj ⊕ Cj
4 5
This can be used to distinguish XEX from a collection of truly random permutations. The attacker
6
computes for all i the sum Si=Pi ⊕ Ci and counts the number of pairs (i,j) for which Si=Sj. The argument
7
above implies that for any i,j, the probability that Si=Sj in ciphertext produced by XEX is roughly
8
2-n+2-n=2-n+1, where the first term is due to collision between i and j and the second term is due to equality
9
Si=Sj without a collision. On the other hand, for truly random permutation the probability of Si=Sj is exactly
10
2-n, and hence after observing roughly 2n/2 tuples ((si,ti), Pi, Ci) it is possible to distinguish ciphertext
11
produced by XEX from a random sequence with non-negligible probability.
12 13
Given a collision between i and j as above, the following approach shows how the attacker can use his
14
ability to create legally encrypted data for position i and ability to modify ciphertext in position j to modify
15
the ciphertext at j so it will decrypt to an arbitrary attacker-controlled value.
16 17
As above, the attacker begins by computing the sums Si=Ci ⊕ Pi and uses any equality Si=Sj as an evidence
18
of collision between i and j. Denote by ((si,ti), Pi, Ci), ((sj,tj), Pj, Cj) the corresponding tweak, plaintext, and
19
ciphertext values.
20 21
For some �� �� 0, the attacker encrypts a new value P'i=Pi ⊕ �� in position (si,ti), observes the corresponding
22
ciphertext C'i, and replaces the ciphertext block Cj by:
23 24
C'j = Cj ⊕ (Ci ⊕ C'i).
25 26
This new ciphertext block will be decrypted as P'j=Pj ⊕ ��. In other words, the attacker succeeded in
27
��flipping�� specific bits in plaintext corresponding to location j. To see this, observe that:
28 29
C'j ⊕ Tj = Cj ⊕ (Ci ⊕ C'i) ⊕ Tj (Equation 2)
30
= C'i ⊕ (Ci ⊕ Cj) ⊕ Tj
31
= C'i ⊕ (Ti ⊕ Tj) ⊕ Tj (follows from Equation 1)
32
= C'i ⊕ Ti
33 34
Therefore:
35 36
Dec(K1, C'j ⊕ Tj) = Dec(K1, C'i ⊕ Ti)
37 38
which implies that:
39 40
P'j = Tj ⊕ Dec(K1, C'j ⊕ Tj)
41
= Tj ⊕ Dec(K1, C'i ⊕ Ti) (follows from Equation 2)
42
= (Tj ⊕ Ti) ⊕ [Ti ⊕ Dec(K1, C'i ⊕ Ti)]
43
= (Tj ⊕ Ti) ⊕ P'i
44
= (Tj ⊕ Ti) ⊕ (Pi ⊕ ��)
45
= ((Tj ⊕ Ti) ⊕ Pi) ⊕ ��
46
= Pj ⊕ ��.
47 48 49
D.4.3 XTS-AES as a specific instantiation of general XEX
50
The XTS-AES-128 and XTS-AES-256 transforms described in this standard are concrete instantiations of
51
the XEX scheme with AES as the underlying block cipher, and thus using n=128 as the block length. A
52
data unit sequence number (i.e., relative position) is used as a tweak in order to allow for copy or backup of
53

Page 38
IEEE P1619/D16, May 2007 Copyright © 2007 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.
32 a key scope or partial key scope of data encrypted with XTS-AES-[128,256] without re-encryption. In
1
contrast to the generic XEX construction described in [XEX04] that uses a single key, the XTC-AES-128
2
and XTS-AES-256 modes in this standard use separate keys for tweaking and encryption purposes. This
3
separation is a specific example of separation of key usage by purpose and is considered a good security
4
design practice (see [KEY-MGMT, part 1, Section 5.2]).
5 6
The expression 4.5 q2/2n is small enough as long as q is not much more than 240. The proof from [XEX04]
7
yields strong security guarantee as long as the same key is not used to encrypt much more than a terabyte of
8
data (which gives q=236 blocks). For this case, no attack can succeed with probability better than 2-53 (i.e.,
9
approximately one in eight quadrillion).
10 11
This security guarantee deteriorates as more data is encrypted under the same key. For example, when
12
using the same key for a petabyte of data, attacks such as in D.4.2 have success probability of at most
13
approximately 2-37 (i.e., approximately eight in a trillion), and with exabyte, of data the success probability
14
is at most approximately 2-17 (i.e., approximately eight in a million).
15 16
The decision on the maximum amount of data to be encrypted with a single key should take into account
17
the above calculations together with the practical implication of the described attack, (e.g. ability of the
18
attacker to modify plaintext of a specific block, where the position of this block may not be under attacker��s
19
control).
20
D.5 Sector-size that is not a multiple of 128 bits
21
The generic XEX transform as described in [XEX04] immediately implies a method for encrypting sectors
22
that consist of an integral number of 128-bit blocks: apply the transform individually to each 128-bit block,
23
but use the block number in the sector as part of the tweak value when encrypting that block. This method
24
is applicable to the most common sector sizes (such as 512 bytes or 4096 bytes). However, it does not
25
directly apply to sector sizes that are not an integer multiple of 128-bit blocks (e.g., 520-byte sectors).
26 27
To encrypt a sector which length is not an integral number of 128-bit blocks, the standard uses the
28
��ciphertext-stealing�� technique similar to the one used for ECB mode (see [MM82, Fig. 2-22]). Namely,
29
both XTS-AES-128 and XTS-AES-256 encrypt all the full blocks except the last full block (with different
30
tweak values for each block), and then encrypt the last full block together with the remaining partial block
31
using two application of the XTS-AES-blockEnc procedure described in 5.3.1 with two different tweak
32
values, as described in 5.3.2.
33
D.6 Miscellaneous
34
Following are general remarks about appropriate use of the XTS-AES transform.
35
• When analyzing the security of an application that uses this standard, one must consider the methods
36
that were used to generate the keys. As with every cryptographic algorithm, it is important that the
37
secret-key used for XTS-AES-[128,256] be chosen at random (or from a ��cryptographically strong��
38
pseudo-random source). Indeed, all security guarantees (including the security claims of the theorem
39
from [XEX04]) are null and void if the key is chosen from a low entropy source. The issues of strong
40
pseudo-randomness and key-generation are outside the scope of this standard. For further information,
41
see [KEY-MGMT].
42
• Use of a single cryptographic key for more than a few hundred terabytes of data opens possibility of
43
attacks, as described in D.4.3. The limitation on the size of data encrypted with a single key is not
44
unique to this standard. It comes directly from the fact that AES has a block size of 128 bits and is not
45
mitigated by using AES with a 256-bit key.
46

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com
TOP