idnits 2.17.00 (12 Aug 2021) /tmp/idnits57547/draft-irtf-cfrg-ocb-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 06, 2014) is 3019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 202 -- Looks like a reference, but probably isn't: '2' on line 188 -- Looks like a reference, but probably isn't: '3' on line 188 == Unused Reference: 'OCB1ALT' is defined on line 657, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force T. Krovetz 3 Internet-Draft Sacramento State 4 Intended status: Informational P. Rogaway 5 Expires: August 10, 2014 UC Davis 6 February 06, 2014 8 The OCB Authenticated-Encryption Algorithm 9 draft-irtf-cfrg-ocb-07 11 Abstract 13 This document specifies OCB, a shared-key blockcipher-based 14 encryption scheme that provides confidentiality and authenticity for 15 plaintexts and authenticity for associated data. This document is a 16 product of the Crypto Forum Research Group (CFRG). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 10, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Notation and Basic Operations . . . . . . . . . . . . . . . . 4 54 3. OCB Global Parameters . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Named OCB Parameter Sets and RFC 5116 Constants . . . . . 5 56 4. OCB Algorithms . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Associated-Data Processing: HASH . . . . . . . . . . . . 6 58 4.2. Encryption: OCB-ENCRYPT . . . . . . . . . . . . . . . . . 7 59 4.3. Decryption: OCB-DECRYPT . . . . . . . . . . . . . . . . . 9 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 5.1. Nonce Requirements . . . . . . . . . . . . . . . . . . . 12 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 66 8.2. Informative References . . . . . . . . . . . . . . . . . 14 67 Appendix A. Sample Results . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 70 1. Introduction 72 Schemes for authenticated encryption (AE) simultaneously provide for 73 confidentiality and authentication. While this goal would 74 traditionally be achieved by melding separate encryption and 75 authentication mechanisms, each using its own key, integrated AE 76 schemes intertwine what is needed for confidentiality and what is 77 needed for authenticity. By conceptualizing AE as a single 78 cryptographic goal, AE schemes are less likely to be misused than 79 conventional encryption schemes. Also, integrated AE schemes can be 80 significantly faster than what one sees from composing separate 81 confidentiality and authenticity means. 83 When an AE scheme allows for the authentication of unencrypted data 84 at the same time that a plaintext is being encrypted and 85 authenticated, the scheme is an authenticated encryption with 86 associated data (AEAD) scheme. Associated data can be useful when, 87 for example, a network packet has unencrypted routing information and 88 an encrypted payload. 90 OCB (short for Offset Codebook) is an AEAD scheme that depends on a 91 blockcipher. This document fully defines OCB encryption and 92 decryption except for the choice of the blockcipher and the length of 93 authentication tag that is part of the ciphertext. The blockcipher 94 must have a 128-bit blocksize. Each choice of blockcipher and tag 95 length specifies a different variant of OCB. Several AES-based 96 variants are defined in Section 3.1. 98 OCB encryption and decryption employ a nonce N, which must be 99 distinct for each invocation of the OCB encryption operation. OCB 100 requires the associated data A to be specified when one encrypts or 101 decrypts, but it may be zero-length. The plaintext P and the 102 associated data A can have any bitlength. The ciphertext C one gets 103 by encrypting P in the presence of A consists of a ciphertext-core 104 having the same length as P, plus an authentication tag. One can 105 view the resulting ciphertext as either the pair (ciphertext-core, 106 tag) or their concatenation (ciphertext-core || tag), the difference 107 being purely how one assembles and parses ciphertexts. This document 108 uses concatenation. 110 OCB encryption protects the confidentiality of P and the authenticity 111 of A, N, and P. It does this using, on average, about a + m + 1.02 112 blockcipher calls, where a is the blocklength of A and m is the 113 blocklength of P and the nonce N is implemented as a counter (if N is 114 random then OCB uses a + m + 2 blockcipher calls). If A is fixed 115 during a session then, after preprocessing, there is effectively no 116 cost to having A authenticated on subsequent encryptions, and the 117 mode will average m + 1.02 blockcipher calls. OCB requires a single 118 key K for the underlying blockcipher, and all blockcipher calls are 119 keyed by K. OCB is online. In particular, one need not know the 120 length of A or P to proceed with encryption, nor need one know the 121 length of A or C to proceed with decryption. OCB is parallelizable: 122 the bulk of its blockcipher calls can be performed simultaneously. 123 Computational work beyond blockcipher calls consists of a small and 124 fixed number of logical operations per call. OCB enjoys provable 125 security: the mode of operation is secure assuming that the 126 underlying blockcipher is secure. As with most modes of operation, 127 security degrades as the number of blocks processed gets large (see 128 Section 5 for details). 130 For reasons of generality, OCB is defined to operate on arbitrary 131 bit-strings. But for reasons of simplicity and efficiency, most 132 implementations will assume that strings operated on are byte-strings 133 (ie, strings that are a multiple of 8 bits). To promote 134 interoperability, implementations of OCB that communicate with 135 implementations of unknown capabilities should restrict all provided 136 values (nonces, tags, plaintexts, ciphertexts, and associated data) 137 to byte-strings. 139 The version of OCB defined in this document is a refinement of two 140 prior schemes. The original OCB version was published in 2001 [OCB1] 141 and was listed as an optional component in IEEE 802.11i. A second 142 version was published in 2004 [OCB2] and is specified in ISO 19772. 143 The scheme described here is called OCB3 in the 2011 paper describing 144 the mode [OCB3]; it shall be referred to simply as OCB throughout 145 this document. The only difference between the algorithm of this RFC 146 and that of the [OCB3] paper is that the tag length is now encoded 147 into the internally formatted nonce. See [OCB3] for complete 148 references, timing information, and a discussion of the differences 149 between the algorithms. 151 OCB has received years of in-depth analysis previous to its 152 submission to the CFRG, and has been under review by the members of 153 the CFRG for over a year. It is the consensus of the CFRG that the 154 security mechanisms provided by the OCB AEAD algorithm described in 155 this document are suitable for use in providing confidentiality and 156 authentication. 158 2. Notation and Basic Operations 160 There are two types of variables used in this specification, strings 161 and integers. Although strings processed by most implementations of 162 OCB will be strings of bytes, bit-level operations are used 163 throughout this specification document for defining OCB. String 164 variables are always written with an initial upper-case letter while 165 integer variables are written in all lower-case. Following C's 166 convention, a single equals ("=") indicates variable assignment and 167 double equals ("==") is the equality relation. Whenever a variable 168 is followed by an underscore ("_"), the underscore is intended to 169 denote a subscript, with the subscripted expression requiring 170 evaluation to resolve the meaning of the variable. For example, when 171 i == 2, then P_i refers to the variable P_2. 173 c^i The integer c raised to the i-th power. 175 bitlen(S) The length of string S in bits (eg, bitlen(101) == 3). 177 zeros(n) The string made of n zero-bits. 179 ntz(n) The number of trailing zero bits in the base-2 180 representation of the positive integer n. More 181 formally, ntz(n) is the largest integer x for which 2^x 182 divides n. 184 S xor T The string that is the bitwise exclusive-or of S and T. 185 Strings S and T will always have the same length. 187 S[i] The i-th bit of the string S (indices begin at 1, so if 188 S is 011 then S[1] == 0, S[2] == 1, S[3] == 1). 190 S[i..j] The substring of S consisting of bits i through j, 191 inclusive. 193 S || T String S concatenated with string T (eg, 000 || 111 == 194 000111). 196 str2num(S) The base-2 interpretation of bitstring S (eg, 197 str2num(1110) == 14). 199 num2str(i,n) The n-bit string whose base-2 interpretation is i (eg, 200 num2str(14,4) == 1110 and num2str(1,2) == 01). 202 double(S) If S[1] == 0 then double(S) == (S[2..128] || 0); 203 otherwise double(S) == (S[2..128] || 0) xor (zeros(120) 204 || 10000111). 206 3. OCB Global Parameters 208 To be complete, the algorithms in this document require specification 209 of two global parameters: a blockcipher operating on 128-bit blocks 210 and the length of authentication tags in use. 212 Specifying a blockcipher implicitly defines the following symbols. 214 KEYLEN The blockcipher's key length, in bits. 216 ENCIPHER(K,P) The blockcipher function mapping 128-bit plaintext 217 block P to its corresponding ciphertext block using 218 KEYLEN-bit key K. 220 DECIPHER(K,C) The inverse blockcipher function mapping 128-bit 221 ciphertext block C to its corresponding plaintext 222 block using KEYLEN-bit key K. 224 The TAGLEN parameter specifies the length of authentication tag used 225 by OCB and may be any value up to 128. Greater values for TAGLEN 226 provide greater assurances of authenticity, but ciphertexts produced 227 by OCB are longer than their corresponding plaintext by TAGLEN bits. 228 See Section 5 for details about TAGLEN and security. 230 As an example, if 128-bit authentication tags and AES with 192-bit 231 keys are to be used, then KEYLEN is 192, ENCIPHER refers to the 232 AES-192 cipher, DECIPHER refers to the AES-192 inverse cipher, and 233 TAGLEN is 128 [AES]. 235 3.1. Named OCB Parameter Sets and RFC 5116 Constants 237 The following table gives names to common OCB global parameter sets. 238 Each of the AES variants is defined in [AES]. 240 +----------------------------+-------------+--------+ 241 | Name | Blockcipher | TAGLEN | 242 +----------------------------+-------------+--------+ 243 | AEAD_AES_128_OCB_TAGLEN128 | AES-128 | 128 | 244 | AEAD_AES_128_OCB_TAGLEN96 | AES-128 | 96 | 245 | AEAD_AES_128_OCB_TAGLEN64 | AES-128 | 64 | 246 | AEAD_AES_192_OCB_TAGLEN128 | AES-192 | 128 | 247 | AEAD_AES_192_OCB_TAGLEN96 | AES-192 | 96 | 248 | AEAD_AES_192_OCB_TAGLEN64 | AES-192 | 64 | 249 | AEAD_AES_256_OCB_TAGLEN128 | AES-256 | 128 | 250 | AEAD_AES_256_OCB_TAGLEN96 | AES-256 | 96 | 251 | AEAD_AES_256_OCB_TAGLEN64 | AES-256 | 64 | 252 +----------------------------+-------------+--------+ 254 RFC 5116 defines an interface for authenticated encryption schemes 255 [RFC5116]. RFC 5116 requires the specification of certain constants 256 for each named AEAD scheme. For each of the OCB parameter sets 257 listed above: P_MAX, A_MAX, and C_MAX are all unbounded; N_MIN is 1 258 byte and N_MAX is 15 bytes. The parameter-sets indicating the use of 259 AES-128, AES-192 and AES-256 have K_LEN equal to 16, 24 and 32 bytes, 260 respectively. 262 Each ciphertext is longer than its corresponding plaintext by exactly 263 TAGLEN bits, and TAGLEN is given at the end of each name. For 264 instance, an AEAD_AES_128_OCB_TAGLEN64 ciphertext is exactly 64 bits 265 longer than its corresponding plaintext. 267 4. OCB Algorithms 269 OCB is described in this section using pseudocode. Given any 270 collection of inputs of the required types, following the pseudocode 271 description for a function will produce the correct output of the 272 promised type. 274 4.1. Associated-Data Processing: HASH 276 OCB has the ability to authenticate unencrypted associated data at 277 the same time that it provides for authentication and encrypts a 278 plaintext. The following hash function is central to providing this 279 functionality. If an application has no associated data, then the 280 associated data should be considered to exist and to be the empty 281 string. HASH, conveniently, always returns zeros(128) when the 282 associated data is the empty string. 284 Function name: 285 HASH 286 Input: 288 K, string of KEYLEN bits // Key 289 A, string of any length // Associated data 290 Output: 291 Sum, string of 128 bits // Hash result 293 Sum is defined as follows. 295 // 296 // Key-dependent variables 297 // 298 L_* = ENCIPHER(K, zeros(128)) 299 L_$ = double(L_*) 300 L_0 = double(L_$) 301 L_i = double(L_{i-1}) for every integer i > 0 303 // 304 // Consider A as a sequence of 128-bit blocks 305 // 306 Let m be the largest integer so that 128m <= bitlen(A) 307 Let A_1, A_2, ..., A_m and A_* be strings so that 308 A == A_1 || A_2 || ... || A_m || A_*, and 309 bitlen(A_i) == 128 for each 1 <= i <= m. 310 Note: A_* may possibly be the empty string. 312 // 313 // Process any whole blocks 314 // 315 Sum_0 = zeros(128) 316 Offset_0 = zeros(128) 317 for each 1 <= i <= m 318 Offset_i = Offset_{i-1} xor L_{ntz(i)} 319 Sum_i = Sum_{i-1} xor ENCIPHER(K, A_i xor Offset_i) 320 end for 322 // 323 // Process any final partial block; compute final hash value 324 // 325 if bitlen(A_*) > 0 then 326 Offset_* = Offset_m xor L_* 327 CipherInput = (A_* || 1 || zeros(127-bitlen(A_*))) xor Offset_* 328 Sum = Sum_m xor ENCIPHER(K, CipherInput) 329 else 330 Sum = Sum_m 331 end if 333 4.2. Encryption: OCB-ENCRYPT 334 This function computes a ciphertext (which includes a bundled 335 authentication tag) when given a plaintext, associated data, nonce 336 and key. For each invocation of OCB-ENCRYPT using the same key K, 337 the value of the nonce input N must be distinct. 339 Function name: 340 OCB-ENCRYPT 341 Input: 342 K, string of KEYLEN bits // Key 343 N, string of no more than 120 bits // Nonce 344 A, string of any length // Associated data 345 P, string of any length // Plaintext 346 Output: 347 C, string of length bitlen(P) + TAGLEN bits // Ciphertext 349 C is defined as follows. 351 // 352 // Key-dependent variables 353 // 354 L_* = ENCIPHER(K, zeros(128)) 355 L_$ = double(L_*) 356 L_0 = double(L_$) 357 L_i = double(L_{i-1}) for every integer i > 0 359 // 360 // Consider P as a sequence of 128-bit blocks 361 // 362 Let m be the largest integer so that 128m <= bitlen(P) 363 Let P_1, P_2, ..., P_m and P_* be strings so that 364 P == P_1 || P_2 || ... || P_m || P_*, and 365 bitlen(P_i) == 128 for each 1 <= i <= m. 366 Note: P_* may possibly be the empty string. 368 // 369 // Nonce-dependent and per-encryption variables 370 // 371 Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N 372 bottom = str2num(Nonce[123..128]) 373 Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6)) 374 Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72]) 375 Offset_0 = Stretch[1+bottom..128+bottom] 376 Checksum_0 = zeros(128) 378 // 379 // Process any whole blocks 380 // 381 for each 1 <= i <= m 382 Offset_i = Offset_{i-1} xor L_{ntz(i)} 383 C_i = Offset_i xor ENCIPHER(K, P_i xor Offset_i) 384 Checksum_i = Checksum_{i-1} xor P_i 385 end for 387 // 388 // Process any final partial block and compute raw tag 389 // 390 if bitlen(P_*) > 0 then 391 Offset_* = Offset_m xor L_* 392 Pad = ENCIPHER(K, Offset_*) 393 C_* = P_* xor Pad[1..bitlen(P_*)] 394 Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*))) 395 Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A) 396 else 397 C_* = 398 Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A) 399 end if 401 // 402 // Assemble ciphertext 403 // 404 C = C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] 406 4.3. Decryption: OCB-DECRYPT 408 This function computes a plaintext when given a ciphertext, 409 associated data, nonce and key. An authentication tag is embedded in 410 the ciphertext. If the tag is not correct for the ciphertext, 411 associated data, nonce and key, then an INVALID signal is produced. 413 Function name: 414 OCB-DECRYPT 415 Input: 416 K, string of KEYLEN bits // Key 417 N, string of no more than 120 bits // Nonce 418 A, string of any length // Associated data 419 C, string of at least TAGLEN bits // Ciphertext 420 Output: 421 P, string of length bitlen(C) - TAGLEN bits, // Plaintext 422 or INVALID indicating authentication failure 424 P is defined as follows. 426 // 427 // Key-dependent variables 428 // 429 L_* = ENCIPHER(K, zeros(128)) 430 L_$ = double(L_*) 431 L_0 = double(L_$) 432 L_i = double(L_{i-1}) for every integer i > 0 434 // 435 // Consider C as a sequence of 128-bit blocks 436 // 437 Let m be the largest integer so that 128m <= bitlen(C) - TAGLEN 438 Let C_1, C_2, ..., C_m, C_* and T be strings so that 439 C == C_1 || C_2 || ... || C_m || C_* || T, 440 bitlen(C_i) == 128 for each 1 <= i <= m, and 441 bitlen(T) == TAGLEN. 442 Note: C_* may possibly be the empty string. 444 // 445 // Nonce-dependent and per-decryption variables 446 // 447 Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N 448 bottom = str2num(Nonce[123..128]) 449 Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6)) 450 Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72]) 451 Offset_0 = Stretch[1+bottom..128+bottom] 452 Checksum_0 = zeros(128) 454 // 455 // Process any whole blocks 456 // 457 for each 1 <= i <= m 458 Offset_i = Offset_{i-1} xor L_{ntz(i)} 459 P_i = Offset_i xor DECIPHER(K, C_i xor Offset_i) 460 Checksum_i = Checksum_{i-1} xor P_i 461 end for 463 // 464 // Process any final partial block and compute raw tag 465 // 466 if bitlen(C_*) > 0 then 467 Offset_* = Offset_m xor L_* 468 Pad = ENCIPHER(K, Offset_*) 469 P_* = C_* xor Pad[1..bitlen(C_*)] 470 Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*))) 471 Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A) 472 else 473 P_* = 474 Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A) 475 end if 476 // 477 // Check for validity and assemble plaintext 478 // 479 if (Tag[1..TAGLEN] == T) then 480 P = P_1 || P_2 || ... || P_m || P_* 481 else 482 P = INVALID 483 end if 485 5. Security Considerations 487 OCB achieves two security properties, confidentiality and 488 authenticity. Confidentiality is defined via "indistinguishability 489 from random bits", meaning that an adversary is unable to distinguish 490 OCB-outputs from an equal number of random bits. Authenticity is 491 defined via "authenticity of ciphertexts", meaning that an adversary 492 is unable to produce any valid nonce-ciphertext pair that it has not 493 already acquired. The security guarantees depend on the underlying 494 blockcipher being secure in the sense of a strong pseudorandom 495 permutation. Thus if OCB is used with a blockcipher that is not 496 secure as a strong pseudorandom permutation, the security guarantees 497 vanish. The need for the strong pseudorandom permutation property 498 means that OCB should be used with a conservatively designed, well- 499 trusted blockcipher, such as AES. 501 Both the confidentiality and the authenticity properties of OCB 502 degrade as per s^2 / 2^128, where s is the total number of blocks 503 that the adversary acquires. The consequence of this formula is that 504 the proven security disappears when s becomes as large as 2^64. Thus 505 the user should never use a key to generate an amount of ciphertext 506 that is near to, or exceeds, 2^64 blocks. In order to ensure that 507 s^2 / 2^128 remains small, a given key should be used to encrypt at 508 most 2^48 blocks (2^55 bits or 4 petabytes), including the associated 509 data. To ensure these limits are not crossed, automated key 510 management is recommended in systems exchanging large amounts of data 511 [RFC4107]. 513 When a ciphertext decrypts as INVALID it is the implementor's 514 responsibility to make sure that no information beyond this fact is 515 made adversarially available. 517 OCB encryption and decryption produce an internal 128-bit 518 authentication tag. The parameter TAGLEN determines how many bits of 519 this internal tag are included in ciphertexts and used for 520 authentication. The value of TAGLEN has two impacts: An adversary 521 can trivially forge with probability 2^{-TAGLEN}, and ciphertexts are 522 TAGLEN bits longer than their corresponding plaintexts. It is up to 523 the application designer to choose an appropriate value for TAGLEN. 524 Long tags cost no more computationally than short ones. 526 Normally, a given key should be used to create ciphertexts with a 527 single tag length, TAGLEN, and an application should reject any 528 ciphertext that claims authenticity under the same key but a 529 different tag length. While the ciphertext core and all of the bits 530 of the tag do depend on the tag length, this is done for added 531 robustness to misuse and should not suggest that receivers accept 532 ciphertexts employing variable tag lengths under a single key. 534 Timing attacks are not a part of the formal security model and an 535 implementation should take care to mitigate them in contexts where 536 this is a concern. To render timing attacks impotent, the amount of 537 time to encrypt or decrypt a string should be independent of the key 538 and the contents of the string. The only explicitly conditional OCB 539 operation that depends on private data is double(), which means that 540 using constant-time blockcipher and double() implementations 541 eliminates most (if not all) sources of timing attacks on OCB. 542 Power-usage attacks are likewise out of scope of the formal model, 543 and should be considered for environments where they are threatening. 545 The OCB encryption scheme reveals in the ciphertext the length of the 546 plaintext. Sometimes the length of the plaintext is a valuable piece 547 of information that should be hidden. For environments where 548 "traffic analysis" is a concern, techniques beyond OCB encryption 549 (typically involving padding) would be necessary. 551 Defining the ciphertext that results from OCB-ENCRYPT to be the pair 552 (C_1 || C_2 || ... || C_m || C_*, Tag[1..TAGLEN]) instead of the 553 concatenation C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] 554 introduces no security concerns. Because TAGLEN is fixed, both 555 versions allow ciphertexts to be parsed unambiguously. 557 5.1. Nonce Requirements 559 It is crucial that, as one encrypts, one does not repeat a nonce. 560 The inadvertent reuse of the same nonce by two invocations of the OCB 561 encryption operation, with the same key, but with distinct plaintext 562 values, undermines the confidentiality of the plaintexts protected in 563 those two invocations, and undermines all of the authenticity and 564 integrity protection provided by that key. For this reason, OCB 565 should only be used whenever nonce uniqueness can be provided with 566 certainty. Note that it is acceptable to input the same nonce value 567 multiple times to the decryption operation. We emphasize that the 568 security consequences are quite serious if an attacker observes two 569 ciphertexts that were created using the same nonce and key values, 570 unless the plaintext and AD values in both invocations of the encrypt 571 operation were identical. First, a loss of confidentiality ensues 572 because the attacker will be able to infer relationships between the 573 two plaintext values. Second, a loss of authenticity ensues because 574 the attacker will be able to recover secret information used to 575 provide authenticity, making subsequent forgeries trivial. Note that 576 there are AEAD schemes, particularly SIV [RFC5297], appropriate for 577 environments where nonces are unavailable or unreliable. OCB is not 578 such a scheme. 580 Nonces need not be secret, and a counter may be used for them. If 581 two parties send OCB-encrypted plaintexts to one another using the 582 same key, then the space of nonces used by the two parties must be 583 partitioned so that no nonce that could be used by one party to 584 encrypt could be used by the other to encrypt (eg, odd and even 585 counters). 587 6. IANA Considerations 589 The Internet Assigned Numbers Authority (IANA) has defined a registry 590 for Authenticated Encryption with Associated Data parameters. The 591 IANA has added the following entries to the AEAD Registry. Each name 592 refers to a set of parameters defined in Section 3.1. 594 +----------------------------+-------------+--------------------+ 595 | Name | Reference | Numeric Identifier | 596 +----------------------------+-------------+--------------------+ 597 | AEAD_AES_128_OCB_TAGLEN128 | Section 3.1 | XX | 598 | AEAD_AES_128_OCB_TAGLEN96 | Section 3.1 | XX | 599 | AEAD_AES_128_OCB_TAGLEN64 | Section 3.1 | XX | 600 | AEAD_AES_192_OCB_TAGLEN128 | Section 3.1 | XX | 601 | AEAD_AES_192_OCB_TAGLEN96 | Section 3.1 | XX | 602 | AEAD_AES_192_OCB_TAGLEN64 | Section 3.1 | XX | 603 | AEAD_AES_256_OCB_TAGLEN128 | Section 3.1 | XX | 604 | AEAD_AES_256_OCB_TAGLEN96 | Section 3.1 | XX | 605 | AEAD_AES_256_OCB_TAGLEN64 | Section 3.1 | XX | 606 +----------------------------+-------------+--------------------+ 608 7. Acknowledgements 610 The design of the original OCB scheme [OCB1] was done while Rogaway 611 was at Chiang Mai University, Thailand. Follow-up work [OCB2] was 612 done with support of NSF grant 0208842 and a gift from Cisco. The 613 final work by Krovetz and Rogaway [OCB3] that has resulted in this 614 spec was supported by NSF grant 0904380. Thanks go to the many 615 members of the Crypto Forum Research Group (CFRG) who provided 616 feedback on earlier drafts. Thanks in particular go to David McGrew 617 for contributing some text and for managing the RFC approval process, 618 to James Manger for initiating a productive discussion on tag-length 619 dependency and for greatly improving Appendix A, to Matt Caswell and 620 Peter Dettman for writing implementations and verifying test vectors, 621 and to Stephen Farrell and Spencer Dawkins for their careful reading 622 and suggestions. 624 8. References 626 8.1. Normative References 628 [RFC5116] McGrew, D., "An interface and algorithms for authenticated 629 encryption", RFC 5116, January 2008. 631 [AES] National Institute of Standards and Technology, "Advanced 632 Encryption Standard (AES)", FIPS PUB 197, November 2001. 634 8.2. Informative References 636 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for cryptographic 637 key management", RFC 4107, June 2005. 639 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 640 authenticated encryption using the Advanced Encryption 641 Standard (AES)", RFC 5297, October 2008. 643 [OCB3] Krovetz, T. and P. Rogaway, "The software performance of 644 authenticated-encryption modes", in Fast Software 645 Encryption - FSE 2011, Springer, 2011. 647 [OCB2] Rogaway, P., "Efficient instantiations of tweakable 648 blockciphers and refinements to modes OCB and PMAC", in 649 Advances in Cryptology - ASIACRYPT 2004, Springer, 2004. 651 [OCB1] Rogaway, P., Bellare, M., Black, J., and T. Krovetz, "OCB: 652 a block-cipher mode of operation for efficient 653 authenticated encryption", in ACM Conference on Computer 654 and Communications Security 2001 - CCS 2001, ACM Press, 655 2001. 657 [OCB1ALT] Rogaway, P., Bellare, M., Black, J., and T. Krovetz, "OCB 658 Mode: proposal to NIST for a block-cipher mode of 659 operation which simultaneously provides privacy and 660 authenticity", at http://eprint.iacr.org/2001/026, IACR 661 ePrint Archive, 2001. 663 Appendix A. Sample Results 664 This section gives sample output values for various inputs when using 665 OCB with AES as per the parameters defined in Section 3.1. All 666 strings are represented in hexadecimal (eg, 0F represents the 667 bitstring 00001111). 669 The following 16 (N,A,P,C) tuples show the ciphertext C that results 670 from OCB-ENCRYPT(K,N,A,P) for various lengths of associated data (A) 671 and plaintext (P). The key (K) has a fixed value, the tag length is 672 128 bits, and the the nonce (N) increments. 674 K : 000102030405060708090A0B0C0D0E0F 676 An empty entry indicates the empty string. 678 N: BBAA99887766554433221100 679 A: 680 P: 681 C: 785407BFFFC8AD9EDCC5520AC9111EE6 683 N: BBAA99887766554433221101 684 A: 0001020304050607 685 P: 0001020304050607 686 C: 6820B3657B6F615A5725BDA0D3B4EB3A257C9AF1F8F03009 688 N: BBAA99887766554433221102 689 A: 0001020304050607 690 P: 691 C: 81017F8203F081277152FADE694A0A00 693 N: BBAA99887766554433221103 694 A: 695 P: 0001020304050607 696 C: 45DD69F8F5AAE72414054CD1F35D82760B2CD00D2F99BFA9 698 N: BBAA99887766554433221104 699 A: 000102030405060708090A0B0C0D0E0F 700 P: 000102030405060708090A0B0C0D0E0F 701 C: 571D535B60B277188BE5147170A9A22C3AD7A4FF3835B8C5 702 701C1CCEC8FC3358 704 N: BBAA99887766554433221105 705 A: 000102030405060708090A0B0C0D0E0F 706 P: 707 C: 8CF761B6902EF764462AD86498CA6B97 709 N: BBAA99887766554433221106 710 A: 712 P: 000102030405060708090A0B0C0D0E0F 713 C: 5CE88EC2E0692706A915C00AEB8B2396F40E1C743F52436B 714 DF06D8FA1ECA343D 716 N: BBAA99887766554433221107 717 A: 000102030405060708090A0B0C0D0E0F1011121314151617 718 P: 000102030405060708090A0B0C0D0E0F1011121314151617 719 C: 1CA2207308C87C010756104D8840CE1952F09673A448A122 720 C92C62241051F57356D7F3C90BB0E07F 722 N: BBAA99887766554433221108 723 A: 000102030405060708090A0B0C0D0E0F1011121314151617 724 P: 725 C: 6DC225A071FC1B9F7C69F93B0F1E10DE 727 N: BBAA99887766554433221109 728 A: 729 P: 000102030405060708090A0B0C0D0E0F1011121314151617 730 C: 221BD0DE7FA6FE993ECCD769460A0AF2D6CDED0C395B1C3C 731 E725F32494B9F914D85C0B1EB38357FF 733 N: BBAA9988776655443322110A 734 A: 000102030405060708090A0B0C0D0E0F1011121314151617 735 18191A1B1C1D1E1F 736 P: 000102030405060708090A0B0C0D0E0F1011121314151617 737 18191A1B1C1D1E1F 738 C: BD6F6C496201C69296C11EFD138A467ABD3C707924B964DE 739 AFFC40319AF5A48540FBBA186C5553C68AD9F592A79A4240 741 N: BBAA9988776655443322110B 742 A: 000102030405060708090A0B0C0D0E0F1011121314151617 743 18191A1B1C1D1E1F 744 P: 745 C: FE80690BEE8A485D11F32965BC9D2A32 747 N: BBAA9988776655443322110C 748 A: 749 P: 000102030405060708090A0B0C0D0E0F1011121314151617 750 18191A1B1C1D1E1F 751 C: 2942BFC773BDA23CABC6ACFD9BFD5835BD300F0973792EF4 752 6040C53F1432BCDFB5E1DDE3BC18A5F840B52E653444D5DF 754 N: BBAA9988776655443322110D 755 A: 000102030405060708090A0B0C0D0E0F1011121314151617 756 18191A1B1C1D1E1F2021222324252627 757 P: 000102030405060708090A0B0C0D0E0F1011121314151617 758 18191A1B1C1D1E1F2021222324252627 759 C: D5CA91748410C1751FF8A2F618255B68A0A12E093FF45460 760 6E59F9C1D0DDC54B65E8628E568BAD7AED07BA06A4A69483 761 A7035490C5769E60 763 N: BBAA9988776655443322110E 764 A: 000102030405060708090A0B0C0D0E0F1011121314151617 765 18191A1B1C1D1E1F2021222324252627 766 P: 767 C: C5CD9D1850C141E358649994EE701B68 769 N: BBAA9988776655443322110F 770 A: 771 P: 000102030405060708090A0B0C0D0E0F1011121314151617 772 18191A1B1C1D1E1F2021222324252627 773 C: 4412923493C57D5DE0D700F753CCE0D1D2D95060122E9F15 774 A5DDBFC5787E50B5CC55EE507BCB084E479AD363AC366B95 775 A98CA5F3000B1479 777 Next are several internal values generated during the OCB-ENCRYPT 778 computation for the last test vector listed above. 780 L_* : C6A13B37878F5B826F4F8162A1C8D879 781 L_$ : 8D42766F0F1EB704DE9F02C54391B075 782 L_0 : 1A84ECDE1E3D6E09BD3E058A8723606D 783 L_1 : 3509D9BC3C7ADC137A7C0B150E46C0DA 784 bottom : 15 (decimal) 785 Ktop : 9862B0FDEE4E2DD56DBA6433F0125AA2 786 Stretch : 9862B0FDEE4E2DD56DBA6433F0125AA2FAD24D13A063F8B8 787 Offset_0 : 587EF72716EAB6DD3219F8092D517D69 788 Offset_1 : 42FA1BF908D7D8D48F27FD83AA721D04 789 Offset_2 : 77F3C24534AD04C7F55BF696A434DDDE 790 Offset_* : B152F972B3225F459A1477F405FC05A7 791 Checksum_1: 000102030405060708090A0B0C0D0E0F 792 Checksum_2: 10101010101010101010101010101010 793 Checksum_*: 30313233343536379010101010101010 795 The next tuple shows a result with a tag length of 96 bits, and a 796 different key. 798 K: 0F0E0D0C0B0A09080706050403020100 800 N: BBAA9988776655443322110D 801 A: 000102030405060708090A0B0C0D0E0F1011121314151617 802 18191A1B1C1D1E1F2021222324252627 803 P: 000102030405060708090A0B0C0D0E0F1011121314151617 804 18191A1B1C1D1E1F2021222324252627 805 C: 1792A4E31E0755FB03E31B22116E6C2DDF9EFD6E33D536F1 806 A0124B0A55BAE884ED93481529C76B6AD0C515F4D1CDD4FD 807 AC4F02AA 809 The following algorithm tests a wider variety of inputs. Results are 810 given for each parameter set defined in Section 3.1. 812 K = zeros(KEYLEN-8) || num2str(TAGLEN,8) 813 C = 814 for i = 0 to 127 do 815 S = zeros(8i) 816 N = num2str(3i+1,96) 817 C = C || OCB-ENCRYPT(K,N,S,S) 818 N = num2str(3i+2,96) 819 C = C || OCB-ENCRYPT(K,N,,S) 820 N = num2str(3i+3,96) 821 C = C || OCB-ENCRYPT(K,N,S,) 822 end for 823 N = num2str(385,96) 824 Output : OCB-ENCRYPT(K,N,C,) 826 Iteration i of the loop adds 2i + (3 * TAGLEN / 8) bytes to C, 827 resulting in an ultimate length for C of 22,400 bytes when TAGLEN == 828 128, 20,864 bytes when TAGLEN == 192, and 19,328 bytes when TAGLEN == 829 64. The final OCB-ENCRYPT has an empty plaintext component, so 830 serves only to authenticate C. The output should be: 832 AEAD_AES_128_OCB_TAGLEN128 Output: 67E944D23256C5E0B6C61FA22FDF1EA2 833 AEAD_AES_192_OCB_TAGLEN128 Output: F673F2C3E7174AAE7BAE986CA9F29E17 834 AEAD_AES_256_OCB_TAGLEN128 Output: D90EB8E9C977C88B79DD793D7FFA161C 835 AEAD_AES_128_OCB_TAGLEN96 Output : 77A3D8E73589158D25D01209 836 AEAD_AES_192_OCB_TAGLEN96 Output : 05D56EAD2752C86BE6932C5E 837 AEAD_AES_256_OCB_TAGLEN96 Output : 5458359AC23B0CBA9E6330DD 838 AEAD_AES_128_OCB_TAGLEN64 Output : 192C9B7BD90BA06A 839 AEAD_AES_192_OCB_TAGLEN64 Output : 0066BC6E0EF34E24 840 AEAD_AES_256_OCB_TAGLEN64 Output : 7D4EA5D445501CBE 842 Authors' Addresses 843 Ted Krovetz 844 Computer Science Department 845 California State University 846 6000 J Street 847 Sacramento, CA 95819-6021 848 USA 850 Email: ted@krovetz.net 852 Phillip Rogaway 853 Computer Science Department 854 University of California 855 One Shields Avenue 856 Davis, CA 95616-8562 857 USA 859 Email: rogaway@cs.ucdavis.edu