OCB For Block Ciphers Without 128-Bit BlocksComputer Science DepartmentCalifornia State University6000 J StreetSacramentoCA95819-6021USAted@krovetz.net
Security
Internet Engineering Task ForceOCBAEADauthenticated-encryption
The OCB authenticated-encryption algorithm is specified in RFC 7523, but only for blockciphers with 128-bit blocks such as AES. This document extends RFC 7523 by specifying how OCB is used with blockciphers of any blocklength. When the blocklength is 128 bits, this specification and that in RFC 7523 are identical.
OCB is a shared-key, blockcipher-based authentication scheme specified in . It was designed with the AES blockcipher in mind and thus envisioned only being used with 128-bit blockciphers. The resulting RFC 7523 does not allow blockciphers with larger or smaller blocklengths. This document respecifies OCB in a more general manner, eliminating the expectation that a 128-bit blockcipher is used. This update is consistent with RFC 7523 and does not contradict it in any way. For applications using 128-bit blockciphers, RFC 7523 should be preferred because it is simpler, self-contained, and has more applicable test vectors.
Changing the blocklength used in OCB is not a simple matter. There are non-trivially defined constants used in OCB that must be recalculated for each different blocklength. What follows is largely a copy of the algorithms from RFC 7523, made more general by using blocklength-dependent symbolic constants.
The security of OCB continues to follow a birthday bound. Both the confidentiality and the authenticity properties of OCB degrade as per s^2 / 2^b, where s is the total number of blocks that the adversary acquires and b is the number of bits per blockcipher block. Note that this means security degrades rapidly when using a blockcipher with a small to moderate blocklength.
There are two types of variables used in this specification, strings and integers. Although strings processed by most implementations of OCB will be strings of bytes, bit-level operations are used throughout this specification document for defining OCB. String variables are always written with an initial upper-case letter while integer variables are written in all lower-case. Following C's convention, a single equals ("=") indicates variable assignment and double equals ("==") is the equality relation. Whenever a variable is followed by an underscore ("_"), the underscore is intended to denote a subscript, with the subscripted expression requiring evaluation to resolve the meaning of the variable. For example, when i == 2, then P_i refers to the variable P_2.
The integer c raised to the i-th power.The length of string S in bits (eg, bitlen(001) == 3).The string made of n zero-bits.The number of trailing zero bits in the base-2 representation of the positive integer n. More formally, ntz(n) is the largest integer x for which 2^x divides n.The string that is the bitwise exclusive-or of S and T. Strings S and T will always have the same length.The i-th bit of the string S (indices begin at 1, so if S is 011 then S[1] == 0, S[2] == 1, S[3] == 1).The substring of S consisting of bits i through j, inclusive.String S concatenated with string T (eg, 000 || 111 == 000111).The base-2 interpretation of bitstring S (eg, str2num(1110) == 14).The n-bit string whose base-2 interpretation is i (eg, num2str(14,4) == 1110 and num2str(1,2) == 01).If S[1] == 0 then double(S) == (S[2..bitlen(S)] || 0); otherwise double(S) == (S[2..bitlen(S)] || 0) xor num2str(RESIDUE,bitlen(S)) where RESIDUE is defined in or .
To be complete, the algorithms in this document require specification of two global parameters: a blockcipher and the length of authentication tags in use.
Specifying a blockcipher implicitly defines the following symbols.The blockcipher's blocklength, in bits.The blockcipher's key length, in bits.The blockcipher function mapping BLOCKLEN-bit plaintext block P to its corresponding ciphertext block using KEYLEN-bit key K.The inverse blockcipher function mapping BLOCKLEN-bit ciphertext block C to its corresponding plaintext block using KEYLEN-bit key K.
The TAGLEN parameter specifies the length of authentication tag used by OCB and may be any positive value up to, and including, the smaller of BLOCKLEN or 256.
As an example, if 128-bit authentication tags and AES with 192-bit keys are to be used, then BLOCKLEN is 128, KEYLEN is 192, ENCIPHER refers to the AES-192 cipher, DECIPHER refers to the AES-192 inverse cipher, and TAGLEN is 128.
Greater values for TAGLEN provide greater assurances of authenticity, but ciphertexts produced by OCB are longer than their corresponding plaintext by TAGLEN bits. See for details about TAGLEN and security.
Each value of BLOCKLEN gives rise to constants that need careful choosing to ensure OCB security and efficiency. The value RESIDUE is used in the definition of double given in , and the values SHIFT, MASKLEN, and TAGREP are used in the OCB-ENCRYPT and OCB-DECRYPT functions given in .
The following table lists these constants for a collection of blockcipher blocklengths. If a blocklength is needed that is not in the table, gives the criteria and algorithm used to determine the constants given here. The same criteria and algorithm should be used to generate other constants for other blocklengths.
Note that there are attacks on OCB with success proportional to a birthday bound related to BLOCKLEN. This means that using small values of BLOCKLEN may lead quickly to poor security. See for more information on the security bounds of OCB.
BLOCKLENRESIDUESHIFTMASKLENTAGREP32141174564272556961601336712813586719213540782561061188384410980885122931768876865537716098102452435535298160018435192108
OCB is described in this section using pseudocode. Given any collection of inputs of the required types, following the pseudocode description for a function will produce the correct output of the promised type.
OCB has the ability to authenticate unencrypted associated data at the same time that it provides for authentication and encrypts a plaintext. The following hash function is central to providing this functionality. If an application has no associated data, then the associated data should be considered to exist and to be the empty string. HASH, conveniently, always returns zeros(BLOCKLEN) when the associated data is the empty string.
This function computes a ciphertext (which includes a bundled authentication tag) when given a plaintext, associated data, nonce and key. For each invocation of OCB-ENCRYPT using the same key K, the value of the nonce input N must be distinct.
This function computes a plaintext when given a ciphertext, associated data, nonce and key. An authentication tag is embedded in the ciphertext. If the tag is not correct for the ciphertext, associated data, nonce and key, then an INVALID signal is produced.
What follows is a duplicate of the Security Considerations section of RFC 7523 with numeric literals replaced by their symbolic equivalents. With the ability to change BLOCKLEN comes two important additional considerations. The amount of data that can safely be processed using a single key is related to BLOCKLEN: a larger BLOCKLEN allows more data whereas a smaller BLOCKLEN allows less. Also, authentication tag lengths are limited to BLOCKLEN bits, which means that using OCB with a small BLOCKLEN forces the use of small tags. In all cases, but especially when reducing BLOCKLEN, a careful evaluation of an application's security requirements should be conducted and only if OCB, with a particular BLOCKLEN, meets those requirements should it be used.
OCB achieves two security properties, confidentiality and authenticity. Confidentiality is defined via "indistinguishability from random bits", meaning that an adversary is unable to distinguish OCB-outputs from an equal number of random bits. Authenticity is defined via "authenticity of ciphertexts", meaning that an adversary is unable to produce any valid nonce-ciphertext pair that it has not already acquired. The security guarantees depend on the underlying blockcipher being secure in the sense of a strong pseudorandom permutation. Thus if OCB is used with a blockcipher that is not secure as a strong pseudorandom permutation, the security guarantees vanish. The need for the strong pseudorandom permutation property means that OCB should be used with a conservatively designed, well-trusted blockcipher, such as AES.
Both the confidentiality and the authenticity properties of OCB degrade as per s^2 / 2^BLOCKLEN, where s is the total number of blocks that the adversary acquires. The consequence of this formula is that the proven security disappears when s becomes as large as 2^(BLOCKLEN/2). Thus the user should never use a key to generate an amount of ciphertext that is near to, or exceeds, 2^(BLOCKLEN/2) blocks. In order to ensure that s^2 / 2^BLOCKLEN remains less than about 1/2^32, a given key should be used to encrypt at most 2^(BLOCKLEN/2-16) blocks, including the associated data. To ensure these limits are not crossed, automated key management is recommended in systems exchanging large amounts of data .
When a ciphertext decrypts as INVALID it is the implementor's responsibility to make sure that no information beyond this fact is made adversarially available.
OCB encryption and decryption produce an internal BLOCKLEN-bit authentication tag. The parameter TAGLEN determines how many bits of this internal tag are included in ciphertexts and used for authentication. The value of TAGLEN has two impacts: An adversary can trivially forge with probability 2^{-TAGLEN}, and ciphertexts are TAGLEN bits longer than their corresponding plaintexts. It is up to the application designer to choose an appropriate value for TAGLEN. Long tags cost no more computationally than short ones.
Normally, a given key should be used to create ciphertexts with a single tag length, TAGLEN, and an application should reject any ciphertext that claims authenticity under the same key but a different tag length. While the ciphertext core and all of the bits of the tag do depend on the tag length, this is done for added robustness against misuse and should not suggest that receivers accept ciphertexts employing variable tag lengths under a single key.
Timing attacks are not a part of the formal security model and an implementation should take care to mitigate them in contexts where this is a concern. To render timing attacks impotent, the amount of time to encrypt or decrypt a string should be independent of the key and the contents of the string. The only explicitly conditional OCB operation that depends on private data is double(), which means that using constant-time blockcipher and double() implementations eliminates most (if not all) sources of timing attacks on OCB. Power-usage attacks are likewise out of scope of the formal model, and should be considered for environments where they are threatening.
The OCB encryption scheme reveals in the ciphertext the length of the plaintext. Sometimes the length of the plaintext is a valuable piece of information that should be hidden. For environments where "traffic analysis" is a concern, techniques beyond OCB encryption (typically involving padding) would be necessary.
Defining the ciphertext that results from OCB-ENCRYPT to be the pair (C_1 || C_2 || ... || C_m || C_*, Tag[1..TAGLEN]) instead of the concatenation C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] introduces no security concerns. Because TAGLEN is fixed, both versions allow ciphertexts to be parsed unambiguously.
It is crucial that, as one encrypts, one does not repeat a nonce. The inadvertent reuse of the same nonce by two invocations of the OCB encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key. For this reason, OCB should only be used whenever nonce uniqueness can be provided with certainty. Note that it is acceptable to input the same nonce value multiple times to the decryption operation. We emphasize that the security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key values, unless the plaintext and AD values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because the attacker will be able to infer relationships between the two plaintext values. Second, a loss of authenticity ensues because the attacker will be able to recover secret information used to provide authenticity, making subsequent forgeries trivial. Note that there are AEAD schemes, particularly SIV , appropriate for environments where nonces are unavailable or unreliable. OCB is not such a scheme.
Nonces need not be secret, and a counter may be used for them. If two parties send OCB-encrypted plaintexts to one another using the same key, then the space of nonces used by the two parties must be partitioned so that no nonce that could be used by one party to encrypt could be used by the other to encrypt (eg, odd and even counters).
The Internet Assigned Numbers Authority (IANA) has defined a registry for Authenticated Encryption with Associated Data parameters. This document does not specify any concrete AEAD schemes, so contributes nothing to the registry. Any AEAD scheme based on this document, where a permanently registered identifier would be useful, should register such identifier with IANA .
During a short period of 2017 three people inquired about extending OCB to
blockciphers with blocklengths other than 128-bits. Thanks go to Jeffrey Walton, Mark Wooding, and Uri Blumenthal for providing the motivation for this work. Mark Wooding has been especially helpful, providing the basis for the code in and corroborating test vectors by writing an independent implementation.
Table of low-weight binary irreducible polynomialsThe OCB authenticated-encryption algorithmThe software performance of authenticated-encryption modesThe RC6 block cipherRC6 and RC5 test vectors for multiple block sizesGuidelines for cryptographic key managementAn interface and algorithms for authenticated encryptionSynthetic Initialization Vector (SIV) authenticated encryption using the Advanced Encryption Standard (AES)SageMath, the Sage Mathematics Software System (Version 7.6)The Sage Developers
This section gives sample outputs for various inputs using OCB and blockciphers with blocklengths other than 128. In each case, an instance of RC6 is used for the blockcipher . The name RC6-w/r/b refers to RC6 with a 4w-bit blocklength, r internal rounds, and a b-byte key.
There are too many possible cases to consider for this section to be exhaustive. Instead a small number of examples are shown in detail with many significant variable assignments in the pseudocode shown. This will help an implementor find most basic errors. Further validation could then be accomplished by comparison with a reference implementation over a much more thorough selection of inputs.
Each of the following entries indicates the blockcipher and tag length used followed by the values K, N, A, P, C, indicating that plaintext P with associated data A when encrypted using OCB with key K, and nonce N, yields ciphertext C (which includes the tag). All strings are represented in hexadecimal (eg, 0F represents the bitstring 00001111). An empty entry indicates the empty string.
The following VALIDATE[B] algorithm tests a wider variety of inputs. Parameter B indicates that throughout the validation RC6-(B/4)/16/16 (ie, RC6 with B-bit blocklength, 16 rounds, and 16-byte keys) is the blockcipher used. Please note that when B is not a power of two, then the non-standard version of RC6 documented in is used. In all cases TAGLEN is min(B, 256).
Iteration i of the loop adds 2i + (3 * TAGLEN / 8) bytes to C, resulting in an ultimate length for C of 16256 + 48 * TAGLEN bytes. The final OCB-ENCRYPT has an empty plaintext component, so serves only to authenticate C. The output values should be:
OCB, as defined in and , uses several "magic numbers" when manipulating 128-bit blocks (135, 8, 6 and 7 for RESIDUE, SHIFT, MASKLEN and TAGREP). These constants are carefully chosen and depend on BLOCKLEN. A table in gives values for other assorted blocklengths and this section describes how to produce the values for more blocklengths if needed.
Finding MASKLEN and SHIFT for a particular BLOCKLEN begins by following the process described in Section 4.1 of . The result of that process is the domain size for every possible shift, 1 through BLOCKLEN-1, in the stretch-then-shift hash used internally by OCB. With that information, MASKLEN and SHIFT are determined as follows. Define MASKLEN as the floor of the base-2 logarithm of the largest domain size found. Keep as SHIFT candidates all shifts with domain sizes of at least 2^MASKLEN. These all provide equal security, but we want a shift that allows efficient implementation too. A shift equal to a large power-of-two would be ideal, but not all BLOCKLEN values produce candidate shifts with that property. Of all the shifts with domains of at least 2^MASKLEN, we continue to keep as candidates those shift values that are minimal modulo 8 (if this minima is equal to zero, then shifts can be performed using byte manipulations). Finally, we prefer shifts that are close to a large power-of-two, so of the remaining candidates, we choose for SHIFT one whose value modulo 8 and modulo 2^k is equal for the largest k, and if more than one has this property we settle on the smallest of those that do. The Sage script at the end of this section makes explicit this process and was run using SageMath 7.6 to generate all of the MASKLEN and SHIFT values given in . Its list of blocklengths can be edited and the script rerun to determine other MASKLEN and SHIFT values.
For the other two constants, TAGREP is defined as min(8, t) where t is the smallest integer making 2^t >= BLOCKLEN, and RESIDUE is extracted from . To determine a RESIDUE for BLOCKLEN, find the entry whose largest number is BLOCKLEN and let S be the set of numbers other than BLOCKLEN in this entry. Then, RESIDUE = 1 + sum({2^x | x in S}). For example, when BLOCKLEN is 122 we find the entry "122,6,2,1" making S == {6,2,1}. In this case RESIDUE == 1 + 2^6 + 2^2 + 2^1 == 71.