doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7253.txt b/doc/rfc/rfc7253.txt
new file mode 100644
index 0000000..3c729ad
--- /dev/null
+++ b/doc/rfc/rfc7253.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                           T. Krovetz
+Request for Comments: 7253                              Sacramento State
+Category: Informational                                       P. Rogaway
+ISSN: 2070-1721                                                 UC Davis
+                                                                May 2014
+
+
+               The OCB Authenticated-Encryption Algorithm
+
+Abstract
+
+   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).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Research Task Force
+   (IRTF).  The IRTF publishes the results of Internet-related research
+   and development activities.  These results might not be suitable for
+   deployment.  This RFC represents the consensus of the Crypto Forum
+   Research Group of the Internet Research Task Force (IRTF).  Documents
+   approved for publication by the IRSG are not a candidate for any
+   level of Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7253.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 1]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Notation and Basic Operations ...................................4
+   3. OCB Global Parameters ...........................................5
+      3.1. Named OCB Parameter Sets and RFC 5116 Constants ............6
+   4. OCB Algorithms ..................................................6
+      4.1. Processing Associated Data: HASH ...........................6
+      4.2. Encryption: OCB-ENCRYPT ....................................8
+      4.3. Decryption: OCB-DECRYPT ....................................9
+   5. Security Considerations ........................................11
+      5.1. Nonce Requirements ........................................12
+   6. IANA Considerations ............................................13
+   7. Acknowledgements ...............................................13
+   8. References .....................................................14
+      8.1. Normative References ......................................14
+      8.2. Informative References ....................................14
+   Appendix A.  Sample Results .......................................15
+
+1.  Introduction
+
+   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 Section 3.1.
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 2]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   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
+   Section 5 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 [OCB1]
+   and was listed as an optional component in IEEE 802.11i.  A second
+   version was published in 2004 [OCB2] and is specified in ISO 19772.
+   The scheme described here is called OCB3 in the 2011 paper describing
+   the mode [OCB3]; it shall be referred to simply as OCB throughout
+   this document.  The only difference between the algorithm of this RFC
+
+
+
+Krovetz & Rogaway             Informational                     [Page 3]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   and that of the [OCB3] paper is that the tag length is now encoded
+   into the internally formatted nonce.  See [OCB3] 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.
+
+2.  Notation and Basic Operations
+
+   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.
+
+   c^i           The integer c raised to the i-th power.
+
+   bitlen(S)     The length of string S in bits (e.g., bitlen(101) ==
+                 3).
+
+   zeros(n)      The string made of n zero bits.
+
+   ntz(n)        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.
+
+   S xor T       The string that is the bitwise exclusive-or of S and T.
+                 Strings S and T will always have the same length.
+
+   S[i]          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).
+
+   S[i..j]       The substring of S consisting of bits i through j,
+                 inclusive.
+
+
+
+Krovetz & Rogaway             Informational                     [Page 4]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   S || T        String S concatenated with string T (e.g., 000 || 111
+                 == 000111).
+
+   str2num(S)    The base-2 interpretation of bitstring S (e.g.,
+                 str2num(1110) == 14).
+
+   num2str(i,n)  The n-bit string whose base-2 interpretation is i
+                 (e.g., num2str(14,4) == 1110 and num2str(1,2) == 01).
+
+   double(S)     If S[1] == 0, then double(S) == (S[2..128] || 0);
+                 otherwise, double(S) == (S[2..128] || 0) xor
+                 (zeros(120) || 10000111).
+
+3.  OCB Global Parameters
+
+   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.
+
+   KEYLEN         The blockcipher's key length in bits.
+
+   ENCIPHER(K,P)  The blockcipher function mapping 128-bit plaintext
+                  block P to its corresponding ciphertext block using
+                  KEYLEN-bit key K.
+
+   DECIPHER(K,C)  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 Section 5 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 [AES].
+
+
+
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 5]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+3.1.  Named OCB Parameter Sets and RFC 5116 Constants
+
+   The following table gives names to common OCB global parameter sets.
+   Each of the AES variants is defined in [AES].
+
+           +----------------------------+-------------+--------+
+           | Name                       | Blockcipher | TAGLEN |
+           +----------------------------+-------------+--------+
+           | AEAD_AES_128_OCB_TAGLEN128 |   AES-128   |  128   |
+           | AEAD_AES_128_OCB_TAGLEN96  |   AES-128   |   96   |
+           | AEAD_AES_128_OCB_TAGLEN64  |   AES-128   |   64   |
+           | AEAD_AES_192_OCB_TAGLEN128 |   AES-192   |  128   |
+           | AEAD_AES_192_OCB_TAGLEN96  |   AES-192   |   96   |
+           | AEAD_AES_192_OCB_TAGLEN64  |   AES-192   |   64   |
+           | AEAD_AES_256_OCB_TAGLEN128 |   AES-256   |  128   |
+           | AEAD_AES_256_OCB_TAGLEN96  |   AES-256   |   96   |
+           | AEAD_AES_256_OCB_TAGLEN64  |   AES-256   |   64   |
+           +----------------------------+-------------+--------+
+
+   RFC 5116 defines an interface for authenticated-encryption schemes
+   [RFC5116].  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.
+
+4.  OCB Algorithms
+
+   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.
+
+4.1.  Processing Associated Data: HASH
+
+   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.
+
+
+
+Krovetz & Rogaway             Informational                     [Page 6]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   Function name:
+     HASH
+   Input:
+     K, string of KEYLEN bits                      // Key
+     A, string of any length                       // Associated data
+   Output:
+     Sum, string of 128 bits                       // Hash result
+
+   Sum is defined as follows.
+
+     //
+     // Key-dependent variables
+     //
+     L_* = ENCIPHER(K, zeros(128))
+     L_$ = double(L_*)
+     L_0 = double(L_$)
+     L_i = double(L_{i-1}) for every integer i > 0
+
+     //
+     // Consider A as a sequence of 128-bit blocks
+     //
+     Let m be the largest integer so that 128m <= bitlen(A)
+     Let A_1, A_2, ..., A_m and A_* be strings so that
+       A == A_1 || A_2 || ... || A_m || A_*, and
+       bitlen(A_i) == 128 for each 1 <= i <= m.
+       Note: A_* may possibly be the empty string.
+
+     //
+     // Process any whole blocks
+     //
+     Sum_0 = zeros(128)
+     Offset_0 = zeros(128)
+     for each 1 <= i <= m
+        Offset_i = Offset_{i-1} xor L_{ntz(i)}
+        Sum_i = Sum_{i-1} xor ENCIPHER(K, A_i xor Offset_i)
+     end for
+
+     //
+     // Process any final partial block; compute final hash value
+     //
+     if bitlen(A_*) > 0 then
+        Offset_* = Offset_m xor L_*
+        CipherInput = (A_* || 1 || zeros(127-bitlen(A_*))) xor Offset_*
+        Sum = Sum_m xor ENCIPHER(K, CipherInput)
+     else
+        Sum = Sum_m
+     end if
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 7]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+4.2.  Encryption: OCB-ENCRYPT
+
+   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.
+
+   Function name:
+     OCB-ENCRYPT
+   Input:
+     K, string of KEYLEN bits                      // Key
+     N, string of no more than 120 bits            // Nonce
+     A, string of any length                       // Associated data
+     P, string of any length                       // Plaintext
+   Output:
+     C, string of length bitlen(P) + TAGLEN bits   // Ciphertext
+
+   C is defined as follows.
+
+     //
+     // Key-dependent variables
+     //
+     L_* = ENCIPHER(K, zeros(128))
+     L_$ = double(L_*)
+     L_0 = double(L_$)
+     L_i = double(L_{i-1}) for every integer i > 0
+
+     //
+     // Consider P as a sequence of 128-bit blocks
+     //
+     Let m be the largest integer so that 128m <= bitlen(P)
+     Let P_1, P_2, ..., P_m and P_* be strings so that
+       P == P_1 || P_2 || ... || P_m || P_*, and
+       bitlen(P_i) == 128 for each 1 <= i <= m.
+       Note: P_* may possibly be the empty string.
+
+     //
+     // Nonce-dependent and per-encryption variables
+     //
+     Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N
+     bottom = str2num(Nonce[123..128])
+     Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6))
+     Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72])
+     Offset_0 = Stretch[1+bottom..128+bottom]
+     Checksum_0 = zeros(128)
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 8]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+     //
+     // Process any whole blocks
+     //
+     for each 1 <= i <= m
+        Offset_i = Offset_{i-1} xor L_{ntz(i)}
+        C_i = Offset_i xor ENCIPHER(K, P_i xor Offset_i)
+        Checksum_i = Checksum_{i-1} xor P_i
+     end for
+
+     //
+     // Process any final partial block and compute raw tag
+     //
+     if bitlen(P_*) > 0 then
+        Offset_* = Offset_m xor L_*
+        Pad = ENCIPHER(K, Offset_*)
+        C_* = P_* xor Pad[1..bitlen(P_*)]
+        Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*)))
+        Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A)
+     else
+        C_* = <empty string>
+        Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A)
+     end if
+
+     //
+     // Assemble ciphertext
+     //
+     C = C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN]
+
+4.3.  Decryption: OCB-DECRYPT
+
+   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.
+
+   Function name:
+     OCB-DECRYPT
+   Input:
+     K, string of KEYLEN bits                      // Key
+     N, string of no more than 120 bits            // Nonce
+     A, string of any length                       // Associated data
+     C, string of at least TAGLEN bits             // Ciphertext
+   Output:
+     P, string of length bitlen(C) - TAGLEN bits,  // Plaintext
+          or INVALID indicating authentication failure
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                     [Page 9]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   P is defined as follows.
+
+     //
+     // Key-dependent variables
+     //
+     L_* = ENCIPHER(K, zeros(128))
+     L_$ = double(L_*)
+     L_0 = double(L_$)
+     L_i = double(L_{i-1}) for every integer i > 0
+
+     //
+     // Consider C as a sequence of 128-bit blocks
+     //
+     Let m be the largest integer so that 128m <= bitlen(C) - TAGLEN
+     Let C_1, C_2, ..., C_m, C_* and T be strings so that
+       C == C_1 || C_2 || ... || C_m || C_* || T,
+       bitlen(C_i) == 128 for each 1 <= i <= m, and
+       bitlen(T) == TAGLEN.
+       Note: C_* may possibly be the empty string.
+
+     //
+     // Nonce-dependent and per-decryption variables
+     //
+     Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N
+     bottom = str2num(Nonce[123..128])
+     Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6))
+     Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72])
+     Offset_0 = Stretch[1+bottom..128+bottom]
+     Checksum_0 = zeros(128)
+
+     //
+     // Process any whole blocks
+     //
+     for each 1 <= i <= m
+        Offset_i = Offset_{i-1} xor L_{ntz(i)}
+        P_i = Offset_i xor DECIPHER(K, C_i xor Offset_i)
+        Checksum_i = Checksum_{i-1} xor P_i
+     end for
+
+     //
+     // Process any final partial block and compute raw tag
+     //
+     if bitlen(C_*) > 0 then
+        Offset_* = Offset_m xor L_*
+        Pad = ENCIPHER(K, Offset_*)
+        P_* = C_* xor Pad[1..bitlen(C_*)]
+        Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*)))
+        Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A)
+
+
+
+Krovetz & Rogaway             Informational                    [Page 10]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+     else
+        P_* = <empty string>
+        Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A)
+     end if
+
+     //
+     // Check for validity and assemble plaintext
+     //
+     if (Tag[1..TAGLEN] == T) then
+        P = P_1 || P_2 || ... || P_m || P_*
+     else
+        P = INVALID
+     end if
+
+5.  Security Considerations
+
+   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 [RFC4107].
+
+   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
+
+
+
+Krovetz & Rogaway             Informational                    [Page 11]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   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.
+
+5.1.  Nonce Requirements
+
+   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
+
+
+
+Krovetz & Rogaway             Informational                    [Page 12]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   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) [RFC5297], 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).
+
+6.  IANA Considerations
+
+   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 Section 3.1.
+
+         +----------------------------+-------------+------------+
+         | Name                       |  Reference  | Numeric ID |
+         +----------------------------+-------------+------------+
+         | AEAD_AES_128_OCB_TAGLEN128 | Section 3.1 |     20     |
+         | AEAD_AES_128_OCB_TAGLEN96  | Section 3.1 |     21     |
+         | AEAD_AES_128_OCB_TAGLEN64  | Section 3.1 |     22     |
+         | AEAD_AES_192_OCB_TAGLEN128 | Section 3.1 |     23     |
+         | AEAD_AES_192_OCB_TAGLEN96  | Section 3.1 |     24     |
+         | AEAD_AES_192_OCB_TAGLEN64  | Section 3.1 |     25     |
+         | AEAD_AES_256_OCB_TAGLEN128 | Section 3.1 |     26     |
+         | AEAD_AES_256_OCB_TAGLEN96  | Section 3.1 |     27     |
+         | AEAD_AES_256_OCB_TAGLEN64  | Section 3.1 |     28     |
+         +----------------------------+-------------+------------+
+
+7.  Acknowledgements
+
+   The design of the original OCB scheme [OCB1] was done while Rogaway
+   was at Chiang Mai University, Thailand.  Follow-up work [OCB2] was
+   done with support of NSF grant 0208842 and a gift from Cisco.  The
+   final work by Krovetz and Rogaway [OCB3] that has resulted in this
+
+
+
+Krovetz & Rogaway             Informational                    [Page 13]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   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 Appendix A, 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.
+
+8.  References
+
+8.1.  Normative References
+
+   [AES]      National Institute of Standards and Technology, "Advanced
+              Encryption Standard (AES)", FIPS PUB 197, November 2001.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, January 2008.
+
+8.2.  Informative References
+
+   [OCB1]     Rogaway, P., Bellare, M., Black, J., and T. Krovetz, "OCB:
+              A Block-Cipher Mode of Operation for Efficient
+              Authenticated Encryption", ACM Conference on Computer and
+              Communications Security 2001 - CCS 2001, ACM Press, 2001.
+
+   [OCB2]     Rogaway, P., "Efficient Instantiations of Tweakable
+              Blockciphers and Refinements to Modes OCB and PMAC",
+              Advances in Cryptology - ASIACRYPT 2004, Springer, 2004.
+
+   [OCB3]     Krovetz, T. and P. Rogaway, "The Software Performance of
+              Authenticated-Encryption Modes", Fast Software Encryption
+              - FSE 2011 Springer, 2011.
+
+   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+              Key Management", BCP 107, RFC 4107, June 2005.
+
+   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
+              Authenticated Encryption Using the Advanced Encryption
+              Standard (AES)", RFC 5297, October 2008.
+
+
+
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 14]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+Appendix A.  Sample Results
+
+   This section gives sample output values for various inputs when using
+   OCB with AES as per the parameters defined in Section 3.1.  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.
+
+     K : 000102030405060708090A0B0C0D0E0F
+
+   An empty entry indicates the empty string.
+
+     N: BBAA99887766554433221100
+     A:
+     P:
+     C: 785407BFFFC8AD9EDCC5520AC9111EE6
+
+     N: BBAA99887766554433221101
+     A: 0001020304050607
+     P: 0001020304050607
+     C: 6820B3657B6F615A5725BDA0D3B4EB3A257C9AF1F8F03009
+
+     N: BBAA99887766554433221102
+     A: 0001020304050607
+     P:
+     C: 81017F8203F081277152FADE694A0A00
+
+     N: BBAA99887766554433221103
+     A:
+     P: 0001020304050607
+     C: 45DD69F8F5AAE72414054CD1F35D82760B2CD00D2F99BFA9
+
+     N: BBAA99887766554433221104
+     A: 000102030405060708090A0B0C0D0E0F
+     P: 000102030405060708090A0B0C0D0E0F
+     C: 571D535B60B277188BE5147170A9A22C3AD7A4FF3835B8C5
+        701C1CCEC8FC3358
+
+     N: BBAA99887766554433221105
+     A: 000102030405060708090A0B0C0D0E0F
+     P:
+     C: 8CF761B6902EF764462AD86498CA6B97
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 15]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+     N: BBAA99887766554433221106
+     A:
+     P: 000102030405060708090A0B0C0D0E0F
+     C: 5CE88EC2E0692706A915C00AEB8B2396F40E1C743F52436B
+        DF06D8FA1ECA343D
+
+     N: BBAA99887766554433221107
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+     C: 1CA2207308C87C010756104D8840CE1952F09673A448A122
+        C92C62241051F57356D7F3C90BB0E07F
+
+     N: BBAA99887766554433221108
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+     P:
+     C: 6DC225A071FC1B9F7C69F93B0F1E10DE
+
+     N: BBAA99887766554433221109
+     A:
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+     C: 221BD0DE7FA6FE993ECCD769460A0AF2D6CDED0C395B1C3C
+        E725F32494B9F914D85C0B1EB38357FF
+
+     N: BBAA9988776655443322110A
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F
+     C: BD6F6C496201C69296C11EFD138A467ABD3C707924B964DE
+        AFFC40319AF5A48540FBBA186C5553C68AD9F592A79A4240
+
+     N: BBAA9988776655443322110B
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F
+     P:
+     C: FE80690BEE8A485D11F32965BC9D2A32
+
+     N: BBAA9988776655443322110C
+     A:
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F
+     C: 2942BFC773BDA23CABC6ACFD9BFD5835BD300F0973792EF4
+        6040C53F1432BCDFB5E1DDE3BC18A5F840B52E653444D5DF
+
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 16]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+     N: BBAA9988776655443322110D
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     C: D5CA91748410C1751FF8A2F618255B68A0A12E093FF45460
+        6E59F9C1D0DDC54B65E8628E568BAD7AED07BA06A4A69483
+        A7035490C5769E60
+
+     N: BBAA9988776655443322110E
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     P:
+     C: C5CD9D1850C141E358649994EE701B68
+
+     N: BBAA9988776655443322110F
+     A:
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     C: 4412923493C57D5DE0D700F753CCE0D1D2D95060122E9F15
+        A5DDBFC5787E50B5CC55EE507BCB084E479AD363AC366B95
+        A98CA5F3000B1479
+
+   Next are several internal values generated during the OCB-ENCRYPT
+   computation for the last test vector listed above.
+
+     L_*       : C6A13B37878F5B826F4F8162A1C8D879
+     L_$       : 8D42766F0F1EB704DE9F02C54391B075
+     L_0       : 1A84ECDE1E3D6E09BD3E058A8723606D
+     L_1       : 3509D9BC3C7ADC137A7C0B150E46C0DA
+     bottom    : 15 (decimal)
+     Ktop      : 9862B0FDEE4E2DD56DBA6433F0125AA2
+     Stretch   : 9862B0FDEE4E2DD56DBA6433F0125AA2FAD24D13A063F8B8
+     Offset_0  : 587EF72716EAB6DD3219F8092D517D69
+     Offset_1  : 42FA1BF908D7D8D48F27FD83AA721D04
+     Offset_2  : 77F3C24534AD04C7F55BF696A434DDDE
+     Offset_*  : B152F972B3225F459A1477F405FC05A7
+     Checksum_1: 000102030405060708090A0B0C0D0E0F
+     Checksum_2: 10101010101010101010101010101010
+     Checksum_*: 30313233343536379010101010101010
+
+
+
+
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 17]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+   The next tuple shows a result with a tag length of 96 bits and a
+   different key.
+
+     K: 0F0E0D0C0B0A09080706050403020100
+
+     N: BBAA9988776655443322110D
+     A: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     P: 000102030405060708090A0B0C0D0E0F1011121314151617
+        18191A1B1C1D1E1F2021222324252627
+     C: 1792A4E31E0755FB03E31B22116E6C2DDF9EFD6E33D536F1
+        A0124B0A55BAE884ED93481529C76B6AD0C515F4D1CDD4FD
+        AC4F02AA
+
+   The following algorithm tests a wider variety of inputs.  Results are
+   given for each parameter set defined in Section 3.1.
+
+      K = zeros(KEYLEN-8) || num2str(TAGLEN,8)
+      C = <empty string>
+      for i = 0 to 127 do
+         S = zeros(8i)
+         N = num2str(3i+1,96)
+         C = C || OCB-ENCRYPT(K,N,S,S)
+         N = num2str(3i+2,96)
+         C = C || OCB-ENCRYPT(K,N,<empty string>,S)
+         N = num2str(3i+3,96)
+         C = C || OCB-ENCRYPT(K,N,S,<empty string>)
+      end for
+      N = num2str(385,96)
+      Output : OCB-ENCRYPT(K,N,C,<empty string>)
+
+   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:
+
+     AEAD_AES_128_OCB_TAGLEN128 Output: 67E944D23256C5E0B6C61FA22FDF1EA2
+     AEAD_AES_192_OCB_TAGLEN128 Output: F673F2C3E7174AAE7BAE986CA9F29E17
+     AEAD_AES_256_OCB_TAGLEN128 Output: D90EB8E9C977C88B79DD793D7FFA161C
+     AEAD_AES_128_OCB_TAGLEN96 Output : 77A3D8E73589158D25D01209
+     AEAD_AES_192_OCB_TAGLEN96 Output : 05D56EAD2752C86BE6932C5E
+     AEAD_AES_256_OCB_TAGLEN96 Output : 5458359AC23B0CBA9E6330DD
+     AEAD_AES_128_OCB_TAGLEN64 Output : 192C9B7BD90BA06A
+     AEAD_AES_192_OCB_TAGLEN64 Output : 0066BC6E0EF34E24
+     AEAD_AES_256_OCB_TAGLEN64 Output : 7D4EA5D445501CBE
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 18]
+
+RFC 7253              OCB Authenticated Encryption              May 2014
+
+
+Authors' Addresses
+
+   Ted Krovetz
+   Computer Science Department
+   California State University, Sacramento
+   6000 J Street
+   Sacramento, CA  95819-6021
+   USA
+
+   EMail: ted@krovetz.net
+
+
+   Phillip Rogaway
+   Computer Science Department
+   University of California, Davis
+   One Shields Avenue
+   Davis, CA  95616-8562
+   USA
+
+   EMail: rogaway@cs.ucdavis.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krovetz & Rogaway             Informational                    [Page 19]
+