Draft Proposal for Tweakable Wide-Block Encryption

October April 2512, 20054 Draft proposal for tweakable wide-block encryption

Document Number: XXXX-00-0-Y-Apr12Apr05 XCB-32-AES: Draft Proposal for Tweakable Wide-block Encryption Draft 1.0101:00

April 12, 2005 April 12, 2005

Sponsor IEEE P1619

Abstract: We describe the XCB-32-AES tweakable block cipher and its use for encryption of storage. XCB-32-AES is a tweakable block cipher that acts on wide blocks of 512 bytes, and it uses as subroutine the AES block cipher (that acts on blocks of 16 bytes). Specifically, XCB-32- AES encrypts and decrypts wide blocks of 512 bytes, under the control of a secret AES key and a non-secret 16-byte tweak. XCB-32-AES is a concrete instantiation of the XCB (Extended Codebook) mode of operation, as described in reference [XCB]. When used to encrypt storage data, the tweak value is computed as the logical position of the current wide block within the scope of the current key. The motivating application for XCB-32-AES is encryption of storage at the sector level. In this application, sectors are typically of length 512 bytes, and one may use the address of the sector on the disk as the tweak value. XCB-AES can be easily extended to any wide block of size between 128 and 239 bits, but the scope of this document is limited to 512 bytes wide blocks.

Keywords: Encryption, storage.

IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard.

Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art.

Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason IEEE and the members of its technical committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration.

Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331

IEEE Standards documents are adopted by the Institute of Electrical and Electronics Engineers without regard to whether their adoption may involve patents on articles, materials, or processes. Such adoption does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the standards documents.

1. Status summary

Contacts

This proposal editor: Fabio Maino Cisco Systems, Inc. 375 East Tasman Drive San Jose, CA 95134 Tel: +1.408.853.7530 Email: [email protected]

Table of contents

1. Status summary ...... 3 Contacts ...... 3

2. Overview ...... 7 2.1 Scope and purpose ...... 7 2.2 Related work ...... 7

3. References ...... 8

4. Definitions ...... 9 4.1 Conformance levels ...... 9 4.2 Glossary of terms ...... 9 4.3 Acronyms and abbreviations ...... 10 4.4 Numerical values ...... 10 4.5 Field names ...... 10 4.6 Notations for block encryption and decryption ...... 10 4.7 C-code notation ...... 11

5. The XCB-32-AES transform ...... 12 5.1 Multiplication in the finite field GF(2 128 ) ...... 13 5.2 The universal hash function GHASH ...... 14 5.3 The XCB encryption procedure ...... 15 5.4 The XCB decryption procedure ...... 15

6. Using XCB-32-AES for encryption of storage ...... 17 6.1 Encoding the tweak values ...... 17

7. Acnowledgements ...... 18

Annex A: Bibliography (informative) ...... 19

Annex B: Test Vectors ...... 20

1. Status summary ...... 3 Contacts ...... 3

2. Overview ...... 7 2.1 Scope and purpose ...... 7 2.2 Related work ...... 7

3. References ...... 8

4. Definitions ...... 9 4.1 Conformance levels ...... 9 4.2 Glossary of terms ...... 9 4.3 Acronyms and abbreviations ...... 10 4.4 Numerical values ...... 10 4.5 Field names ...... 10 4.6 Notations for block encryption and decryption ...... 10 4.7 C-code notation ...... 11

5. The XCB-32-AES transform ...... 12 5.1 Multiplication in the finite field GF(2128) ...... 13 5.2 The universal hash function GHASH ...... 14 5.3 The XCB encryption procedure ...... 15 5.4 The XCB decryption procedure ...... 15

6. Using XCB-32-AES for encryption of storage ...... 21 6.1 Encoding the tweak values ...... 21

7. Acnowledgements ...... 22

Annex A: Bibliography (informative) ...... 23

List of figures

Figure 5-1, An illustration of XCB-32-AES encryption, C1..C32 = XCB-32-AESK(T; P1..P32) ...... 12 Figure 5-2, An illustration of XCB-32-AES decryption, P1..P32 = XCB-32-AESK(T; C1..C32) ...... 13 Figure 5-1, An illustration of XCB-32-AES encryption, C1..C32 = XCB-32-AESK(T; P1..P32) ...... 12 Figure 5-2, An illustration of XCB-32-AES decryption, P1..P32 = XCB-32-AESK(T; C1..C32) ...... 13 Figure 5-3. A “C” code for the XCB encryption procedure...... 17

List of tables

Table 4.1 — Names of registers and fields ...... 10 Table 4.2 —C code expressions ...... 11 Table 4.1 — Names of registers and fields ...... 10 Table 4.2 —C code expressions ...... 11

2. Overview

2.1 Scope and purpose

The purpose of this document is to specify the XCB-32-AES transform and its use for encryption of data at rest. The XCB-32-AES transform acts on wide blocks of 512 bytes, under the control of a secret key and a non-secret tweak. It is implemented as a mode of operation for the AES block cipher (that has blocks of size 16 bytes). The security goal of XCB-32-AES states that it should look like a block cipher (with “wide blocks” of size 512 bytes). Moreover, using the same key with different tweaks should look like using completely independent keys.

XCB-32-AES is a concrete instantiation of the XCB mode of operation, which is described in reference [XCB[XCB]. The XCB mode of operation uses a block cipher with n-byte blocks, and turns it into a tweakable cipher with blocks of any size between n and 239 bits, with associated data of arbitrary length. It is proven in [XCBXCB] that the XCB mode indeed achieves the stated security goal, assuming that the underlying block cipher is secure.

An example application for this transform is encryption of storage at the sector level, where the encrypting device is not aware of high-level concepts like files and directories. The disk is often partitioned into fixed- length sectors (typically 512 bytes), and the encrypting device is given one sector at a time, in arbitrary order, to encrypt or decrypt. The device needs to operate on sectors as they arrive, independently of the rest. Moreover, the ciphertext must have the same length as its plaintext. On the other hand, it is possible to vary the encryption/decryption process, based on the location on the disk where the ciphertext is stored. The dependency on the location allows that identical plaintext sectors stored at different places on the disk will have unrelated ciphertexts.

This document includes the description of the XCB-32-AES transform itself (in both encryption and decryption modes), as well as how it should be used for encryption of data at rest. The scope is limited to encryption of storage data, consisting of an integral number of 512-byte blocks. Throughout this document, a block of 512 consecutive bytes is referred to as a “wide block”.

2.2 Related work

The extended codebook (XCB) mode of operation for block ciphers, as defined in [XCB], is a pseudorandom arbitrary-length permutation with associated data. That is for each plaintext length and each value of the associated data, the ciphers acts as a pseudorandom permutation.

The extended codebook (XCB) mode of operation for block ciphers is amenable to implementation in both hardware and software, and it has a computational cost that is relatively low (compared to similar modes): it only requires n + 1 block cipher invocations and 2n multiplications in GF(2w), where w is the number of bits in the block cipher inputs and outputs.

The use of an associated data input to a pseudorandom permutation first appeared in the innovative Hasty Pudding Cipher of Schroppel [S98], where it was called a ‘spice’, and was given a rigorous mathematical treatment by Liskov, Rivest, and Wagner [LRW02], who called it a ‘tweak’. The security goal of XCB follows that of the latter work, with the distinction that XCB allows the associated data to have an arbitrary length.

There are several other block cipher modes of operation that also implement psedurandom arbitrary length permutations. Most notable is the EME mode of Halevi and Rogaway [HR04], which is also efficient and accepts associated data.

TODO (see [XCB])

3. References

[R1] ANSI/ISO 9899-1990, Programming Language—C.1,2

[R2] NIST FIPS-197, Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard.3

All the standards listed are normative references. Informative references are given in Annex A. At the time of publication, the editions indicated were valid.

1 Replaces ANSI X3.159-1989. 2 ISO documents are available from ISO Central Secretariat, 1 rue de Varembé, Case Postale 56, CH-1211, Genève 20, Switzer-land/Suisse; and from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036-8002, USA 3 FIPS publications are available from the National Technical Information Service (NTIS), 5285 Port Royal Road, Springfield, VA, USA. FIPS-197 is also available on-line from http://csrc.nist.gov/CryptoToolkit/aes/

4. Definitions

4.1 Conformance levels

expected: A key word used to describe the behavior of the hardware or software in the design models assumed by this specification. Other hardware and software design models may also be implemented.

may: A key word indicating flexibility of choice with no implied preference.

shall: A key word indicating a mandatory requirement. Designers are required to implement all such mandatory requirements.

should: A key word indicating flexibility of choice with a strongly preferred alternative. Equivalent to the phrase is recommended.

reserved fields: A set of bits within a data structure that is defined in this specification as reserved, and is not otherwise used. Implementations of this specification shall zero these fields. Future revisions of this specification, however, may define their usage.

reserved values: A set of values for a field that are defined in this specification as reserved, and are not otherwise used. Implementations of this specification shall not generate these values for the field. Future revisions of this specification, however, may define their usage.

NOTE —These conformance definitions are used throughout IEEE standards and should therefore never be changed.

4.2 Glossary of terms

byte: Eight bits of data, used as a synonym for octet.

doublet: Two bytes of data.

quadlet: Four bytes of data.

octlet: Eight bytes of data.

3.2.5 block: Sixteen bytes of data.

3.2.6 wide block: Five hundred and twelve bytes of data.

4.3 Acronyms and abbreviations

IEEE The Institute of Electrical and Electronics Engineers, Inc.

4.4 Numerical values

Decimal, hexadecimal, and binary numbers are used within this document. For clarity, decimal numbers are generally used to represent counts, hexadecimal numbers are used to represent addresses, and binary numbers are used to describe bit patterns within binary fields.

Decimal numbers are represented in their usual 0, 1, 2, ... format. Hexadecimal numbers are represented by a string of one or more hexadecimal (0-9,A-F) digits followed by the subscript 16, except in C-code contexts, where they are written as 0x123EF2 etc. Binary numbers are represented by a string of one or more binary (0,1) digits, followed by the subscript 2. Thus the decimal number “26” may also be represented as “1A16” or “110102”.

4.5 Field names

This document describes values that are in memory-resident or control-and-status registers (CSRs). For clarity, names of these values have an italics font and contain the context as well as field names, as illustrated in 1.1.

Table 1.1— Names of registers and fields

Name Description

MoverCsr.control The mover’s control register.

Command.code. The code field within a command entry

Status.count The count field within a status entry

Note that run-together names like “MoverCsr” are preferred because they are more compact than under- score-separated names (like “Mover_Csr”). The use of multiword names with spaces (like “Mover CSR” is avoided, to avoid confusion between commonly used capitalized key words and the capitalized word used at the start of each sentence. Capitalization may, however, be useful for differentiating between different types of key words. For example: the upper case MoverCsr, Command, and Status names refer to CSR registers and the lower case control, code, and count names refer to fields within these registers.

4.6 Notations for block encryption and decryption

Subject to the procedures described in publication 2 (AES), we denote by C = AES-enc(K; P) the operation of applying the encryption procedure from 2, when K is an array of bytes that is used as the encryption key, and P is a block of 16 bytes. The result of this operation is a block of 16 bytes, which is denoted C. Similarly, we denote by P = AES-dec(K; C) the operation of applying the decryption procedure from 2, when K is an array of bytes that is used as the decryption key, and C is a block of 16 bytes. The result of this operation is a block of 16 bytes, which is denoted P.

4.7 C-code notation

The behavior of many commands is frequently specified by C code, such as in Equation 1.1. To differentiate this code from textual descriptions, such C code listings are formatted using a fixed-width Courier font. Similar C-code segments are included within some figures.

// Return maximum of a and b values Max(a,b) { if (ab) 1.1 return(GT); return(EQ); }

Since the meaning of many C code operators are not obvious to the casual reader, their meanings are summarized in 1.2.

Table 1.2—C code expressions

Expression Description

~i Bitwise complement of integer i

i^j Bitwise EXOR of integers i and j

i&j Bitwise AND of integers i and j

i*j Arithmetic bmultiplication of integers i and j

!i Logical negation of Boolean value i

i&&j Logical AND of Boolean i and j values

i||j Logical OR of Boolean i and j values

i^= j Equivalent to i= i^j.

i==j Equality test, true if i equals j

i!=j Equality test, true if i does not equal j

i>j Inequality test, true if i is greater than j

5. The XCB-32-AES transform

In this section we describe the XCB-32-AES transform itself. That is, the procedures to be followed when encrypting or decrypting a wide block, given the secret key K and the public tweak value T. A pictorial illustration of the encryption procedure is provided in Figure 5-1. Decryption is illustrated in Figure 5-2. In these figures, black lines represent 16-byte blocks, and the blocks represent the AES encryption or decryption procedure, with the key Ki. The symbol `’ denotes bit-wise exclusive-or (xor) of two or more 16-byte blocks, the symbol ‘’ denotes multiplication in the finite field GF(2128) as described in section 5.1. A complete description of the XCB-32-AES encryption and decryption can be found in section 5.3 and 5.4. The constant ‘LLEN’ is the concatenation of two 64-bit strings containing the nonnegative integers 100h and F80h and 80h, with the least significant bit on the right (length = 05 52 || 15 || 0 87 || 0 52 48 || 1 5 || 07). The keys Ki i=0,…,4H, I, J, L are derived from the key K according to the key schedules indicated in section 5.3. The function incr(X) applied to the 16-byte value X increments the least significant 32 bits of X.

H H H … H H

0 I GHASH

C Encryption P P P … P LEN AESK 1 2 3 32 D D incr(.) … incr(.)

Encryption Encryption … Encryption T AESK AESK AESK AES-CTR

F Decryption C C C … C AESK 1 2 3 32 L J 0

H H H H … H H GHASH

Figure 5-1, An illustration of XCB-32-AES encryption, C1..C32 = XCB-32-AESK(T; P1..P32)

The XCB-32-AES encryption and decryption algorithms use the AES block cipher function (encryption and decryption), as well as the same universal hash function GHASH that is used as a component of the Galois/Counter Mode (GCM) of operation [GCMGCM]. The figures show also that the block cipher AES in counter mode is used as a pseudorandom function.

H H H H … H H

0 J L GHASH F Encryption C C C … C AESK 1 2 3 32 LEN D D incr(.) … incr(.)

Encryption Encryption … Encryption T AESK AESK AESK AES-CTR

Decryption P P2 P3 … P32 C AESK 1 I 0

H H H … H H GHASH

Figure 5-2, An illustration of XCB-32-AES decryption, P1..P32 = XCB-32-AESK(T; C1..C32)

5.1 Multiplication in the finite field GF(2 1 2 8 )

We now describe a procedure for multiplying a 16-byte block by a another 16 byte block b in the finite field GF(2128). Both the inputs and the output of this procedure are 16-byte blocks. When these blocks are interpreted as binary polynomials of degree 127, the procedure computes z = a b modulo P128, where P128 is 128 7 2 128 the polynomial P128(x) = x + x + x + x + 1. Multiplication of two elements in the finite field GF(2 ) is computed by computing the polynomial multiplication and taking the remainder of the Euclidean division 128 7 2 by the chosen irreducible. In our case, the irreducible is P128(x) = x +x +x +x+1. Example: (over GF(27) with irreducible x7+x+1 for simplicity) {0,1,0,0,1,1,1}  {1,0,0,1,1,1,0} = (x5+x2+x+1)*(x6+x3+x2+x) mod (x7+x+1) = (x11+x5+x3+x) mod (x7+x+1) = x4+x3+x = {0,0,1,1,0,1,0} Efficient multiplication in GF(2128) may be implemented in numerous ways, depending on whether the multiplier is hardware or software based and which special optimizations may apply. Algorithm 1 represents a simple, non-optimized method:

Algorithm 1. Multiplication in GF(2128). Computes the value of Z = C · Y , where C, Y and Z ε GF(2128).

Z ← 0, V ← C for i = 0 to 127 do if Yi = 1 then Z ← Z  V end if

if V127 = 0 then V ← rightshift(V ) else

V ← rightshift(V )  P128 end if end for return Z

A simple optimization of this algorithm improves performance when multiple inputs Y are multiplied by the same constant C. Note that in the ith step of Algorithm 1 V = C · xi , where xi represents the 16 byte 128 th member of GF(2 ) with only the i bit set. A 2,048 byte table of Vi (i = 0 to 127) may be stored on the first use of Algorithm 1 and reused thereafter:

Algorithm 2. Multiplication in GF(2128). Computes the value of Z = C · Y , where C, Y and Z ε GF(2128).

Z ← 0, table of Vi (i = 0 to 127) has been precomputed for i = 0 to 127 do if Yi = 1 then

Z ← Z  Vi end if end for return Z

5.2 The universal hash function GHASH

We now describe the function GHASH, the universal hash that is used as a component of the Galois/Counter Mode (GCM) of Operation [GCMGCM], that is a component of the XCB encryption/decryption procedure.

Given a 16-byte key K, a block A of 49632 -bytes and a block C of 16496 b-bytes, the function GHASH is defined as GHASH(K, A, C) = X343, where the 16-byte variables Xi for i=0, …, 343 are defined as:

0 i  0  (X i1  Ai )  K i  1,,2 X i   (X i1  Ci )  K i  3,...,33  (X i1  (len(A) || len(C)))  K i  34

The multiplication of two elements X, Y in GF(2128) is denoted as XY and the addition of X and Y is denoted as XY. The function len(S) returns a 64-bit string containing the nonnegative integer describing the number of bits in its argument S, with the least significant bit on the right.

5.3 The XCB encryption procedure

The XCB encryption procedure takes as input an AES key K, a 512-byte wide block P (for Plaintext) and a 16-byte block T (for Tweak). It produces as output a 512-byte wide block C (for Ciphertext). The procedure works as follows:

1. The 16-byte keys K0, … , K4H, I, J, L are derived from the 128-bit key K according to the key schedule4 below: H = AES_enc(K;0 128 ) I = AES_enc(K;0 128| ||1) J = AES_enc(K;0 128 ||10) L = AES_enc(K;0 128 ||11)

2. The 16-byte constant LEN is initialized to LEN = 05 52 || 15 || 0 87 || 048 0 52 || 1 5 || 07

3. The input wide block P is broken into 32 blocks P1 P2 … P32, where P1 consists of the first 16 bytes in P, P2 consists of the next 16 bytes, etc. In general, for j=1, 2, … 32, the block Pj consists of bytes number 16j15 through 16j (indexing starts at one).

4. A 16-byte block C is computed as C = AES-enc(K0; P1  I)

5. 128 A 16-byte block D is computed as D = C  GHASHK1GHASHH( 0 || T , P2 || … || P32, T), where the function GHASHKGHASHH(A,C) is the universal hash described section 5.2

6. for j=2, … , 32 a 16-byte block PPj Cj is computed as PPj Cj = Pj  DDj, where DD2 = AES-enc(K2; D) and DDj = AES-enc(K2; incr(DDj-1)) for j=3,…,32

7. A 16-byte block F is computed as F = D  GHASHK3GHASHH(T || L, PP2 C2 || … || PPC32, T), where the function GHASHKGHASHH(A,C) is the universal hash described belowabove. The intermediate 16-byte blocks C2 to C32 are also a result of this computation with Cj=Xj-1 for j=2,…,32, as defined in section 5.2

8. A 16-byte block C1 is computed as C1 = AES-dec(K4; F)  J

9. Finally, the 32 blocks C1 through C32 are concatenated to form the output wide block C. That is, the first 16 bytes in C come from C1, the next 16 bytes from C2, etc. In general, for j=1, 2, … 32, bytes

number 16j15 through 16j in C come from block Cj (indexing starts at one).

A C-code for this procedure is given in Figure 5-3.

5.4 The XCB decryption procedure

The XCB decryption procedure takes as input an AES key K, a 512-byte wide block C (for Ciphertext) and a 16-byte block T (for Tweak). It produces as output a 512-byte wide block P (for Plaintext). The procedure is very similar to the encryption procedure. The decryption procedure works as follows:

1. The 16-byte keys K0, … , K4H, I, J, L are derived from the 128-bit key K according to the key schedule below:

4 The use of distinct keys in each round is a burden, because those values must either be stored in memory and fetched when needed, or computed from the master key when needed. We believe that it is possible to re-use key material between rounds, but have not yet thoroughly analyzed the security of those cases. We chose the conservative security option for the initial version of XCB, but we hope to offer a reduced number of round keys in a future version.

128 K0  AES _ enc(K;0 ) 127 K1  AES _ enc(K;0 ||1) 126 128 K2  AES _ enc(K;0 ||10) H = AES_enc(K;0 ) K3  AES _ enc(K;0126 ||11) 125 K4  AES _ enc(K;0 ||100) I = AES_enc(K;0 128| ||1) J = AES_enc(K;0 128 ||10) L = AES_enc(K;0 128 ||11)

2. The 16-byte constant LLEN is initialized to LLEN = 0 55 || 1 || 0 8 || 0 52 || 1 5 || 0 7052 || 15 || 07 || 048 || 1 || 07

3. The input wide block C is broken into 32 blocks C1 C2 … C32, where C1 consists of the first 16 bytes in C, C2 consists of the next 16 bytes, etc. In general, for j=1, 2, … 32, the block Cj consists of bytes number 16j15 through 16j (indexing starts at one).

4. A 16-byte block F is computed as F = AES-enc(K4; C1 ) J)

5. A 16-byte block D is computed as D = F  GHASHK3GHASHH( T || L, C2 || … || C32, T), where the function GHASHKGHASHH(A,C) is the universal hash described section 5.2

6. for j=2, … , 32 a 16-byte block CCj Pj is computed as CCj Pj = Pj Cj  CCjDDj, where CC2 DD2 = AES- enc(K2; D) and DDj = AES-enc(K2; incr(DDj-1)) for j=3,…,32

7. 128 A 16-byte block C is computed as C = D  GHASHK1GHASHH( 0 ||T, CC2 || … || CC32, T), where the function GHASHKGHASHH(A,C) is the universal hash described belowabove. The intermediate 16- byte blocks P2 to P32 are also a result of this computation with Pj=Xj-1 for j=2,…,32, as defined in section 5.2

8. A 16-byte block P1 is computed as P1 = AES-dec(K0; C)  I

Finally, the 32 blocks P1 through P32 are concatenated to form the output wide block P. That is, the first 16 bytes in P come from P1, the next 16 bytes from P2, etc. In general, for j=1, 2, … 32, bytes number 16j15 through 16j in P come from block Pj (indexing starts at one).

Figure 5-3. A “C” code for the XCB encryption procedure. #include "aes.h" inline voidFigure 5-4. A “C” code for the XCB encryption procedure. typedef uint32_t gf2_128_t[4]; gf2_128_mult(gf2_128_t z, const gf2_128_t x, const gf2_128_t y) { int i; typedef enum { err_status_ok = 0, err_status_fail } err_status_t; gf2_128_t temp_x, temp_y; gf2_128_t temp_z = { 0, 0, 0, 0 }; typedef struct xcb_ctx_t { aes_expanded_key_t k0_enc; gf2_128_copy(temp_x, x); aes_expanded_key_t k0_dec; gf2_128_swap(temp_x); gf2_128_t k1; gf2_128_copy(temp_y, y); aes_expanded_key_t k2; gf2_128_swap(temp_y); gf2_128_t k3; for (i=127; i >= 0; i--) { aes_expanded_key_t k4_enc; if (gf2_128_get_bit(temp_y, i)) aes_expanded_key_t k4_dec; gf2_128_add(temp_z, temp_z, temp_x); unsigned bytes_processed; gf2_128_shift(temp_x); } xcb_ctx_t; } gf2_128_swap(temp_z); gf2_128_copy(z, temp_z); static inline uint32_t swap(uint32_t v) { } #if (BYTE_ORDER == LITTLE_ENDIAN) asm("bswap %0" : "=r" (v) : "0" (v)); void ghash_aligned(const gf2_128_t H, const uint32_t *U, int U_len, #endif const uint32_t *V, int V_len, u128_t output) { return v; int i; } u128_t X = { 0, 0, 0, 0 }; /* note: X is in host byte order */ #define gf2_128_swap(x) \ for (i=0; i < V_len/16; i++) { (x[0]=swap(x[0]),x[1]=swap(x[1]),x[2]=swap(x[2]),x[3]=swap(x[3])) gf2_128_add(X, X, V); V += 4; #define gf2_128_add(z, x, y) \ gf2_128_mult(X, H, X); (z[0]=x[0]^y[0], z[1]=x[1]^y[1],z[2]=x[2]^y[2],z[3]=x[3]^y[3]) } for (i=0; i < U_len/16; i++) { #define gf2_128_copy(dst, src) \ gf2_128_add(X, X, U); (dst[0]=src[0],dst[1]=src[1],dst[2]=src[2],dst[3]=src[3]) U += 4; gf2_128_mult(X, H, X); unsigned gf2_128_get_bit(const gf2_128_t x, unsigned bit) { } return (x[3-(bit >> 5)] >> (bit & 31)) & 1; X[1] ^= swap(V_len << 3); } X[3] ^= swap(U_len << 3); gf2_128_mult(X, H, X); u128_t gf2_128_field_polynomial = { u128_xor(output, output, X); 0xe1000000, 0x00000000, 0x00000000, 0x00000000 } }; inline void incr(u128_t ctr) { ctr[3] = swap(swap(ctr[3])+1); } inline void u128_right_shift(u128_t x) { x[3] = (x[3] >> 1) | ((x[2] & 0x00000001) << 31); inline void ctr_enc_aligned(aes_expanded_key_t key, u128_t ctr, x[2] = (x[2] >> 1) | ((x[1] & 0x00000001) << 31); uint32_t *plaintext, unsigned plaintext_bytes) { x[1] = (x[1] >> 1) | ((x[0] & 0x00000001) << 31); u128_t tmp, c; x[0] = (x[0] >> 1); uint32_t *terminus = plaintext + (plaintext_bytes/4); } gf2_128_copy(c, ctr); inline void while (plaintext < terminus) { gf2_128_shift(gf2_128_t input) { gf2_128_copy(tmp, c); if (gf2_128_get_bit(input, 0)) { aes_encrypt(tmp, key); u128_right_shift(input); gf2_128_add(plaintext, plaintext, tmp); gf2_128_add(input, input, gf2_128_field_polynomial); incr(c); } else { plaintext += 4; u128_right_shift(input); } } } }

err_status_tFigure 5-5. A “C” code for the XCB encryption procedure. xcb_init(xcb_ctx_t *key, void *key_material) { unsigned char *k = key_material; aes_expanded_key_t master_key; u128_t tmp;

aes_expand_encryption_key(k, master_key);

/* set k0 */ tmp[0] = tmp[1] = tmp[2] = tmp[4] = 0x00000000; aes_encrypt(tmp, master_key); aes_expand_encryption_key(tmp, key->k0_enc); aes_expand_decryption_key(tmp, key->k0_dec);

/* set k1 */ tmp[0] = tmp[1] = tmp[2] = 0x00000000; tmp[4] = 0x00000001; aes_encrypt(tmp, master_key); gf2_128_copy(key->k1, tmp);

/* set k2 */ tmp[0] = tmp[1] = tmp[2] = 0x00000000; tmp[4] = 0x00000002; aes_encrypt(tmp, master_key); aes_expand_encryption_key(tmp, key->k2);

/* set k3 */ tmp[0] = tmp[1] = tmp[2] = 0x00000000; tmp[4] = 0x00000003; aes_encrypt(tmp, master_key); gf2_128_copy(key->k3, tmp);

/* set k4 */ tmp[0] = tmp[1] = tmp[2] = 0x00000000; tmp[4] = 0x00000004; aes_encrypt(tmp, master_key); aes_expand_encryption_key(tmp, key->k4_enc); aes_expand_decryption_key(tmp, key->k4_dec);

return err_status_ok; }

err_status_t xcb_encrypt(xcb_ctx_t *key, uint32_t *pt, unsigned pt_bytes, uint32_t *ad, unsigned ad_bytes) { uint32_t *L = pt; /* L is the leftmost 16 bytes */ uint32_t *R = pt + 4; /* R is the remaining bytes */ unsigned R_len = pt_bytes - 16;

if (pt_bytes < 16 || (pt_bytes % 16) || (ad_bytes % 16) ) return err_status_fail; aes_encrypt(L, key->k0_enc); ghash_aligned(key->k1, R, R_len, ad, ad_bytes, L); ctr_enc_aligned(key->k2, L, R, R_len); ghash_aligned(key->k3, R, R_len, ad, ad_bytes, L); aes_decrypt(L, key->k4_dec); return err_status_ok; }

err_status_t xcb_decrypt(xcb_ctx_t *key, uint32_t *ct, unsigned ct_bytes, uint32_t *ad, unsigned ad_bytes) { uint32_t *L = ct; /* L is the leftmost 16 bytes */ uint32_t *R = ct + 4; /* R is the remaining bytes */ unsigned R_len = ct_bytes - 16;

if (ct_bytes < 16 || (ct_bytes % 16) || (ad_bytes % 16) ) return err_status_fail; aes_encrypt(L, key->k4_enc); ghash_aligned(key->k3, R, R_len, ad, ad_bytes, L); ctr_enc_aligned(key->k2, L, R, R_len); ghash_aligned(key->k1, R, R_len, ad, ad_bytes, L); aes_decrypt(L, key->k0_dec); return err_status_ok; }

Figure 5-6. A “C” code for the XCB encryption procedure.

6. Using XCB-32-AES for encryption of storage

The scope of this document is limited to direct application of the XCB-32-AES transform to encrypt or decrypt data at rest, when this data consists of an integral number of wide blocks, each of size 512 bytes. To use this standard, an AES key shall be associated with an ordered sequence of wide blocks, numbered consecutively 1 through N, where 1 is the index of the first logical wide block for this key, and N is the index of the last one. The sequence of wide blocks that are associated with an AES key is related to the SCOPE of that key, as defined in [BACKUPBACKUP]. In order to encrypt or decrypt a wide block using an AES key, the index of the wide block within the scope of the key must be known.

Key Scope is defined in [BACKUPBACKUP] as being represented by two integers which represent the “LBA” or Logical Byte Address of the start of the storage to be encrypted in bytes, and the number of bytes to be encrypted. To be valid for use with XCB-32-AES, the number of bytes to be encrypted in the key scope shall be a multiple of 512. Also, since the index N of the last block in the range must be less than 2128, the number of bytes in the scope shall be less than or equal to 512(2128-1). Each wide block (of 512 bytes) within the key scope is then associated with a logical index J, which may be viewed as the number of wide blocks from the beginning of the key scope, with the first wide block being numbered 1.

In a typical application for storage encryption, the scope of a key typically includes a range of logically consecutive sectors on the disk. Start location of the key scope would be the location of the beginning of the first sector in the range. The alignment of key scopes with integral numbers of consecutive storage sectors is recommended, but not mandated.

To encrypt a plaintext wide block with index J, the positive integer J is first encoded as a 16-byte block T J, as explained in Section 6.1 below. Then the XCB-32-AES encryption transform is applied to this wide block, using the given key and the tweak value TJ, as described in Section 5.3. The result of the transformation is a ciphertext wide block. Similarly, to decrypt a ciphertext wide block with index J, the positive integer J is encoded as a 16-byte block TJ, then the XCB-32-AES decryption transform is applied to this wide block using the given key and the tweak value TJ, as described in Section 5.4, and the result is a plaintext wide block.

It is stressed that a single AES secret key shall not be associated with more than one scope. The reason is that encrypting more than one wide block with the same AES key and the same index introduces security vulnerabilities that can potentially be used in an attack on the system.

6.1 Encoding the tweak values

A positive integer J (smaller than 2128) is encoded as a 16-byte block T using big-endian notation. That is, the integer J is represented in base-256 notation, where the most significant byte is stored as the first byte in the block T and the least significant byte is stored as the last byte. Using “C” notations, we view T as an array of sixteen unsigned char, indexed from 0 (first) to 15 (last), with each byte representing a number between 0 and 255, then the integer J is

J = T[0]25615 + T[1]25614 + T[2]25613 + T[3]25612 + T[4]25611 + T[5]25610 + T[6]2569 + T[7]2568 + T[8]2567 + T[9]2566 + T[10]2565 + T[11]2564 + T[12]2563 + T[13]2562 + T[14]256 + T[15]

7. Acnowledgements

Portions of this text, as well as its general structure, were unabashedly lifted from draft proposals for tweakable wide-block encryption written by Shai Halevi and Clement Kent.

Annexes

Annex A: Bibliography (informative) [BACKUP] Dalit Naor. Key Backup Format for Wide-block Encryption. April 14 2004

[GCM] D. McGrew and J. Viega, `”The Galois/Counter Mode of Operation (GCM),” Submission to NIST Modes of Operation Process, January, 2004. [LR88] M. Luby and C. Rackoff. “How to construct pseudorandom permutations from pseudorandom functions.” SIAM J. of Computation, 17(2), April 1988.

[LRW02] M. Liskov, R. Rivest and D. Wagner. “Tweakable Block Ciphers”, CRYPTO ’02, LNCS, Springer-Verlag, 2002. [BACKUP] Dalit Naor. Key Backup Format for Wide-block Encryption. April 14 2004

[HR04] S. Halevi and P. Rogaway, A Parallelizable Enciphering Mode, 2004 RSA Conference Cryptography Track, LNCS, Springer-Verlag, 2004. [NR98] M. Naor and O. Reingold. “A pseudo-random encryption mode.” Manuscript, available from http://www.wisdom.weizmann.ac.il/~naor/.

[NR99] M. Naor and O. Reingold. On the construction of pseudo-random permutations: Luby-Rackoff revisited. Journal of Cryptology, 12(1):29--66, 1999. Springer-Verlag.

[S98] R. Schroeppel. “The Hasty Pudding cipher.” The first AES conference, NIST, 1998.

[GCMGCM] D. McGrew and J. Viega, `”The Galois/Counter Mode of Operation (GCM),” Submission to NIST Modes of Operation Process, January, 2004.

[GCMXCB] D. McGrew and S. Fluhrer, `”Extended Codebook (XCB) Mode of Operation,” Pre- Publication Manuscript available at IACR eprint archive, October, 2004January, 2005.

Annex B: Test Vectors

AES Key 000102030405060708090a0b0c0d0e0f

Tweak 00000000000000000000000000000001

Plaintext P 00000000000000000000000000000000 00000000000000000000000000000000

H c6a13b37878f5b826f4f8162a1c8d879

I 7346139595c0b41e497bbde365f42d0a

J 49d68753999ba68ce3897a686081b09d

L b9ad2b2e346ac238505d365e9cb7fc56

Ciphertext C d0c3a39133dbc338a5bd4f1ecda0b6df 91abdd5c4da3541ad8248b2e68c04cfa