OCB: A Block-Cipher Mode of Operation for Efficient Authenticated Encryption
Phillip Rogaway∗ Mihir Bellare† John Black‡ Ted Krovetz§ September 19, 2001
Abstract
We describe a parallelizable block-cipher mode of operation that simultaneously provides privacy and authenticity. OCB encrypts-and-authenticates a nonempty stringM ∈ {0,1}∗using
|M|/n+ 2block-cipher invocations, wherenis the block length of the underlying block cipher.
Additional overhead is small. OCB refines a scheme, IAPM, suggested by Charanjit Jutla.
Desirable properties of OCB include: the ability to encrypt a bit string of arbitrary length into a ciphertext of minimal length; cheap offset calculations; cheap key setup; a single underlying cryptographic key; no extended-precision addition; a nearly optimal number of block-cipher calls; and no requirement for a random IV. We prove OCB secure, quantifying the adversary’s ability to violate the mode’s privacy or authenticity in terms of the quality of its block cipher as a pseudorandom permutation (PRP) or as a strong PRP, respectively.
Keywords: AES, authenticity, block-cipher usage, cryptography, encryption, integrity, modes of operation, provable security, standards .
∗ Department of Computer Science, Eng. II Building, University of California at Davis, Davis, California 95616 USA; and Department of Computer Science, Faculty of Science, Chiang Mai University, Chiang Mai 50200 Thailand.
e-mail: rogaway@cs.ucdavis.eduweb: www.cs.ucdavis.edu/~rogaway
†Department of Computer Science & Engineering, University of California at San Diego, 9500 Gilman Drive, La Jolla, California 92093 USA. e-mail: mihir@cs.ucsd.eduweb: www-cse.ucsd.edu/users/mihir
‡ Department of Computer Science, University of Nevada, Reno, Nevada 89557 USA. e-mail: jrb@cs.unr.edu web: www.cs.unr.edu/~jrb
§Digital Fountain, 600 Alabama Street, San Francisco, CA 94110 USA. e-mail: tdk@acm.org
1 Introduction
Background. An authenticated-encryption scheme is a shared-key encryption scheme whose goal is to provideboth privacyand authenticity. The encryption algorithm takes a key, a plaintext, and a nonce (often called an IV), and it returns a ciphertext. The decryption algorithm takes a key, a ciphertext, and a nonce, and it returns either a plaintext or a special symbol,Invalid. In addition to the customary privacy goal, an authenticated-encryption scheme aims for authenticity: if an adversary should try to create some new ciphertext, the decryption algorithm will almost certainly regard it asInvalid.
An authenticated-encryption scheme can be constructed by appropriately combining an encryp- tion scheme and a message authentication code (MAC), an approach used pervasively in practice and in standards. (Analyses of these methods are provided in [7, 24].) But an extremely attractive goal is an authenticated-encryption scheme having computational cost significantly lower than the cost to encrypt plus the cost to MAC. The classical approach for trying to do this is to encrypt-with- redundancy, where one appends a noncryptographic checksum to the message before encrypting it, typically with CBC mode. Many such schemes have been broken. Recently, however, Charanjit Jutla has proposed two authenticated-encryption schemes supported by a claim of provable secu- rity [21]. Virgil Gligor and Pompiliu Donescu have described a different authenticated-encryption scheme [15]. We continue in this line of work.
OCB mode. This paper describes a new mode of operation, OCB, which refines one of Jutla’s schemes, IAPM [21]. OCB (which stands for “offset codebook”) retains the principal characteristics of IAPM: it is fully parallelizable and adds minor overhead compared to conventional, privacy-only modes. But OCB combines the following features:
Arbitrary-length messages + minimal-length ciphertexts: Any string M ∈ {0,1}∗ can be encrypted; in particular, |M| need not be a multiple of the block length n. What is more, the resulting ciphertexts are as short as possible; plaintexts arenot padded to a multiple ofn bits.
Nearly optimal number of block-cipher calls: OCB uses |M|/n+ 2block-cipher invocations (excluding a block-cipher call assumed to be made during key setup). (It is possible to make do with|M|/n+1 calls, but such alternatives seem to be more complex or require a random IV.) Keeping low the number of block-cipher calls is especially important when messages are short.
In many domains, short messages dominate.
Minimal requirements on nonces: Like other encryption modes, OCB requires a nonce. The entity that encrypts chooses a new nonce for every message with the only restriction that no nonce is used twice. Schemes that require non-repeating nonces are less likely to be misused, and often more efficient, than those requiring random IVs.
Efficient offset calculations: As with [15, 21], we require a sequence of offsets. We generate these in a particularly cheap way, each offset requiring just a few machine cycles. We avoid the use of extended-precision addition, which would introduce endian dependency and might make the scheme less attractive for dedicated hardware.
Single underlying key: The key used for OCB is a single block-cipher key, and all block-cipher invocations are keyed by this one key, saving space and key-setup time.
Achieving the properties above has required putting together a variety of “tricks” that work together in just the right way. Many earlier versions of the algorithm were rejected by the authors because attacks were found or a proof could not be pushed through. We have found schemes of this sort to be amazingly “fragile”—tweak them a little and they break. We have concluded that, if the goals
above are ever to be sought, they must be carefully addressed from the start.
Performance. On a Pentium III processor, experiments by Lipmaa [25] show that OCB is about 6.5% slower than the privacy-only mode CBC. The cost of OCB is about 54% of the cost of CBC encryption combined with the CBC MAC. These figures assume a block cipher of AES128 [34].
In settings where there is adequate opportunity for parallelism, OCB will be faster than CBC.
Parallelizability is important for obtaining the highest speeds from special-purpose hardware, and it may become useful on commodity processors. For special-purpose hardware, one may want to encrypt-and-authenticate at speeds near 10 Gbits/second—an impossible task, with today’s technology, for modes like CBC encryption and the CBC MAC. (One could always create a mode that interleaves message blocks fed into separate CBC encryption or CBC MAC calculations, but that would be a new mode, and one with many drawbacks.) For commodity processors, there is an architectural trend towards highly pipelined machines with multiple instruction pipes and lots of registers. Optimally exploiting such features necessitates algorithms with plenty to do in parallel.
Security properties. We prove OCB secure, in the sense of reduction-based cryptography.
Specifically, we prove indistinguishability under chosen-plaintext attack [3, 16] and authenticity of ciphertexts [7, 8, 22]. As shown in [7, 22], this combination implies indistinguishability un- der the strongest form of chosen-ciphertext attack (CCA) which, in turn, is equivalent to non- malleability [10] under CCA [4, 23]. (Non-malleability refers to an adversary’s inability to modify a ciphertext in a way that makes related the two underlying plaintexts.) Our proof of privacy assumes that the underlying block cipher is good in the sense of a pseudorandom permutation (PRP) [6, 26], while our proof of authenticity assumes that the block cipher is a strong PRP [26].
Our results are quantitative; the security analysis is in the concrete-security paradigm.
We emphasize that OCB has stronger security properties than standard modes. In particular, non-malleability and indistinguishability under CCA are not achieved by CBC, or by any other standard mode, but these properties are achieved by OCB. We believe that the lack of strong security properties has been a problem for the standard modes of operation, because many users of encryption implicitly assume these properties when designing their protocols. For example, it is common to see protocols which use symmetric encryption in order to “bind together” the parts of a plaintext, or which encrypt related messages as a way to do a “handshake.” Standard modes do not support such practices. This fact has sometimes led practitioners to incorrectly apply the standard modes, or to invent or select wrong ways to encrypt with authenticity (a well-known example is the use of PCBC mode [27] in Kerberos v.4 [29]). We believe that a mode like OCB is less likely to be misused because the usual abuses of privacy-only encryption become correct cryptographic techniques.
By way of comparison, a chosen-ciphertext attack by Bleichenbacher on the public-key encryp- tion scheme of RSA PKCS #1, v.1, motivated the company that controls this de facto standard to promptly upgrade its scheme [9, 28]. In contrast, people seem to accept as a matter of course sym- metric encryption schemes which are not even non-malleable. There would seem to be no technical reason to account for this difference in expectations.
The future. We believe that most of the time privacy is desired, authenticity is too. As a consequence, fast authenticated encryption may quickly catch on. OCB has already appeared in one draft standard—the wireless LAN standard IEEE 802.11—and it is also under consideration by NIST.
2 Preliminaries
Notation. If a and b are integers, a ≤ b, then [a..b] is the set {a, a+ 1, . . . , b}. If i ≥ 1 is an integer then ntz(i) is the number of trailing 0-bits in the binary representation of i (equivalently, ntz(i) is the largest integer z such that 2z dividesi). So, for example,ntz(7) = 0 andntz(8) = 3.
A string is a finite sequence of symbols, each symbol being 0 or 1. The string of length 0 is called theempty string and is denotedε. Let{0,1}∗ denote the set of all strings. IfA, B∈ {0,1}∗ then A B, or A B, is their concatenation. If A ∈ {0,1}∗ and A = ε then firstbit(A) is the first bit of A and lastbit(A) is the last bit of A. Let i, n be nonnegative integers. Then 0i and 1i denote the strings ofi0’s and 1’s, respectively. Let {0,1}ndenote the set of all strings of lengthn. If A ∈ {0,1}∗ then |A| denotes the length of A, in bits, while A n = max{1, |A|/n} denotes the length of A in n-bit blocks, where the empty string counts as one block. For A∈ {0,1}∗ and
|A| ≤ n, zpadn(A) is the string A0n−|A|. With n understood we will write A0∗ for zpadn(A). If A∈ {0,1}∗ andτ ∈[0..|A|] thenA[firstτ bits] andA[lastτ bits] denote the firstτ bits ofAand the lastτ bits of A, respectively. Both of these values are the empty string if τ = 0. IfA, B ∈ {0,1}∗ thenA⊕B is the bitwise xor of A[firstbits] and B[firstbits], where = min{|A|,|B|} (where ε⊕A = A ⊕ε = ε). So, for example, 1001⊕11 = 01. If A = an−1· · ·a1a0 ∈ {0,1}n then str2num(A) is the number n−1
i=0 2iai. Ifa∈[0..2n−1] thennum2strn(a) is then-bit stringA such thatstr2num(A) =a. Let lenn(A) =num2strn(|A|). We omit the subscript when nis understood.
If A = an−1an−2· · ·a1a0 ∈ {0,1}n then A<<1 is the n-bit string an−2an−3· · ·a1a00 which is a left shift of A by one bit (the first bit of A disappearing and a zero coming into the last bit), whileA>>1 is then-bit string 0an−1an−2. . . a2a1 which is a right shift ofA by one bit (the last bit disappearing and a zero coming into the first bit).
In pseudocode we write “PartitionM intoM[1]· · ·M[m]” as shorthand for “Letm= M nand let M[1], . . . , M[m] be strings such that M[1]· · ·M[m] = M and |M[i]|=n for 1 ≤i < m.” We write “PartitionCintoC[1]· · ·C[m]T” as shorthand for “if|C|< τ then returnInvalid. Otherwise, let C=C[first|C| −τ bits], letT =C[lastτ bits], let m= C n, and let C[1], . . . , C[m] be strings such that C[1]· · ·C[m] =C and |C[i]|=n for 1≤i < m. Recall that M n = max{1, |M|/n}, so the empty string partitions into m= 1 block, that one block being the empty string.
The field with 2n points. Let GF(2n) denote the field with 2n points. We interchangeably think of a pointain GF(2n) in any of the following ways: (1) as an abstract point in a field; (2) as ann-bit stringan−1. . . a1a0 ∈ {0,1}n; (3) as a formal polynomiala(x) =an−1xn−1+· · ·+a1x+a0 with binary coefficients; (4) as an integer between 0 and 2n−1, where the string a ∈ {0,1}n corresponds to the number str2num(a). For example, one can regard the stringa = 0125101 as a 128-bit string, as the number 5, as the polynomialx2+ 1, or as an abstract point in GF(2128). We write a(x) instead of aif we wish to emphasize that we are thinking of aas a polynomial.
To add two points in GF(2n), take their bitwise xor. We denote this operation by a⊕b. To multiply two points in the field, first fix an irreducible polynomialpn(x) having binary coefficients and degreen: say the lexicographically first polynomial among the irreducible degreenpolynomials having a minimum number of nonzero coefficients. For n = 128, the indicated polynomial is p128(x) = x128 +x7 +x2 +x+ 1. A few other pn(x)-values are x64+x4 +x3+x+ 1 and x96+ x10+x9+x6+ 1 andx160+x5+x3+x2+ 1 andx192+x7+x2+x+ 1 andx224+x9+x8+x3+ 1 and x256+x10+x5+x2+ 1. To multiply a, b∈GF(2n), which we denotea·b, regard aand bas polynomials a(x) = an−1xn−1 +· · ·+a1x+a0 and b(x) = bn−1xn−1 +· · ·+b1x+b0, form their productc(x) over GF(2), and take the remainder one gets when dividing c(x) by pn(x).
It is computationally simple to multiplya∈ {0,1}nbyx. We illustrate the method forn= 128, in which case multiplying a=an−1· · ·a1a0 by xyieldsan−1xn+an−2xn−1+a1x2+a0x. Thus, if
the first bit of a is 0, then a·x= a<<1. If the first bit ofa is 1 then we must add x128 toa<<1.
Since p128(x) = x128+x7+x2 +x+ 1 = 0 we know that x128 = x7+x2+x+ 1, so adding x128 means to xor by 012010000111. In summary, when n= 128,
a·x =
a<<1 iffirstbit(a) = 0 (a<<1)⊕012010000111 iffirstbit(a) = 1
It is similarly easy to divide a∈ {0,1}128 by x(i.e., to multiply aby the multiplicative inverse ofx). If the last bit ofais 0, thena·x−1 isa>>1. If the last bit ofais 1 then we must add (xor) to a>>1 the valuex−1. Sincex128=x7+x2+x+1 we have thatx−1 =x127+x6+x+1 = 101201000011.
In summary, when n= 128, a·x−1 =
a>>1 iflastbit(a) = 0 (a>>1)⊕101201000011 iflastbit(a) = 1
Note thathuge=x−1 is a large number (when viewed as such); in particular, it starts with a 1 bit, sohuge ≥2n−1.
IfL∈ {0,1}n andi≥ −1, we writeL(i) as shorthand forL·xi. Using the equations just given, we have an easy way to compute from Lthe values L(−1), L(0), L(1), . . .,L(µ), whereµ is small number.
Gray codes. For≥1, a Gray code is an ordering γ = (γ0 γ1 . . . γ2−1) of {0,1} such that successive points differ (in the Hamming sense) by just one bit. Forna fixed number, OCB makes use of the “canonical” Gray codeγ =γn constructed byγ1 = (0 1) and, for >0,
γ+1 = ( 0γ0 0γ1 · · · 0γ2−2 0γ2−1 1γ2−1 1γ2−2 · · · 1γ1 1γ0 )
It is easy to see thatγ is a Gray code. What is more, for 1≤i≤2n−1,γi =γi−1⊕(0n−11<<ntz(i)).
This makes it easy to compute successive points.
We emphasize the following characteristics of the Gray-code valuesγ1, γ2, . . . , γ2n−1: that they are distinct and different from 0; thatγ1= 1; and that γi<2i.
Let L ∈ {0,1}n and consider the problem of successively forming the strings γ1 ·L, γ2 ·L, γ3·L, . . .,γm·L. Of courseγ1·L= 1·L=L. Now, for i≥2, assume one has already produced γi−1·L. Sinceγi=γi−1⊕(0n−11<<ntz(i)) we know that
γi·L = (γi−1⊕(0n−11<<ntz(i)))·L
= (γi−1·L)⊕(0n−11<<ntz(i))·L
= (γi−1·L)⊕(L·xntz(i))
= (γi−1·L)⊕L(ntz(i))
That is, theith word in the sequenceγ1·L, γ2·L, γ3·L, . . .is obtained by xoring the previous word with L(ntz(i)). Had the sequence we were considering beenγ1·L⊕R,γ2·L⊕R,γ3·L⊕R, . . ., theith word would be formed in the same way for i≥2, but the first word in the sequence would have beenL⊕R instead ofL.
3 The Scheme
Parameters. To use OCB one must specify a block cipher and a tag length. The block cipher is a functionE:K×{0,1}n→ {0,1}n, for some numbern, where eachE(K,·) =EK(·) is a permutation
❢
❢
❢
❢
q q q q
❢
❢
q q
❢
❢
❢
❢
❢
❄
❄
❄
✛
❄
❄
❄
✛
❄
❄✛
✲ ❄
❄
❄
❄
❄
❄
✛
✛
❄
❄
✛
✛
❄
❄ ❄
❄
❄
❄
✛
✛
❄
❄
❄
✛
✛
M[m]
Z[m]
len
L·x−1
EK
T Z[m]
firstτbits τ
C[m]
Y[m]
C[1]
Z[1]
EK
Z[1]
M[1]
Z[2]
Z[2]
M[2]
C[2]
EK
Z[m−1]
Z[m−1]
EK
C[m−1]
M[m−1]
Checksum N
L
R
EK EK
X[m]
AlgorithmOCB.EncK (N, M) PartitionM into M[1]· · ·M[m] L←EK(0n)
R←EK(N ⊕L)
fori←1 tom doZ[i] =γi·L⊕R fori←1 tom−1 do
C[i]←EK(M[i]⊕Z[i]) ⊕ Z[i] X[m]←len(M[m])⊕L·x−1⊕Z[m] Y[m]←EK(X[m])
C[m]←Y[m]⊕M[m] C←C[1]· · ·C[m] Checksum←
M[1]⊕ · · · ⊕M[m−1]⊕C[m] 0∗⊕Y[m] T ←EK(Checksum⊕Z[m]) [firstτ bits]
returnC←C T
AlgorithmOCB.DecK (N,C) Partition CintoC[1]· · ·C[m]T L←EK(0n)
R←EK(N⊕L)
for i←1tom do Z[i] =γi·L⊕R for i←1tom−1do
M[i]←EK−1(C[i]⊕Z[i]) ⊕ Z[i] X[m]←len(C[m])⊕L·x−1⊕Z[m] Y[m]←EK(X[m])
M[m]←Y[m]⊕C[m] M ←M[1]· · ·M[m] Checksum←
M[1]⊕ · · · ⊕M[m−1]⊕C[m] 0∗⊕Y[m] T ←EK(Checksum⊕Z[m]) [firstτ bits]
if T =T then returnM else returnInvalid
Figure 1: OCB encryption. The message to encrypt isM and the key isK. MessageM is written as M =M[1]M[2]· · ·M[m−1]M[m], wherem= max{1, |M|/n}and|M[1]|=|M[2]|=· · ·=|M[m−1]|= n. Nonce N is a non-repeating value selected by the party that encrypts. It is sent along with ciphertext C=C[1]C[2]C[3]· · ·C[m−1]C[m]T. The Checksum is M[1]⊕ · · · ⊕M[m−1]⊕C[m] 0∗⊕Y[m]. Offset Z[1] =L⊕R while, for i≥2, Z[i] = Z[i−1]⊕L(ntz(i)). StringL is defined by applyingEK to a fixed string, 0n. For Y[m]⊕M[m] and and Y[m]⊕C[m], truncate Y[m] if it is longer than the other operand.
By C[m] 0∗ we mean C[m] padded on the right with 0-bits to get to lengthn. The function len represents the length of its argument as ann-bit string.
on{0,1}n. HereK is the set of possible keys andnis the block length. Both are arbitrary, though we insist thatn≥64, and we discouragen <128. Thetag lengthis an integerτ ∈[0..n]. By trivial means, the adversary will be able to forge a valid ciphertext with probability 2−τ. The popular block cipher to use with OCB is likely to be AES [34]. As for the tag length, a suggested default of τ = 64 is reasonable. Tags of 32bits are standard in retail banking. Tags of 96 bits are used in IPSec. Using a tag of more than 80 bits adds questionable security benefit, though it does lengthen each ciphertext.
We let OCB-E denote the OCB mode of operation using block cipher E and an unspecified tag length. We let OCB[E, τ] denote the OCB mode of operation using block cipher E and tag lengthτ.
Nonces. Encryption under OCB mode requires an n-bit nonce, N. The nonce would typically be a counter (maintained by the sender) or a random value (selected by the sender). Security is maintained even if the adversary can control the nonce, subject to the constraint that no nonce may be repeated within the current session (that is, during the period of use of the current encryption key). The nonce need not be random, unpredictable, or secret.
The nonce N is needed both to encrypt and to decrypt. Typically it would be communicated, in the clear, along with the ciphertext. However, it is out-of-scope how the nonce is communicated to the party who will decrypt. In particular, we do not regard the nonce as part of the ciphertext.
Definition of the mode. See Figure 1 for a definition and illustration of OCB. The figure defines OCB encryption and decryption. The key space for OCB is the key space K for the underlying block cipherE.
An equivalent description. The following description may clarify what a typical implementa- tion might do.
Key generation. Choose a random keyK ← KR for the block cipher. The keyK is provided to both the entity that encrypts and the entity that decrypts.
Key setup. For the party that encrypts, do any key setup associated to block-cipher enciphering. For the party that decrypts, do any key setup associated to block-cipher enciphering and deciphering.
Let L ← EK(0n). Let m bound the maximum number of n-bit blocks that any message which will be encrypted or decrypted may have. Let µ ← log2m. Let L(0) ← L and, for i ∈ [1..µ], computeL(i)←L(i−1)·xusing a shift and a conditional xor, as described in Section 2. Compute L(−1) ← L·x−1 using a shift and a conditional xor, as described in Section 2. Save the values L(−1), L(0), L(1), . . .,L(µ) in a table.
Encryption. To encrypt plaintext M ∈ {0,1}∗ using key K and nonce N ∈ {0,1}n, obtaining a ciphertext C, do the following. Let m← |M|/n. Ifm = 0 then letm ←1. Let M[1], . . . , M[m] be strings such thatM[1]· · ·M[m] =M and|M[i]|=nfori∈[1..m−1]. Let Offset←EK(N⊕L).
Let Checksum ← 0n. For i ← 1 to m−1, do the following: let Checksum ← Checksum⊕M[i];
let Offset ← Offset ⊕L(ntz(i)); let C[i] ← EK(M[i]⊕Offset)⊕Offset. Let Offset ← Offset⊕ L(ntz(m)). LetY[m]←EK(len(M[m])⊕L(−1)⊕Offset). Let C[m]←M[m] xored with the first
|M[m]|bits of Y[m]. Let Checksum ←Checksum⊕Y[m]⊕C[m] 0∗. Let T be the first τ bits of EK(Checksum⊕Offset). The ciphertext isC=C[1]· · ·C[m−1]C[m]T. It must be communicated along with the nonceN.
Decryption. To decrypt ciphertext C ∈ {0,1}∗ using key K and nonce N ∈ {0,1}n, obtaining a plaintext M ∈ {0,1}∗ or an indicationInvalid, do the following. If |C|< τ then return Invalid (the ciphertext has been rejected). Otherwise let C be the first |C| −τ bits of C and let T be the
remaining τ bits. Let m ← |C|/n. If m = 0 then let m = 1. Let C[1], . . . , C[m] be strings such that C[1]· · ·C[m] = C and |C[i]| = n for i ∈ [1..m−1]. Let Offset ← EK(N ⊕L). Let Checksum←0n. Fori←1 tom−1, do the following: let Offset←Offset⊕L(ntz(i)); letM[i]← EK−1(C[i]⊕Offset)⊕Offset; let Checksum←Checksum⊕M[i]. Let Offset←Offset⊕L(ntz(m)). Let Y[m]←EK(len(C[m])⊕L(−1)⊕Offset). LetM[m]←C[m] xored with the first|C[m]|bits ofY[m].
Let Checksum←Checksum⊕Y[m]⊕C[m] 0∗. LetTbe the firstτ bits ofEK(Checksum⊕Offset).
If T = T then return Invalid (the ciphertext has been rejected). Otherwise, the plaintext is M =M[1]· · ·M[m−1]M[m].
4 Discussion
OCB has been designed to have a variety of desirable properties. These properties are summarized in Figure 2. We now expand on some of the points made in that table, and add some further comments.
Arbitrary-length messages and no ciphertext expansion. One of the key characteristics of OCB is that any string M ∈ {0,1}∗ can be encrypted, and doing this yields a ciphertext C of length|M|+τ. That is, the length of the “ciphertext core”—the portionC=C[1]· · ·C[m] of the ciphertext that excludes the tag—is the same as the length of the message M. This is better, by up to nbits, than what one gets with conventional padding.
Single block-cipher key. OCB makes use of just one block-cipher key,K. While L=EK(0n) functions rather like a key and would normally be computed at key-setup time, and while standard key-separation techniques can always be used to obtain many keys from one, the point is that, in OCB, all block-cipher invocations use the one keyK. Thus only one block-cipher key needs to be setup, saving on storage space and key-setup time.
Weak nonce requirements. We believe that modes of operation that require a random IV are often misused. As an example, consider CBC mode, where C[i] = EK(M[i]⊕C[i−1]) and C[0] = IV. Many standards and many books (e.g., Schneier, Applied Cryptography, 2nd edition, p. 194]) suggest that the IV may be a fixed value, a counter, a timestamp, or the last block of ciphertext from the previous message. But if it is any of these things one certainly will not achieve any of the standard definitions of security [3, 16].
It is sometimes suggested that a mode which needs a random IV is preferable to one that needs a nonce: it is said that state is needed for a nonce, but not for making random bits. We find this argument wrong. First, a random value of sufficent length can always be used as a nonce, but a nonce can not be used as a random value. Second, the manner in which systems provide “random”
IVs is invariably stateful anyway: unpredictable bits are too expensive to harvest for each IV, so one does this rarely, using state to generate pseudorandom bits from unpredictable bits harvested before.
Third, the way to generate pseudorandom bits needs to use cryptography, so the prevalence of non- cryptographic pseudorandom number generators routinely results in implementation errors. Next, nonce-based schemes facillitate replay-detection with constant space and no added cryptography.
Finally, nonces can be communicated using fewer bits, without additional cryptography.
On-line. OCB encryption and decryption are “on line” in the sense that one does not need to know the length of the message in advance of encrypting or decrypting it. Instead, messages can be processed as one goes along, using constant memory, continuing until there is an indication that the message is over. An incremental interface (in the style popular for cryptographic hash functions)
Security Function
Authenticated encryption. Provides both privacy and authenticity, eliminating the need to compute a separate MAC. Specifically, the scheme achieves authenticity of ciphertexts [7, 8, 22] and indistinguishability under chosen-plaintext attack [3, 16].
Error
Propagation
Infinite. If the ciphertext is corrupted in any manner then the received ciphertext will almost certainly (probability≈1−2−τ) be rejected.
Synchronization Optional. If the nonceN is transmitted along with each ciphertext, there are no synchronization requirements. If it is not sent (to save transmission bits) the receiver must maintain the corresponding value.
Parallelizability Fully parallelizable. Both encryption and decryption are fully paral- lelizable: all block-cipher invocations (except the first and last) may be computed at the same time.
Keying Material One block-cipher key. One needs a single key, K, which keys all invocations of the underlying block cipher.
Ctr/IV/Nonce Requirements
Single-use nonce. The encrypting party must supply a new nonce with each message it encrypts. The nonce need not be unpredictable or secret.
The nonce isn bits long (but it would typically be communicated using fewer bits, as determined by the application).
Memory Requirements
Very modest. About 6n bits beyond the key are sufficient for internal calculations. Implementations may choose whether or not to storeL(i)- values, allowing some tradeoff between memory and simplicity/speed.
Pre-processing Capability
Limited. During key setup the stringLwould typically be precomputed (one block cipher call), as would the first few L(i) values, and maybe L·x−1. The block-cipher key K would be converted into its convenient representation. Unlike counter mode, additional precomputation prior to knowing the string to encrypt/decrypt is not possible.
Message-Length Requirements
Any bit string allowed. Any string M ∈ {0,1}∗ may be encrypted, including the empty string and strings which are not an integral number of bytes. The length of the string does need not be known in advance.
Ciphertext Expansion
Minimal possible (for a scheme meeting the desired privacy notion).
Expansion is 0–nbits for the tag plus 0–nbits for the nonce. The former depends on a user-specified parameter τ, with 32–80 bits being typical.
Messages which are not a multiple of the blocksize do not receive addi- tional expansion due to padding.
Other
Characteristics
Efficiency: Uses |M|/n+ 2block-cipher calls and very efficient offset- calculations. Endian neutrality: Can be implemented equally effi- ciently on big-endian and little-endian machines. Provable security:
The mode provably meets its goals, assuming the underlying block cipher meets standard cryptographic assumptions.
Figure 2: Summary properties of OCB.
would be used to support this functionality.
Significance of being efficient. Shaving off a few block-cipher calls or a few bytes of ciphertext may not seem important. But often one is dealing with short messages; for example, roughly a third of the messages on the Internet backbone are 43 bytes. If one is encrypting messages of such short lengths, one should be careful about message expansion and extra computational work since, by percentage, the inefficiencies can be large.
The argument has been made that making a major effort to save a factor of two in computational efficiency is marginal in the first place: “Moore’s law” will soon deliver such an improvement anyway, by way of faster hardware. We are not persuaded. Concommitent with processors getting faster has been security becoming increasingly at issue, and low-power processors becoming all the more prevalent. The result is a need to cryptographically process more and more data, and often by “dumb” execution vehicles that have plenty of other things to do. Hardware advances have changed our understanding of what efficiency entails but, to date, hardware advances have not made cryptographic efficiency any less important.
Endian neutrality. In contrast to a scheme based on mod-parithmetic (for p a prime just less than 2n) or mod-2n arithmetic, there is almost no endian-favoritism implicit in the definition of OCB. (The exception is that, because of our use of standard mathematical conventions, the left shift used for forming L(i+ 1) from L(i) is more convenient under a big-endian convention, as is the right shift used for forming L(−1) =L·x−1 from L.)
Optional pre-processing. Implementations can choose how many L(i) values to precompute.
As only one block-cipher call is needed to compuet these values from K, plus some shifts and conditional xors, it is feasible to do no preprocessing: OCB-AES is appropriate even when each session is a single, short message.
Provable security. Provable security has become a popular goal for practical protocols. This is because it provides the best way to gain assurance that a cryptographic scheme does what it is should. For a scheme which enjoys provable security one does not need to consider attacks on the scheme, since successful ones imply successful attacks on some simpler object.
When we say that “OCB is provably secure” we are asserting the existence of two theorems.
One says that if an adversary A could do a good job at forging ciphertexts with OCB[E, τ] (the adversary does this much more than a 2−τ fraction of the time) then there would be an adversaryB that does a good job at distinguishing (EK(·), EK−1(·)), for a random keyK, from (π(·), π−1(·)), for a random permutation π ∈ Perm(n). The other theorem says that if an adversary A could do a good job at distinguishing OCB[E, τ]-encrypted messages from random strings, then there would be an adversaryB that does a good job at distinguishingEK(·), for a random keyK, fromπ(·), for a random permutationπ ∈Perm(n). Theorems of this sort are calledreductions. In cryptography, provable security means giving reductions (along with the associated definitions).
Provable security begins with Goldwasser and Micali [16], though the style of provable security which we use here—where the primitive is a block cipher, the scheme is a usage mode, and the analysis is concrete (no asymptotics)—is the approach of Bellare and Rogaway [3, 5, 6].
It is not enough to know that there is a provable-security result; one should also understand the definitions and the bounds. We have already sketched the definitions. When we speak of the bounds we are addressing “how effective is the adversaryB in terms of the efficacy of adversary A” (where A and B are as above). For OCB, the bounds can be roughly summarized as follows. An adversary can always forge with probability 1/2τ. Beyond this, the maximal added advantage is at mostσ2/2n, whereσ is the total number of blocks the adversary sees. The privacy bound likewise
degrades as σ2/2n. The conclusion is that one is safe using OCB as long as the underlying block cipher is secure andσis small compared to 2n/2. This is the same security degradation one observes for CBC encryption and in the bound for the CBC MAC [3, 6]. This kind of security loss was the main motivation for choosing a block length for AES ofn= 12 8 bits.
Comparison with Jutla’s bound. More precisely, but still ignoring lower-order terms, our privacy and authenticity bounds are 1.5σ2/2n, while Jutla’s authenticity bound is insignificantly worse at 2σ2/2nand his privacy bound, rescaled to [0,1], looks insignificantly worse at 3σ2/2n[20].
Magnifying the latter difference is that the privacy results assume different defintions. Jutla adopts the find-then-guess definition of privacy [3, 16], while we use an indistinguishability-from-random- bits definition. The former captures an adversary’s inability to distinguish ciphertexts for a pair adversarilly-selected, equal-length plaintexts. The latter captures an adversary’s inability to distin- guish a ciphertext from a random string of the same length. Indistinguishability-from-random-bits implies find-then-guess security, and by a tight reduction, but find-then-guess secure does not imply indistinguishability-from-random-bits. Still, Jutla’s scheme probably satisfies the stronger definition.
Simplicity. Simplicity has been a central design goal. Some of OCB’s characteristics that con- tribute to simplicity are:
Short and full final-message-blocks are handled without making a special case: the treatment of all messages is uniform, regardless of their length.
Only the simplest form of padding is used: append a minimal number of 0-bits to make a string whose length is a multiple ofn. This method is computationally fastest and helps avoid a proliferation of cases in the analysis.
Only one algebraic structure is used throughout the algorithm: the finite field GF(2n).
In forming the sequence of offsets, Gray-code coefficients are taken monotonically, starting at 1 and stopping at m. One never goes back to some earlier offset, uses a peculiar starting point, or forms more offsets than there are blocks.
Not fixing how the nonce is communicated. We do not specify how the nonce is chosen or communicated. Formally, it is not part of the ciphertext (though the receiving party needs it to decrypt). In many contexts, there is already a natural value to use as a nonce (e.g., a sequence number already present in a protocol flow, or implicit because the parties are communicating over a reliable channel). Even when a protocol is designed from scratch, the number of bits needed to communicate the nonce will vary. In some applications, 32or 8 bits is enough. For example, one might have reason to believe that there are at most 232 messages that will flow during the connection, or one may communicate only the lowest 8 bits of a sequence number, counting on the Receiver to anticipate the high-order bits.
Not fixing the tag length. The number of bits necessary for the tag vary according to the application. In a context where the adversary obtains something quite valuable from a successful forgery, one may wish to choose a tag length of 80 bits or more. In contexts such as authenticating a video stream, where an adversary would have to forge many frames to have a major impact on the image, an 8-bit tag may be appropriate. With no universally correct value to choose, it is best to leave this parameter unspecified.
Short tags seem to be more appropriate for OCB than for some other MACs, particularly Carter- Wegman MACs. Many Carter-Wegman MACs have the property that if you can forge one message with probabilityδ then you can forge an arbitrary set of (all correct) messages with probability δ.
This does not appear to be true for OCB (though we have not investigated formalizing or proving such properties).
FormingR using a block-cipher call. During our work we discovered that there are methods for authenticated-encryption which encryptM using|M|/n+ 1 block-cipher calls, as opposed to our|M|/n+ 2calls. Shai Halevi has also made this finding [17]. However, the methods we know to shave off a block-cipher call either require an unpredictable IV instead of a nonce, or they add conceptual and computational complexity to compute the initial offset R by non-cryptographic means (e.g., using a finite-field multiplication of the nonce and a key variant).
Avoiding mod-2naddition. Our earlier designs included a scheme based on modular 2naddition (“addition” for the remainder of this paragraph). Basing an authenticated-encryption scheme on addition is an interesting idea due to Gligor and Donescu [15]. Compared to our GF(2n)-based approach (“xor” for the remainder of this paragraph), an addition-based scheme is quicker to understand a specification for, and may be easier to implement. But the use of addition (where n≥128) has several disadvantages:
The bit-asymmetry of the addition operator implies that the resulting scheme will have a bias towards big-endian architectures or little-endian architectures; there will be no way to achieve an endian-neutral scheme. The AES algorithm was constructed to be endian-neutral and we wanted OCB-AES to inherit this attribute.
Addition is unpleasant for implementations using high-level languages, where one normally has no access to the add-with-carry instruction the machine may have.
Addition needs more chip area than xor.
Addition is not parallelizable. As a consequence, dedicated hardware will perform this op- eration more slowly than xor, and, correspondingly, modern processors can xor two n-bit quantities faster than they can add them.
The concrete security bound appears to be worse with addition than xor (though still not bad). The degradation would seem to be Θ(lg ¯m), where ¯mis the maximal message length.
We eventually came to feel that even the simplicity benefit of addition was not quite real: these schemes seem harder to understand, to prove correct, and to implement well.
Lazy mod-p addition. Let p be the largest prime less than 2n. An earlier design [31] allowed one to produce offsetZ[i] fromZ[i−1] by “lazy mod-p addition”: add LtoZ[i−1], mod 2n, and then add δ = 2n−p whenever the first addition generates a carry. Now X[m] would be defined by len(M[m])⊕Z[m], say, whereZ[m] is the bitwise complement of Z[m]. It appears that, unlike a mod-2n scheme, xors can still be used to combine offsets with message blocks and enciphered message blocks. This might make lazy mod-p approach more attractive than a mod-2n approach.
But in order to propagate a single scheme, avoid endian favoritism, and avoid complicating an already complex proof, we chose not to propagate lazy mod-p-addition.
Definition of the Checksum. An initially odd-looking aspect of OCB’s definition is the defini- tion of Checksum =M[1]⊕ · · ·M[m−1]⊕C[m] 0∗⊕Y[m]. In Jutla’s scheme, where one assumes that all messages are a positive multiple of the block length, the checksum is the simpler-looking M[1]⊕ · · ·M[m−1]⊕M[m]. We comment that these two definitions are identical in the case that
|M[m]|=n. What is more, the definition Checksum =M[1]⊕ · · ·M[m−1]⊕M[m] 0∗ turns out to be the wrong way to generalize the Checksum to allow for short-final-block messages; in particular, the scheme using that checksum is easily attacked.
Avoiding pretag collisions. Many of our earlier schemes, including [31], allowed the adversary to force a “pretag collision.” Recall that we compute the tagT by computing a “pretag”X[m+1] = Checksum⊕SomeOffset, forming a valueY[m+ 1] =EK(X[m+ 1]), and then forming T by doing further processing to Y[m+ 1]. For a scheme of this form, we say that an adversary can force a pretag collision if there is anN, M¯ that can be encrypted, getting ¯CT¯, and then a forgery attempt N, C T can be made such that, in it, the pretag X[m+ 1] will coincide with a value X[i] or ¯X[i] at which the block cipherE was already evaluated.
We designed OCB so that an adversary can not force pretag collisions. The presence of pretag collisions substantially complicates proofs, since one can not follow a line of argument that shows that tags are unpredictable because each pretag-value is almost certainly new. For schemes like IAPM, where pretag collisions can be forced, this intuition is simply wrong. Beyond this, in the presence of pretag collisions one must modifyY[m+1] by an amount ∆ that depends on at least the key and nonce. Say that the modification is by xor, and one wants to be able to pull off an arbitrary bit as a 1-bit authentication tag. Then every bit of ∆ will have to be adversarially unpredictable.
This is unfortunate, as many natural ways to make ∆ fail to have this property. Suppose, for example, the first couple bits of L are forced to zero, as suggested by [31], and ∆ =L·(m+ 1).
Then, for small m, the first bit of ∆ will be zero. This can be exploited to give an attack on the xor-based scheme of [31] when τ = 1. Similarly, for i a power of two, ∆ =iL mod 2n ends in a 0-bit, so had [31] taken the tag to be the last τ bits instead of the first τ bits, one would again have an attack on 1-bit tags. A scheme would be arcane, at best, if certain bits of the full tag are usable and other bits are not.
Block-cipher circuit-depth. One further efficiency measure is the circuit depth of an encryp- tion scheme as measured in terms of block-cipher gates. For OCB encryption, this number is three:
a call to form R; calls to form the ciphertext core; and a call to compute the tag. Block-cipher circuit-depth serves as a lower bound for latency in an agressively parallel environment. Reducing the block-cipher circuit-depth to one or two is possible, but the benefit does not seem worth the associated drawbacks.
5 T heorems
5.1 Security Definitions
We begin with the requisite definitions. These are not completely standard because OCB uses a nonce, and we wish to give the adversary every possible advantage (more than is available in real life) by allowing her to choose this nonce (though we forbid the adversary from choosing the same nonce twice).
Syntax. We extend the syntax of an encryption scheme as given in [3]. A (nonce-using, symmetric) encryption scheme is a triple Π = (K,E,D) and an associated number n(the nonce length). Here K is a finite set and E and D are deterministic algorithms. Encryption algorithm E takes K ∈ K, N ∈ {0,1}n, and M ∈ {0,1}∗, and returns a stringC← EK(N, M). Decryption algorithmD takes K ∈ K,N ∈ {0,1}n, andC∈ {0,1}∗, and returns DK(N, M), which is either a string M ∈ {0,1}∗ or the distinguished symbol Invalid. If C← EK(N, M) thenDK(N,C) =M.
Privacy. We give a particularly strong definition of privacy, one asserting indistinguishability from random strings. This notion is easily seen to imply more standard definitions [3], and by tight reductions. Consider an adversaryAwho has one of two types of oracles: a “real” encryption
oracle or a “fake” encryption oracle. A real encryption oracle, EK(·,·), takes as input N, M and returnsC← EK(N, M). Assume that|C|=(|M|) depends only on |M|. A fake encryption oracle,
$(·,·), takes as input N, M and returns a random string C ← {R 0,1}(|M|). Given adversary A and encryption scheme Π = (K,E,D), define AdvprivΠ (A) = Pr[K ← KR : AEK(·,·) = 1]−Pr[K ←R K: A$(·,·)= 1].
An adversary A is nonce-respecting if it never repeats a nonce: if A asks its oracle a query (N, M) it will never subsequently ask its oracle a query (N, M), regardless of its coins (if any) and regardless of oracle responses. All adversaries are assumed to be nonce-respecting.
Authenticity. We extend the notion of integrity of ciphertexts of [7, 8, 22]. Fix an encryption scheme Π = (K,E,D) and run an adversaryAwith an oracleEK(·,·) for some keyK. AdversaryA forges (in this run) if A is nonce-respecting, A outputs (N,C) where DK(N,C) = Invalid, and A made no earlier query (N, M) which resulted in a response C. Let AdvauthΠ (A) = Pr[K ←R K: AEK(·,·) forges ]. We stress that the nonce used in the forgery attempt may coincide with a nonce used in one of the adversary’s queries.
Block ciphers and PRFs. A function family from n-bits to n-bits is a mapE :K × {0,1}n → {0,1}nwhereKis a finite set of strings. It is ablock cipherif eachEK(·) =E(K,·) is a permutation.
Let Rand(n) denote the set of all functions from{0,1}n to{0,1}n and let Perm(n) denote the set of all permutations from {0,1}n to {0,1}n. These sets can be regarded as function families by imagining that each member is specified by a string. For π ∈Perm(n), let π−1(Y) be the unique stringX such thatπ(X) =Y. Let
AdvprfE (A) = Pr[K ← KR : AEK(·)= 1]−Pr[ρ←R Rand(n) : Aρ(·)= 1]
AdvprpE (A) = Pr[K ← KR : AEK(·)= 1]−Pr[π←R Perm(n) : Aπ(·) = 1]
AdvsprpE (A) = Pr[K ← KR : AEK(·),EK−1(·) = 1]−Pr[π←R Perm(n) : Aπ(·),π−1(·)= 1]
5.2 Theorem Statements
We give information-theoretic bounds on the authenticity and the privacy of OCB. Proofs are in Appendix B.
Theorem 1 [Authenticity] Fix OCB parameters nand τ. Let A be an adversary that asksq queries and then makes its forgery attempt. Suppose the q queries have aggregate length of σ blocks,and the adversary’s forgery attempt has at most cblocks. Letσ¯ =σ+ 2q+ 5c+ 11. Then
AdvauthOCB[Perm(n),τ](A) ≤ 1.5 ¯σ2 2n + 1
2τ
The aggregate length of queries M1, . . . , Mq means the number σ=q
r=1 Mr n.
It is standard to pass to a complexity-theoretic analog of Theorem 1, but in doing this one will need access to anE−1 oracle in order to verify a forgery attempt, which translates into needing the strong PRP assumption. One gets the following. Fix OCB parametersnandτ, and a block cipher E :K × {0,1}n→ {0,1}n. Let A be an adversary that asks q queries and then makes its forgery attempt. Suppose the q queries have aggregate length of σ blocks, and the adversary’s forgery attempt has at mostcblocks. Let ¯σ=σ+2q+5c+11. Letδ=AdvauthOCB[E,τ](A)−1.5 ¯σ2/2n−1/2τ.
