idnits 2.17.1 draft-krovetz-ocb-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'OCB1' on line 560 -- Looks like a reference, but probably isn't: 'OCB2' on line 562 -- Looks like a reference, but probably isn't: 'OCB3' on line 563 -- Looks like a reference, but probably isn't: 'AES' on line 205 -- Looks like a reference, but probably isn't: 'RFC5116' on line 222 -- Looks like a reference, but probably isn't: 'RFC4107' on line 472 -- Looks like a reference, but probably isn't: 'RFC5297' on line 491 == Unused Reference: '2' is defined on line 583, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 595, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Krovetz 3 Internet-Draft Sacramento State 4 Intended status: Informational P. Rogaway 5 Expires: January 15, 2013 UC Davis 6 July 16, 2012 8 The OCB Authenticated-Encryption Algorithm 9 draft-krovetz-ocb-04 11 Abstract 13 This document specifies OCB, a shared-key blockcipher-based 14 encryption scheme that provides privacy and authenticity for 15 plaintexts and authenticity for associated data. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 15, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Notation and Basic Operations . . . . . . . . . . . . . . . . 3 52 3. OCB Global Parameters . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Named OCB Parameter Sets and RFC 5116 Constants . . . . . 4 55 4. OCB Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Associated-Data Processing: HASH . . . . . . . . . . . . . 5 57 4.2. Encryption: OCB-ENCRYPT . . . . . . . . . . . . . . . . . 6 58 4.3. Decryption: OCB-DECRYPT . . . . . . . . . . . . . . . . . 9 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 65 Appendix A. Sample Results . . . . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 68 1. Introduction 70 Schemes for authenticated encryption (AE) simultaneously provide for 71 privacy and authentication. While this goal would traditionally be 72 achieved by melding separate encryption and authentication 73 mechanisms, each using its own key, integrated AE schemes intertwine 74 what is needed for privacy and what is needed for authenticity. By 75 conceptualizing AE as a single cryptographic goal, AE schemes are 76 less likely to be misused than conventional encryption schemes. 77 Also, integrated AE schemes can be significantly faster than what one 78 sees from composing separate privacy and authenticity means. 80 When an AE scheme allows for the authentication of unencrypted data 81 at the same time that a plaintext is being encrypted and 82 authenticated, the scheme is an authenticated encryption with 83 associated data (AEAD) scheme. Associated data can be useful when, 84 for example, a network packet has unencrypted routing information and 85 an encrypted payload. 87 OCB is an AEAD scheme that depends on a blockcipher. This document 88 fully defines OCB encryption and decryption except for the choice of 89 the blockcipher and the length of authentication tag that is part of 90 the ciphertext. The blockcipher must have a 128-bit blocksize. Each 91 choice of blockcipher and tag length specifies a different variant of 92 OCB. Several AES-based variants are defined in Section 3.1. 94 OCB encryption and decryption employ a nonce N, which must be 95 selected as a new value for each message encrypted. OCB requires the 96 associated data A to be specified when one encrypts or decrypts, but 97 it may be zero-length. The plaintext P and the associated data A can 98 have any bitlength. The ciphertext C one gets by encrypting P in the 99 presence of A consists of a ciphertext-core having the same length as 100 P, plus an authentication tag. One can view the resulting ciphertext 101 as either the pair (ciphertext-core, tag) or their concatenation 102 (ciphertext-core || tag), the difference being purely how one 103 assembles and parses ciphertexts. This document uses concatenation. 105 OCB encryption protects the privacy of P and the authenticity of A, 106 N, and P. It does this using, on average, about a + m + 1.02 107 blockcipher calls, where a is the blocklength of A and m is the 108 blocklength of P and the nonce N is implemented as a counter (if N is 109 random then OCB uses a + m + 2 blockcipher calls). If A is fixed 110 during a session then, after preprocessing, there is effectively no 111 cost to having A authenticated on subsequent encryptions, and the 112 mode will average m + 1.02 blockcipher calls. OCB requires a single 113 key K for the underlying blockcipher, and all blockcipher calls are 114 keyed by K. OCB is on-line: one need not know the length of A or P to 115 proceed with encryption, nor need one know the length of A or C to 116 proceed with decryption. OCB is parallelizable: the bulk of its 117 blockcipher calls can be performed simultaneously. Computational 118 work beyond blockcipher calls consists of a small and fixed number of 119 logical operations per call. OCB enjoys provable security: the mode 120 of operation is secure assuming that the underlying blockcipher is 121 secure. As with most modes of operation, security degrades in the 122 square of the number of blocks of texts divided by two to the 123 blocklength. 125 The version of OCB defined in this document is a refinement of two 126 prior schemes. The original OCB version was published in 2001 [OCB1] 127 and was listed as an optional component in IEEE 802.11i. A second 128 version was published in 2004 [OCB2] and is specified in ISO 19772. 129 The scheme described here is called OCB3 in the 2011 paper describing 130 the mode [OCB3]; it shall be referred to simply as OCB throughout 131 this document. See [OCB3] for complete references, timing 132 information, and a discussion of the differences between the 133 algorithms. 135 2. Notation and Basic Operations 137 There are two types of variables used in this specification, strings 138 and integers. Although most data processed by implementations of OCB 139 will be byte-oriented, a number of bit-level operations are used in 140 this specification, and so strings are here considered strings of 141 bits rather than strings of bytes. String variables are always 142 written with an initial upper-case letter while integer variables are 143 written in all lower-case. Following C's convention, a single equals 144 ("=") indicates variable assignment and double equals ("==") is the 145 equality relation. Whenever a variable is followed by an underscore 146 ("_"), the underscore is intended to denote a subscript, with the 147 subscripted expression requiring evaluation to resolve the meaning of 148 the variable. For example, when i == 2, then P_i refers to the 149 variable P_2. 151 c^i The integer c raised to the i-th power. 153 bitlen(S) The length of string S in bits (eg, bitlen(101) == 3). 155 zeros(n) The string made of n zero-bits. 157 ntz(n) The number of trailing zero bits in the base-2 158 representation of the positive integer n. More formally, 159 ntz(n) is the largest integer x for which 2^x divides n. 161 S xor T The string that is the bitwise exclusive-or of S and T. 162 Strings S and T will always have the same length. 164 S[i] The i-th bit of the string S (indices begin at 1). 166 S[i..j] The substring of S consisting of bits i through j, 167 inclusive. 169 S || T String S concatenated with string T (eg, 000 || 111 == 170 000111). 172 str2num(S) The base-2 integral interpretation of bitstring S (eg, 173 str2num(1110) == 14). 175 double(S) If S[1] == 0 then double(S) == (S[2..128] || 0); 176 otherwise double(S) == (S[2..128] || 0) xor (zeros(120) 177 || 10000111). 179 3. OCB Global Parameters 181 To be complete, the algorithms in this document require specification 182 of two global parameters: a blockcipher operating on 128-bit blocks 183 and the length of authentication tags in use. 185 Specifying a blockcipher implicitly defines the following symbols. 187 KEYLEN The blockcipher's key length, in bits. 189 ENCIPHER(K,P) The blockcipher function mapping 128-bit plaintext 190 block P to its corresponding ciphertext block using 191 KEYLEN-bit key K. 193 DECIPHER(K,C) The inverse blockcipher function mapping 128-bit 194 ciphertext block C to its corresponding plaintext 195 block using KEYLEN-bit key K. 197 As an example, if 128-bit authentication tags and AES with 192-bit 198 keys are to be used, then KEYLEN is 192, ENCIPHER refers to the 199 AES-192 cipher, DECIPHER refers to the AES-192 inverse cipher, and 200 TAGLEN is 128 [AES]. 202 3.1. Named OCB Parameter Sets and RFC 5116 Constants 204 The following table gives names to common OCB global parameter sets. 205 Each of the AES variants is defined in [AES]. 207 +----------------------------+-------------+--------+ 208 | Name | Blockcipher | TAGLEN | 209 +----------------------------+-------------+--------+ 210 | AEAD_AES_128_OCB_TAGLEN128 | AES-128 | 128 | 211 | AEAD_AES_128_OCB_TAGLEN96 | AES-128 | 96 | 212 | AEAD_AES_128_OCB_TAGLEN64 | AES-128 | 64 | 213 | AEAD_AES_192_OCB_TAGLEN128 | AES-192 | 128 | 214 | AEAD_AES_192_OCB_TAGLEN96 | AES-192 | 96 | 215 | AEAD_AES_192_OCB_TAGLEN64 | AES-192 | 64 | 216 | AEAD_AES_256_OCB_TAGLEN128 | AES-256 | 128 | 217 | AEAD_AES_256_OCB_TAGLEN96 | AES-256 | 96 | 218 | AEAD_AES_256_OCB_TAGLEN64 | AES-256 | 64 | 219 +----------------------------+-------------+--------+ 221 RFC 5116 defines an interface for authenticated encryption schemes 222 [RFC5116]. RFC 5116 requires the specification of certain constants 223 for each named AEAD scheme. For each of the OCB parameter sets 224 listed above: P_MAX, A_MAX, and C_MAX are all unbounded; N_MIN is 1 225 byte and N_MAX is 15 bytes. The parameter-sets indicating the use of 226 AES-128, AES-192 and AES-256 have K_LEN equal to 16, 24 and 32 bytes, 227 respectively. 229 4. OCB Algorithms 231 OCB is described in this section using pseudocode. Given any 232 collection of inputs of the required types, following the pseuduocode 233 description for a function will produce the correct output of the 234 promised type. 236 4.1. Associated-Data Processing: HASH 238 OCB has the ability to authenticate unencrypted associated data at 239 the same time that it provides for authentication and encrypts a 240 plaintext. The following hash function is central to providing this 241 functionality. If an application has no associated data, then the 242 associated data should be considered to exist and to be the empty 243 string. HASH, conveniently, always returns zeros(128) when the 244 associated data is the empty string. 246 Function name: 247 HASH 248 Input: 249 K, string of KEYLEN bits // Key 250 A, string of any length // Associated data 251 Output: 252 Sum, string of 128 bits // Hash result 254 Sum is defined as follows. 256 // 257 // Key-dependent variables 258 // 259 L_* = ENCIPHER(K, zeros(128)) 260 L_$ = double(L_*) 261 L_0 = double(L_$) 262 L_i = double(L_{i-1}) for every integer i > 0 264 // 265 // Consider A as a sequence of 128-bit blocks 266 // 267 Let m be the largest integer so that 128m <= bitlen(A) 268 Let A_1, A_2, ..., A_m and A_* be strings so that 269 A == A_1 || A_2 || ... || A_m || A_*, and 270 bitlen(A_i) == 128 for each 1 <= i <= m. 271 Note: A_* may possibly be the empty string. 273 // 274 // Process any whole blocks 275 // 276 Sum_0 = zeros(128) 277 Offset_0 = zeros(128) 278 for each 1 <= i <= m 279 Offset_i = Offset_{i-1} xor L_{ntz(i)} 280 Sum_i = Sum_{i-1} xor ENCIPHER(K, A_i xor Offset_i) 281 end for 283 // 284 // Process any final partial block; compute final hash value 285 // 286 if bitlen(A_*) > 0 then 287 Offset_* = Offset_m xor L_* 288 CipherInput = (A_* || 1 || zeros(127-bitlen(A_*))) xor Offset_* 289 Sum = Sum_m xor ENCIPHER(K, CipherInput) 290 else 291 Sum = Sum_m 292 end if 294 4.2. Encryption: OCB-ENCRYPT 295 This function computes a ciphertext (which includes a bundled 296 authentication tag) when given a plaintext, associated data, nonce 297 and key. 299 Function name: 300 OCB-ENCRYPT 301 Input: 302 K, string of KEYLEN bits // Key 303 N, string of fewer than 128 bits // Nonce 304 A, string of any length // Associated data 305 P, string of any length // Plaintext 306 Output: 307 C, string of length bitlen(P) + TAGLEN bits // Ciphertext 309 C is defined as follows. 311 // 312 // Key-dependent variables 313 // 314 L_* = ENCIPHER(K, zeros(128)) 315 L_$ = double(L_*) 316 L_0 = double(L_$) 317 L_i = double(L_{i-1}) for every integer i > 0 319 // 320 // Consider P as a sequence of 128-bit blocks 321 // 322 Let m be the largest integer so that 128m <= bitlen(P) 323 Let P_1, P_2, ..., P_m and P_* be strings so that 324 P == P_1 || P_2 || ... || P_m || P_*, and 325 bitlen(P_i) == 128 for each 1 <= i <= m. 326 Note: P_* may possibly be the empty string. 328 // 329 // Nonce-dependent and per-encryption variables 330 // 331 Nonce = zeros(127-bitlen(N)) || 1 || N 332 bottom = str2num(Nonce[123..128]) 333 Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6)) 334 Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72]) 335 Offset_0 = Stretch[1+bottom..128+bottom] 336 Checksum_0 = zeros(128) 338 // 339 // Process any whole blocks 340 // 341 for each 1 <= i <= m 342 Offset_i = Offset_{i-1} xor L_{ntz(i)} 343 C_i = Offset_i xor ENCIPHER(K, P_i xor Offset_i) 344 Checksum_i = Checksum_{i-1} xor P_i 345 end for 347 // 348 // Process any final partial block and compute raw tag 349 // 350 if bitlen(P_*) > 0 then 351 Offset_* = Offset_m xor L_* 352 Pad = ENCIPHER(K, Offset_*) 353 C_* = P_* xor Pad[1..bitlen(P_*)] 354 Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*))) 355 Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A) 356 else 357 C_* = 358 Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A) 359 end if 361 // 362 // Assemble ciphertext 363 // 364 C = C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] 366 4.3. Decryption: OCB-DECRYPT 368 This function computes a plaintext when given a ciphertext, 369 associated data, nonce and key. An authentication tag is embedded in 370 the ciphertext. If the tag is not correct for the ciphertext, 371 associated data, nonce and key, then an INVALID signal is produced. 373 Function name: 374 OCB-DECRYPT 375 Input: 376 K, string of KEYLEN bits // Key 377 N, string of fewer than 128 bits // Nonce 378 A, string of any length // Associated data 379 C, string of at least TAGLEN bits // Ciphertext 380 Output: 381 P, string of length bitlen(C) - TAGLEN bits, // Plaintext 382 or INVALID indicating authentication failure 384 P is defined as follows. 386 // 387 // Key-dependent variables 388 // 389 L_* = ENCIPHER(K, zeros(128)) 390 L_$ = double(L_*) 391 L_0 = double(L_$) 392 L_i = double(L_{i-1}) for every integer i > 0 394 // 395 // Consider C as a sequence of 128-bit blocks 396 // 397 Let m be the largest integer so that 128m <= bitlen(C) - TAGLEN 398 Let C_1, C_2, ..., C_m, C_* and T be strings so that 399 C == C_1 || C_2 || ... || C_m || C_* || T, 400 bitlen(C_i) == 128 for each 1 <= i <= m, and 401 bitlen(T) == TAGLEN. 402 Note: C_* may possibly be the empty string. 404 // 405 // Nonce-dependent and per-decryption variables 406 // 407 Nonce = zeros(127-bitlen(N)) || 1 || N 408 bottom = str2num(Nonce[123..128]) 409 Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6)) 410 Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72]) 411 Offset_0 = Stretch[1+bottom..128+bottom] 412 Checksum_0 = zeros(128) 414 // 415 // Process any whole blocks 416 // 417 for each 1 <= i <= m 418 Offset_i = Offset_{i-1} xor L_{ntz(i)} 419 P_i = Offset_i xor DECIPHER(K, C_i xor Offset_i) 420 Checksum_i = Checksum_{i-1} xor P_i 421 end for 423 // 424 // Process any final partial block and compute raw tag 425 // 426 if bitlen(C_*) > 0 then 427 Offset_* = Offset_m xor L_* 428 Pad = ENCIPHER(K, Offset_*) 429 P_* = C_* xor Pad[1..bitlen(C_*)] 430 Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*))) 431 Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A) 432 else 433 P_* = 434 Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A) 435 end if 437 // 438 // Check for validity and assemble plaintext 439 // 440 if (Tag[1..TAGLEN] == T) then 441 P = P_1 || P_2 || ... || P_m || P_* 442 else 443 P = INVALID 444 end if 446 5. Security Considerations 448 OCB achieves two security properties, privacy and authenticity. 449 Privacy is defined via "indistinguishability from random bits", 450 meaning that an adversary is unable to distinguish OCB-outputs from 451 an equal number of random bits. Authenticity is defined via 452 "authenticity of ciphertexts", meaning that an adversary is unable to 453 produce any valid (N,C,T) triple that it has not already acquired. 454 The security guarantees depend on the underlying blockcipher being 455 secure in the sense of a strong pseudorandom permutation. Thus if 456 OCB is used with a blockcipher that is not secure as a strong 457 pseudorandom permutation, the security guarantees vanish. The need 458 for the strong pseudorandom permutation property means that OCB 459 should be used with a conservatively designed, well-trusted 460 blockcipher, such as AES. 462 Both the privacy and the authenticity properties of OCB degrade as 463 per s^2 / 2^128, where s is the total number of blocks that the 464 adversary acquires. The consequence of this formula is that the 465 proven security vanishes when s becomes as large as 2^{128/2}. Thus 466 the user should never use a key to generate an amount of ciphertext 467 that is near to, or exceeds, 2^64 blocks. In order to ensure that 468 s^2 / 2^128 remains small, a given key should be used to encrypt at 469 most 2^48 blocks (2^55 bits or 4 petabytes), including the associated 470 data. To ensure these limits are not crossed, automated key 471 management is recommended in systems exchanging large amounts of data 472 [RFC4107]. 474 It is crucial that, as one encrypts, one does not repeat a nonce. 475 The inadvertent reuse of the same nonce by two invocations of the OCB 476 encryption operation, with the same key, but with distinct plaintext 477 values, undermines the confidentiality of the plaintexts protected in 478 those two invocations, and undermines all of the authenticity and 479 integrity protection provided by that key. For this reason, OCB 480 should only be used whenever nonce uniqueness can be provided with 481 certainty. Note that it is acceptable to input the same nonce value 482 multiple times to the decryption operation. We emphasize that the 483 security consequences are quite serious if an attacker observes two 484 ciphertexts that were created using the same nonce and key values, 485 unless the plaintext and AD values in both invocations of the encrypt 486 operation were identical. First, a loss of confidentiality ensues 487 because he will be able to infer relationships between the two 488 plaintext values. Second, a loss of authenticity ensues because the 489 attacker will be able to recover secret information used to provide 490 authenticity, making subsequent forgeries trivial. Note that there 491 are AEAD schemes, particularly SIV [RFC5297], appropriate for 492 environements where nonces are unavailable or unreliable. OCB is not 493 such a scheme. 495 Nonces need not be secret, and a counter may be used for them. If 496 two parties send OCB-encrypted plaintexts to one another using the 497 same key, then the space of nonces used by the two parties must be 498 partitioned so that no nonce that could be used by one party to 499 encrypt could be used by the other to encrypt (eg, odd and even 500 counters). 502 When a ciphertext decrypts as INVALID it is the implementor's 503 responsibility to make sure that no information beyond this fact is 504 made adversarially available. 506 OCB encryption and decryption produce an internal 128-bit 507 authentication tag. The parameter TAGLEN determines how many bits of 508 this internal tag are used for authentication. The value of TAGLEN 509 impacts the adversary's ability to forge: it will always be trivial 510 for the adversary to forge with probability 2^{-TAGLEN}. It is up to 511 the application designer to choose an appropriate value for TAGLEN. 512 Long tags cost no more computationally than short ones. 514 Timing attacks are not a part of the formal security model and an 515 implementation should take care to mitigate them in contexts where 516 this is a concern. To render timing attacks impotent, the amount of 517 time to encrypt or decrypt a string should be independent of the key 518 and the contents of the string. The only explicitly conditional OCB 519 operation that depends on private data is double(), which means that 520 using constant-time blockcipher and double() implementations 521 eliminates most (if not all) sources of timing attacks on OCB. Power- 522 usage attacks are likewise out of scope of the formal model, and 523 should be considered for environments where they are threatening. 525 The OCB encryption scheme reveals in the ciphertext the length of the 526 plaintext. Sometimes the length of the plaintext is a valuable piece 527 of information that should be hidden. For environments where 528 "traffic analysis" is a concern, techniques beyond OCB encryption 529 (typically involving padding) would be necessary. 531 Defining the ciphertext that results from OCB-ENCRYPT to be the pair 532 (C_1 || C_2 || ... || C_m || C_*, Tag[1..TAGLEN]) instead of the 533 concatenation C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] 534 introduces no security concerns. Because TAGLEN is fixed, both 535 versions allows ciphertexts to be parsed unambiguously. 537 6. IANA Considerations 539 The Internet Assigned Numbers Authority (IANA) has defined a registry 540 for Authenticated Encryption with Associated Data parameters. The 541 IANA has added the following entries to the AEAD Registry. Each name 542 refers to a set of parameters defined in Section 3.1. 544 +----------------------------+-------------+--------------------+ 545 | Name | Reference | Numeric Identifier | 546 +----------------------------+-------------+--------------------+ 547 | AEAD_AES_128_OCB_TAGLEN128 | Section 3.1 | XX | 548 | AEAD_AES_128_OCB_TAGLEN96 | Section 3.1 | XX | 549 | AEAD_AES_128_OCB_TAGLEN64 | Section 3.1 | XX | 550 | AEAD_AES_192_OCB_TAGLEN128 | Section 3.1 | XX | 551 | AEAD_AES_192_OCB_TAGLEN96 | Section 3.1 | XX | 552 | AEAD_AES_192_OCB_TAGLEN64 | Section 3.1 | XX | 553 | AEAD_AES_256_OCB_TAGLEN128 | Section 3.1 | XX | 554 | AEAD_AES_256_OCB_TAGLEN96 | Section 3.1 | XX | 555 | AEAD_AES_256_OCB_TAGLEN64 | Section 3.1 | XX | 556 +----------------------------+-------------+--------------------+ 558 7. Acknowledgements 560 The design of the original OCB scheme [OCB1] was done while Phil 561 Rogaway was at Chiang Mai University, Thailand. Follow-up work 562 [OCB2] was done with support of NSF grant 0208842 and a gift from 563 Cisco. The final work by Krovetz and Rogaway [OCB3] that has 564 resulted in this spec was supported by NSF grant 0904380. Thanks go 565 to the Crypto Forum Research Group for providing feedback on earlier 566 drafts, and David McGrew for contributing some text in Section 5. 568 8. References 570 8.1. Normative References 572 [1] McGrew, D., "An interface and algorithms for authenticated 573 encryption", RFC 5116, January 2008. 575 [2] National Institute of Standards and Technology, "Advanced 576 Encryption Standard (AES)", FIPS PUB 197, November 2001. 578 8.2. Informative References 580 [1] Bellovin, S. and R. Housley, "Guidelines for cryptographic 581 key management", RFC 4107, June 2005. 583 [2] Harkins, D., "Synthetic Initialization Vector (SIV) 584 authenticated encryption using the Advanced Encryption 585 Standard (AES)", RFC 5297, October 2008. 587 [3] Krovetz, T. and P. Rogaway, "The software performance of 588 authenticated-encryption modes", in Fast Software 589 Encryption - FSE 2011, Springer, 2011. 591 [4] Rogaway, P., "Efficient instantiations of tweakable 592 blockciphers and refinements to modes OCB and PMAC", in 593 Advances in Cryptology - ASIACRYPT 2004, Springer, 2004. 595 [5] Rogaway, P., Bellare, M., Black, J. and T. Krovetz, "OCB: 596 a block-cipher mode of operation for efficient 597 authenticated encryption", in ACM Conference on Computer 598 and Communications Security 2001 - CCS 2001, ACM Press, 599 2001. 601 Appendix A. Sample Results 603 This section gives sample output values for various inputs when using 604 the AEAD_AES_128_OCB_TAGLEN128 parameters defined in Section 3.1. All 605 strings are represented in hexadecimal (eg, 0F represents the 606 bitstring 00001111). 608 Each of the following (A,P,C) triples show the ciphertext C that 609 results from OCB-ENCRYPT(K,N,A,P) when K and N are fixed with the 610 values 612 K : 000102030405060708090A0B0C0D0E0F 613 N : 000102030405060708090A0B 615 An empty entry indicates the empty string. 617 A: 618 P: 619 C: 197B9C3C441D3C83EAFB2BEF633B9182 621 A: 0001020304050607 622 P: 0001020304050607 623 C: 92B657130A74B85A16DC76A46D47E1EAD537209E8A96D14E 625 A: 0001020304050607 626 P: 627 C: 98B91552C8C009185044E30A6EB2FE21 629 A: 630 P: 0001020304050607 631 C: 92B657130A74B85A971EFFCAE19AD4716F88E87B871FBEED 633 A: 000102030405060708090A0B0C0D0E0F 634 P: 000102030405060708090A0B0C0D0E0F 635 C: BEA5E8798DBE7110031C144DA0B26122776C9924D6723A1F 636 C4524532AC3E5BEB 638 A: 000102030405060708090A0B0C0D0E0F 639 P: 640 C: 7DDB8E6CEA6814866212509619B19CC6 642 A: 643 P: 000102030405060708090A0B0C0D0E0F 644 C: BEA5E8798DBE7110031C144DA0B2612213CC8B747807121A 645 4CBB3E4BD6B456AF 647 A: 000102030405060708090A0B0C0D0E0F1011121314151617 648 P: 000102030405060708090A0B0C0D0E0F1011121314151617 649 C: BEA5E8798DBE7110031C144DA0B26122FCFCEE7A2A8D4D48 650 5FA94FC3F38820F1DC3F3D1FD4E55E1C 652 A: 000102030405060708090A0B0C0D0E0F1011121314151617 653 P: 654 C: 282026DA3068BC9FA118681D559F10F6 656 A: 657 P: 000102030405060708090A0B0C0D0E0F1011121314151617 658 C: BEA5E8798DBE7110031C144DA0B26122FCFCEE7A2A8D4D48 659 6EF2F52587FDA0ED97DC7EEDE241DF68 661 A: 000102030405060708090A0B0C0D0E0F1011121314151617 662 18191A1B1C1D1E1F 663 P: 000102030405060708090A0B0C0D0E0F1011121314151617 664 18191A1B1C1D1E1F 665 C: BEA5E8798DBE7110031C144DA0B26122CEAAB9B05DF771A6 666 57149D53773463CBB2A040DD3BD5164372D76D7BB6824240 668 A: 000102030405060708090A0B0C0D0E0F1011121314151617 669 18191A1B1C1D1E1F 671 P: 672 C: E1E072633BADE51A60E85951D9C42A1B 674 A: 675 P: 000102030405060708090A0B0C0D0E0F1011121314151617 676 18191A1B1C1D1E1F 677 C: BEA5E8798DBE7110031C144DA0B26122CEAAB9B05DF771A6 678 57149D53773463CB4A3BAE824465CFDAF8C41FC50C7DF9D9 680 A: 000102030405060708090A0B0C0D0E0F1011121314151617 681 18191A1B1C1D1E1F2021222324252627 682 P: 000102030405060708090A0B0C0D0E0F1011121314151617 683 18191A1B1C1D1E1F2021222324252627 684 C: BEA5E8798DBE7110031C144DA0B26122CEAAB9B05DF771A6 685 57149D53773463CB68C65778B058A635659C623211DEEA0D 686 E30D2C381879F4C8 688 A: 000102030405060708090A0B0C0D0E0F1011121314151617 689 18191A1B1C1D1E1F2021222324252627 690 P: 691 C: 7AEB7A69A1687DD082CA27B0D9A37096 693 A: 694 P: 000102030405060708090A0B0C0D0E0F1011121314151617 695 18191A1B1C1D1E1F2021222324252627 696 C: BEA5E8798DBE7110031C144DA0B26122CEAAB9B05DF771A6 697 57149D53773463CB68C65778B058A635060C8467F4ABAB5E 698 8B3C2067A2E115DC 700 Next are several internal values generated during the OCB-ENCRYPT 701 computation for the last test vector listed above. 703 bottom : 11 704 Checksum_1: 000102030405060708090A0B0C0D0E0F 705 Checksum_2: 10101010101010101010101010101010 706 Checksum_*: 30313233343536379010101010101010 707 Ktop : 43E111498C0582BF99F1D966CEFCBCC6 708 L_* : C6A13B37878F5B826F4F8162A1C8D879 709 L_$ : 8D42766F0F1EB704DE9F02C54391B075 710 L_0 : 1A84ECDE1E3D6E09BD3E058A8723606D 711 L_1 : 3509D9BC3C7ADC137A7C0B150E46C0DA 712 Offset_0 : 088A4C602C15FCCF8ECB3677E5E63517 713 Offset_1 : 120EA0BE322892C633F533FD62C5557A 714 Offset_2 : 270779020E524ED5498938E86C8395A0 715 Offset_* : E1A6423589DD155726C6B98ACD4B4DD9 716 Stretch : 43E111498C0582BF99F1D966CEFCBCC6A2F058C589873D26 718 The following algorithm tests a wider variety of inputs. Results are 719 given for each of AEAD_AES_128_OCB_TAGLEN128, 720 AEAD_AES_192_OCB_TAGLEN128 and AEAD_AES_256_OCB_TAGLEN128. Let be 721 the 8-bit base-2 representation of i (eg, <3> == 00000011 and <255> 722 == 11111111). 724 K = zeros(KEYLEN) // Keylength of AES in use 725 for i = 0 to 127 do 726 S = zeros(8i) // i bytes of zeros 727 N = zeros(88) || // 11 byte zero followed by 1 byte i 728 C = C || OCB-ENCRYPT(K,N,S,S) 729 C = C || OCB-ENCRYPT(K,N,,S) 730 C = C || OCB-ENCRYPT(K,N,S,) 731 end for 732 N = zeros(96) 733 Output : OCB-ENCRYPT(K,N,C,) 735 Iteration i of the loop adds 2i + 48 bytes to C, resulting in an 736 ultimate length for C of 22,400 bytes. The final OCB-ENCRYPT has an 737 empty plaintext component, so serves only to authenticate C. The 738 output should be: 740 AEAD_AES_128_OCB_TAGLEN128 Output: B2B41CBF9B05037DA7F16C24A35C1C94 741 AEAD_AES_192_OCB_TAGLEN128 Output: 1529F894659D2B51B776740211E7D083 742 AEAD_AES_256_OCB_TAGLEN128 Output: 42B83106E473C0EEE086C8D631FD4C7B 744 Authors' Addresses 746 Ted Krovetz 747 Computer Science Department 748 California State University 749 6000 J Street 750 Sacramento, CA 95819-6021 751 USA 753 Email: ted@krovetz.net 755 Phillip Rogaway 756 Computer Science Department 757 University of California 758 One Shields Avenue 759 Davis, CA 95616-8562 760 USA 762 Email: rogaway@cs.ucdavis.edu