The OCB Authenticated-Encryption AlgorithmComputer Science DepartmentCalifornia State University, Sacramento6000 J StreetSacramentoCA95819-6021USAted@krovetz.netComputer Science DepartmentUniversity of California, DavisOne Shields AvenueDavisCA95616-8562USArogaway@cs.ucdavis.edu
Security
Crypto ForumOCBAEADauthenticated-encryption
This document specifies OCB, a shared-key blockcipher-based
encryption scheme that provides confidentiality and authenticity for
plaintexts and authenticity for associated data. This document is a product of
the Crypto Forum Research Group (CFRG).
Schemes for authenticated encryption (AE) simultaneously provide for confidentiality and authentication. While this goal would traditionally be achieved by melding separate encryption and authentication mechanisms, each using its own key, integrated AE schemes intertwine what is needed for confidentiality and what is needed for authenticity. By conceptualizing AE as a single cryptographic goal, AE schemes are less likely to be misused than conventional encryption schemes. Also, integrated AE schemes can be significantly faster than what one sees from composing separate confidentiality and authenticity means.
When an AE scheme allows for the authentication of unencrypted data at the same time that a plaintext is being encrypted and authenticated, the scheme is an authenticated encryption with associated data (AEAD) scheme. Associated data can be useful when, for example, a network packet has unencrypted routing information and an encrypted payload.
OCB is an AEAD scheme that depends on a blockcipher. This document fully defines OCB encryption and decryption except for the choice of the blockcipher and the length of authentication tag that is part of the ciphertext. The blockcipher must have a 128-bit blocksize. Each choice of blockcipher and tag length specifies a different variant of OCB. Several AES-based variants are defined in .
OCB encryption and decryption employ a nonce N, which must be distinct for
each invocation of the OCB encryption operation. OCB requires the associated data A to be specified when one encrypts or decrypts, but it may be zero-length. The plaintext P and the associated data A can have any bitlength. The ciphertext C one gets by encrypting P in the presence of A consists of a ciphertext-core having the same length as P, plus an authentication tag. One can view the resulting ciphertext as either the pair (ciphertext-core, tag) or their concatenation (ciphertext-core || tag), the difference being purely how one assembles and parses ciphertexts. This document uses concatenation.
OCB encryption protects the confidentiality of P and the authenticity of A, N,
and P. It does this using, on average, about a + m + 1.02 blockcipher calls,
where a is the blocklength of A, m is the blocklength of P, and the nonce N is
implemented as a counter (if N is random, then OCB uses a + m + 2 blockcipher
calls). If A is fixed during a session, then, after preprocessing, there is
effectively no cost to having A authenticated on subsequent encryptions, and
the mode will average m + 1.02 blockcipher calls. OCB requires a single key K
for the underlying blockcipher, and all blockcipher calls are keyed by K. OCB
is online. In particular, one need not know the length of A or P to proceed
with encryption, nor need one know the length of A or C to proceed with
decryption. OCB is parallelizable: the bulk of its blockcipher calls can be
performed simultaneously. Computational work beyond blockcipher calls consists
of a small and fixed number of logical operations per call. OCB enjoys
provable security: the mode of operation is secure assuming that the
underlying blockcipher is secure. As with most modes of operation, security
degrades as the number of blocks processed gets large (see for details).
For reasons of generality, OCB is defined to operate on arbitrary bitstrings. But for reasons of simplicity and efficiency, most implementations will assume that strings operated on are bytestrings (i.e., strings that are a multiple of 8 bits). To promote interoperability, implementations of OCB that communicate with implementations of unknown capabilities should restrict all provided values (nonces, tags, plaintexts, ciphertexts, and associated data) to bytestrings.
The version of OCB defined in this document is a refinement of two prior schemes. The original OCB version was published in 2001 and was listed as an optional component in IEEE 802.11i. A second version was published in 2004 and is specified in ISO 19772. The scheme described here is called OCB3 in the 2011 paper describing the mode ; it shall be referred to simply as OCB throughout this document. The only difference between the algorithm of this RFC and that of the paper is that the tag length is now encoded into the internally formatted nonce. See for complete references, timing information, and a discussion of the differences between the algorithms. OCB was initially the acronym for Offset Codebook but is now the algorithm's full name.
OCB has received years of in-depth analysis previous to its submission to the CFRG and has been under review by the members of the CFRG for over a year. It is the consensus of the CFRG that the security mechanisms provided by the OCB AEAD algorithm described in this document are suitable for use in providing confidentiality and authentication.
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 uppercase letter while integer variables are written in all lowercase. 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 (e.g., bitlen(101) == 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 (e.g., 000 || 111 == 000111).The base-2 interpretation of bitstring S (e.g., str2num(1110) == 14).The n-bit string whose base-2 interpretation is i (e.g., num2str(14,4) == 1110 and num2str(1,2) == 01).If S[1] == 0, then double(S) == (S[2..128] || 0); otherwise, double(S) == (S[2..128] || 0) xor (zeros(120) || 10000111).
To be complete, the algorithms in this document require specification of two global parameters: a blockcipher operating on 128-bit blocks and the length of authentication tags in use.
Specifying a blockcipher implicitly defines the following symbols.The blockcipher's key length in bits.The blockcipher function mapping 128-bit plaintext block P to its corresponding ciphertext block using KEYLEN-bit key K.The inverse blockcipher function mapping 128-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 value up to 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.
As an example, if 128-bit authentication tags and AES with 192-bit keys are to be used, then KEYLEN is 192, ENCIPHER refers to the AES-192 cipher, DECIPHER refers to the AES-192 inverse cipher, and TAGLEN is 128 .
The following table gives names to common OCB global parameter sets. Each of the AES variants is defined in .
NameBlockcipherTAGLENAEAD_AES_128_OCB_TAGLEN128AES-128128AEAD_AES_128_OCB_TAGLEN96AES-12896AEAD_AES_128_OCB_TAGLEN64AES-12864AEAD_AES_192_OCB_TAGLEN128AES-192128AEAD_AES_192_OCB_TAGLEN96AES-19296AEAD_AES_192_OCB_TAGLEN64AES-19264AEAD_AES_256_OCB_TAGLEN128AES-256128AEAD_AES_256_OCB_TAGLEN96AES-25696AEAD_AES_256_OCB_TAGLEN64AES-25664
RFC 5116 defines an interface for authenticated-encryption schemes . RFC 5116 requires the specification of certain constants
for each named AEAD scheme. For each of the OCB parameter sets listed above:
P_MAX, A_MAX, and C_MAX are all unbounded; N_MIN is 1 byte, and N_MAX is 15
bytes. The parameter sets indicating the use of AES-128, AES-192, and AES-256
have K_LEN equal to 16, 24, and 32 bytes, respectively.
Each ciphertext is longer than its corresponding plaintext by exactly TAGLEN bits, and TAGLEN is given at the end of each name. For instance, an AEAD_AES_128_OCB_TAGLEN64 ciphertext is exactly 64 bits longer than its corresponding plaintext.
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(128) 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.
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^128, 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^64. Thus, the user should never use a key to generate an amount of ciphertext that is near to, or exceeds, 2^64 blocks. In order to ensure that s^2 / 2^128 remains small, a given key should be used to encrypt at most 2^48 blocks (2^55 bits or 4 petabytes), 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 128-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 to 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 the 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 associated data 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 the Synthetic
Initialization Vector (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 (e.g., odd and even counters).
The Internet Assigned Numbers Authority (IANA) has defined a registry for
Authenticated Encryption with Associated Data parameters. The IANA has added
the following entries to the AEAD Registry. Each name refers to a set of
parameters defined in .
NameReferenceNumeric IDAEAD_AES_128_OCB_TAGLEN12820AEAD_AES_128_OCB_TAGLEN9621AEAD_AES_128_OCB_TAGLEN6422AEAD_AES_192_OCB_TAGLEN12823AEAD_AES_192_OCB_TAGLEN9624AEAD_AES_192_OCB_TAGLEN6425AEAD_AES_256_OCB_TAGLEN12826AEAD_AES_256_OCB_TAGLEN9627AEAD_AES_256_OCB_TAGLEN6428
The design of the original OCB scheme was done while
Rogaway was at Chiang Mai University, Thailand. Follow-up work was done with support of NSF grant 0208842 and a gift from
Cisco. The final work by Krovetz and Rogaway that has
resulted in this specification was supported by NSF grant 0904380. Thanks go
to the many members of the Crypto Forum Research Group (CFRG) who provided
feedback on earlier drafts. Thanks in particular go to David McGrew for
contributing some text and for managing the RFC approval process, to James
Manger for initiating a productive discussion on tag-length dependency and for
greatly improving , to Matt Caswell and Peter Dettman
for writing implementations and verifying test vectors, and to Stephen Farrell
and Spencer Dawkins for their careful reading and suggestions.
Advanced Encryption Standard (AES)National Institute of Standards and TechnologyOCB: A Block-Cipher Mode of Operation for Efficient Authenticated EncryptionEfficient Instantiations of Tweakable Blockciphers and Refinements to Modes
OCB and PMACThe Software Performance of Authenticated-Encryption Modes
This section gives sample output values for various inputs when using OCB with AES as per the parameters defined in . All strings are represented in hexadecimal (e.g., 0F represents the bitstring 00001111).
The following 16 (N,A,P,C) tuples show the ciphertext C that results from
OCB-ENCRYPT(K,N,A,P) for various lengths of associated data (A) and plaintext
(P). The key (K) has a fixed value, the tag length is 128 bits, and the
nonce (N) increments.
An empty entry indicates the empty string.
Next are several internal values generated during the OCB-ENCRYPT computation for the last test vector listed above.
The next tuple shows a result with a tag length of 96 bits and a different key.
The following algorithm tests a wider variety of inputs. Results are given for each parameter set defined in .
Iteration i of the loop adds 2i + (3 * TAGLEN / 8) bytes to C, resulting in an ultimate length for C of 22,400 bytes when TAGLEN == 128, 20,864 bytes when TAGLEN == 192, and 19,328 bytes when TAGLEN == 64. The final OCB-ENCRYPT has an empty plaintext component, so serves only to authenticate C. The output should be: