diff options
Diffstat (limited to 'doc/rfc/rfc5297.txt')
| -rw-r--r-- | doc/rfc/rfc5297.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5297.txt b/doc/rfc/rfc5297.txt new file mode 100644 index 0000000..6e4a752 --- /dev/null +++ b/doc/rfc/rfc5297.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group D. Harkins +Request for Comments: 5297 Aruba Networks +Category: Informational October 2008 + + + Synthetic Initialization Vector (SIV) Authenticated Encryption + Using the Advanced Encryption Standard (AES) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This memo describes SIV (Synthetic Initialization Vector), a block + cipher mode of operation. SIV takes a key, a plaintext, and multiple + variable-length octet strings that will be authenticated but not + encrypted. It produces a ciphertext having the same length as the + plaintext and a synthetic initialization vector. Depending on how it + is used, SIV achieves either the goal of deterministic authenticated + encryption or the goal of nonce-based, misuse-resistant authenticated + encryption. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hawkins Informational [Page 1] + +RFC 5297 SIV-AES October 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Background .................................................3 + 1.2. Definitions ................................................4 + 1.3. Motivation .................................................4 + 1.3.1. Key Wrapping ........................................4 + 1.3.2. Resistance to Nonce Misuse/Reuse ....................4 + 1.3.3. Key Derivation ......................................5 + 1.3.4. Robustness versus Performance .......................6 + 1.3.5. Conservation of Cryptographic Primitives ............6 + 2. Specification of SIV ............................................6 + 2.1. Notation ...................................................6 + 2.2. Overview ...................................................7 + 2.3. Doubling ...................................................7 + 2.4. S2V ........................................................8 + 2.5. CTR .......................................................10 + 2.6. SIV Encrypt ...............................................10 + 2.7. SIV Decrypt ...............................................12 + 3. Nonce-Based Authenticated Encryption with SIV ..................14 + 4. Deterministic Authenticated Encryption with SIV ................15 + 5. Optimizations ..................................................15 + 6. IANA Considerations ............................................15 + 6.1. AEAD_AES_SIV_CMAC_256 .....................................17 + 6.2. AEAD_AES_SIV_CMAC_384 .....................................17 + 6.3. AEAD_AES_SIV_CMAC_512 .....................................18 + 7. Security Considerations ........................................18 + 8. Acknowledgments ................................................19 + 9. References .....................................................19 + 9.1. Normative References ......................................19 + 9.2. Informative References ....................................19 + Appendix A. Test Vectors ....................................... 22 + A.1. Deterministic Authenticated Encryption Example ........... 22 + A.2. Nonce-Based Authenticated Encryption Example ............. 23 + + + + + + + + + + + + + + + + + +Hawkins Informational [Page 2] + +RFC 5297 SIV-AES October 2008 + + +1. Introduction + +1.1. Background + + Various attacks have been described (e.g., [BADESP]) when data is + merely privacy protected and not additionally authenticated or + integrity protected. Therefore, combined modes of encryption and + authentication have been developed ([RFC5116], [RFC3610], [GCM], + [JUTLA], [OCB]). These provide conventional authenticated encryption + when used with a nonce ("a number used once") and typically accept + additional inputs that are authenticated but not encrypted, + hereinafter referred to as "associated data" or AD. + + A deterministic, nonce-less, form of authenticated encryption has + been used to protect the transportation of cryptographic keys (e.g., + [X9F1], [RFC3217], [RFC3394]). This is generally referred to as "Key + Wrapping". + + This memo describes a new block cipher mode, SIV, that provides both + nonce-based authenticated encryption as well as deterministic, nonce- + less key wrapping. It contains a Pseudo-Random Function (PRF) + construction called S2V and an encryption/decryption construction, + called CTR. SIV was specified by Phillip Rogaway and Thomas + Shrimpton in [DAE]. The underlying block cipher used herein for both + S2V and CTR is AES with key lengths of 128 bits, 192 bits, or 256 + bits. S2V uses AES in Cipher-based Message Authentication Code + ([CMAC]) mode, CTR uses AES in counter ([MODES]) mode. + + Associated data is data input to an authenticated-encryption mode + that will be authenticated but not encrypted. [RFC5116] says that + associated data can include "addresses, ports, sequence numbers, + protocol version numbers, and other fields that indicate how the + plaintext or ciphertext should be handled, forwarded, or processed". + These are multiple, distinct inputs and may not be contiguous. Other + authenticated-encryption cipher modes allow only a single associated + data input. Such a limitation may require implementation of a + scatter/gather form of data marshalling to combine the multiple + components of the associated data into a single input or may require + a pre-processing step where the associated data inputs are + concatenated together. SIV accepts multiple variable-length octet + strings (hereinafter referred to as a "vector of strings") as + associated data inputs. This obviates the need for data marshalling + or pre-processing of associated data to package it into a single + input. + + By allowing associated data to consist of a vector of strings SIV + also obviates the requirement to encode the length of component + fields of the associated data when those fields have variable length. + + + +Hawkins Informational [Page 3] + +RFC 5297 SIV-AES October 2008 + + +1.2. Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3. Motivation + +1.3.1. Key Wrapping + + A key distribution protocol must protect keys it is distributing. + This has not always been done correctly. For example, RADIUS + [RFC2865] uses Microsoft Point-to-Point Encryption (MPPE) [RFC2548] + to encrypt a key prior to transmission from server to client. It + provides no integrity checking of the encrypted key. [RADKEY] + specifies the use of [RFC3394] to wrap a key in a RADIUS request but + because of the inability to pass associated data, a Hashed Message + Authentication Code (HMAC) [RFC2104] is necessary to provide + authentication of the entire request. + + SIV can be used as a drop-in replacement for any specification that + uses [RFC3394] or [RFC3217], including the aforementioned use. It is + a more general purpose solution as it allows for associated data to + be specified. + +1.3.2. Resistance to Nonce Misuse/Reuse + + The nonce-based authenticated encryption schemes described above are + susceptible to reuse and/or misuse of the nonce. Depending on the + specific scheme there are subtle and critical requirements placed on + the nonce (see [SP800-38D]). [GCM] states that it provides + "excellent security" if its nonce is guaranteed to be distinct but + provides "no security" otherwise. Confidentiality guarantees are + voided if a counter in [RFC3610] is reused. In many cases, + guaranteeing no reuse of a nonce/counter/IV is not a problem, but in + others it will be. + + For example, many applications obtain access to cryptographic + functions via an application program interface to a cryptographic + library. These libraries are typically not stateful and any nonce, + initialization vector, or counter required by the cipher mode is + passed to the cryptographic library by the application. Putting the + construction of a security-critical datum outside the control of the + encryption engine places an onerous burden on the application writer + who may not provide the necessary cryptographic hygiene. Perhaps his + random number generator is not very good or maybe an application + fault causes a counter to be reset. The fragility of the cipher mode + may result in its inadvertent misuse. Also, if one's environment is + + + +Hawkins Informational [Page 4] + +RFC 5297 SIV-AES October 2008 + + + (knowingly or unknowingly) a virtual machine, it may be possible to + roll back a virtual state machine and cause nonce reuse thereby + gutting the security of the authenticated encryption scheme (see + [VIRT]). + + If the nonce is random, a requirement that it never repeat will limit + the amount of data that can be safely protected with a single key to + one block. More sensibly, a random nonce is required to "almost + always" be non-repeating, but that will drastically limit the amount + of data that can be safely protected. + + SIV provides a level of resistance to nonce reuse and misuse. If the + nonce is never reused, then the usual notion of nonce-based security + of an authenticated encryption mode is achieved. If, however, the + nonce is reused, authenticity is retained and confidentiality is only + compromised to the extent that an attacker can determine that the + same plaintext (and same associated data) was protected with the same + nonce and key. See Security Considerations (Section 7). + +1.3.3. Key Derivation + + A PRF is frequently used as a key derivation function (e.g., [WLAN]) + by passing it a key and a single string. Typically, this single + string is the concatenation of a series of smaller strings -- for + example, a label and some context to bind into the derived string. + + These are usually multiple strings but are mapped to a single string + because of the way PRFs are typically defined -- two inputs: a key + and data. Such a crude mapping is inefficient because additional + data must be included -- the length of variable-length inputs must be + encoded separately -- and, depending on the PRF, memory allocation + and copying may be needed. Also, if only one or two of the inputs + changed when deriving a new key, it may still be necessary to process + all of the other constants that preceded it every time the PRF is + invoked. + + When a PRF is used in this manner its input is a vector of strings + and not a single string and the PRF should handle the data as such. + The S2V ("string to vector") PRF construction accepts a vector of + inputs and provides a more natural mapping of input that does not + require additional lengths encodings and obviates the memory and + processing overhead to marshal inputs and their encoded lengths into + a single string. Constant inputs to the PRF need only be computed + once. + + + + + + + +Hawkins Informational [Page 5] + +RFC 5297 SIV-AES October 2008 + + +1.3.4. Robustness versus Performance + + SIV cannot perform at the same high throughput rates that other + authenticated encryption schemes can (e.g., [GCM] or [OCB]) due to + the requirement for two passes of the data, but for situations where + performance is not a limiting factor -- e.g., control plane + applications -- it can provide a robust alternative, especially when + considering its resistance to nonce reuse. + +1.3.5. Conservation of Cryptographic Primitives + + The cipher mode described herein can do authenticated encryption, key + wrapping, key derivation, and serve as a generic message + authentication algorithm. It is therefore possible to implement all + these functions with a single tool, instead of one tool for each + function. This is extremely attractive for devices that are memory + and/or processor constrained and that cannot afford to implement + multiple cryptographic primitives to accomplish these functions. + +2. Specification of SIV + +2.1. Notation + + SIV and S2V use the following notation: + + len(A) + returns the number of bits in A. + + pad(X) + indicates padding of string X, len(X) < 128, out to 128 bits by + the concatenation of a single bit of 1 followed by as many 0 bits + as are necessary. + + leftmost(A,n) + the n most significant bits of A. + + rightmost(A,n) + the n least significant bits of A. + + A || B + means concatenation of string A with string B. + + A xor B + is the exclusive OR operation on two equal length strings, A and + B. + + + + + + +Hawkins Informational [Page 6] + +RFC 5297 SIV-AES October 2008 + + + A xorend B + where len(A) >= len(B), means xoring a string B onto the end of + string A -- i.e., leftmost(A, len(A)-len(B)) || (rightmost(A, + len(B)) xor B). + + A bitand B + is the logical AND operation on two equal length strings, A and B. + + dbl(S) + is the multiplication of S and 0...010 in the finite field + represented using the primitive polynomial + x^128 + x^7 + x^2 + x + 1. See Doubling (Section 2.3). + + a^b + indicates a string that is "b" bits, each having the value "a". + + <zero> + indicates a string that is 128 zero bits. + + <one> + indicates a string that is 127 zero bits concatenated with a + single one bit, that is 0^127 || 1^1. + + A/B + indicates the greatest integer less than or equal to the real- + valued quotient of A and B. + + E(K,X) + indicates AES encryption of string X using key K. + +2.2. Overview + + SIV-AES uses AES in CMAC mode (S2V) and in counter mode (CTR). SIV- + AES takes either a 256-, 384-, or 512-bit key (which is broken up + into two equal-sized keys, one for S2V and the other for CTR), a + variable length plaintext, and multiple variable-length strings + representing associated data. Its output is a ciphertext that + comprises a synthetic initialization vector concatenated with the + encrypted plaintext. + +2.3. Doubling + + The doubling operation on a 128-bit input string is performed using a + left-shift of the input followed by a conditional xor operation on + the result with the constant: + + 00000000 00000000 00000000 00000087 + + + + +Hawkins Informational [Page 7] + +RFC 5297 SIV-AES October 2008 + + + The condition under which the xor operation is performed is when the + bit being shifted off is one. + + Note that this is the same operation used to generate sub-keys for + CMAC-AES. + +2.4. S2V + + The S2V operation consists of the doubling and xoring of the outputs + of a pseudo-random function, CMAC, operating over individual strings + in the input vector: S1, S2, ... , Sn. It is bootstrapped by + performing CMAC on a 128-bit string of zeros. If the length of the + final string in the vector is greater than or equal to 128 bits, the + output of the double/xor chain is xored onto the end of the final + input string. That result is input to a final CMAC operation to + produce the output V. If the length of the final string is less than + 128 bits, the output of the double/xor chain is doubled once more and + it is xored with the final string padded using the padding function + pad(X). That result is input to a final CMAC operation to produce + the output V. + + S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and + len(Sn) >= 128: + + +----+ +----+ +------+ +----+ + | S1 | | S2 | . . . | Sn-1 | | Sn | + +----+ +----+ +------+ +----+ + <zero> K | | | | + | | | | | V + V | V V V /----> xorend + +-----+ | +-----+ +-----+ +-----+ | | + | AES-|<----->| AES-| K-->| AES-| K--->| AES-| | | + | CMAC| | CMAC| | CMAC| | CMAC| | | + +-----+ +-----+ +-----+ +-----+ | V + | | | | | +-----+ + | | | | | K-->| AES-| + | | | | | | CMAC| + | | | | | +-----+ + \-> dbl -> xor -> dbl -> xor -> dbl -> xor---/ | + V + +---+ + | V | + +---+ + + Figure 2 + + + + + + +Hawkins Informational [Page 8] + +RFC 5297 SIV-AES October 2008 + + + S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and + len(Sn) < 128: + + +----+ +----+ +------+ +---------+ + | S1 | | S2 | . . . | Sn-1 | | pad(Sn) | + +----+ +----+ +------+ +---------+ + <zero> K | | | | + | | | | | V + V | V V V /------> xor + +-----+ | +-----+ +-----+ +-----+ | | + | AES-|<--->| AES-| K-->| AES-| K-->| AES-| | | + | CMAC| | CMAC| | CMAC| | CMAC| | | + +-----+ +-----+ +-----+ +-----+ | V + | | | | | +-----+ + | | | | | K-->| AES-| + | | | | | | CMAC| + | | | | | +-----+ + \-> dbl -> xor -> dbl -> xor -> dbl -> xor-> dbl | + V + +---+ + | V | + +---+ + + Figure 3 + + Algorithmically S2V can be described as: + + S2V(K, S1, ..., Sn) { + if n = 0 then + return V = AES-CMAC(K, <one>) + fi + D = AES-CMAC(K, <zero>) + for i = 1 to n-1 do + D = dbl(D) xor AES-CMAC(K, Si) + done + if len(Sn) >= 128 then + T = Sn xorend D + else + T = dbl(D) xor pad(Sn) + fi + return V = AES-CMAC(K, T) + } + + + + + + + + + +Hawkins Informational [Page 9] + +RFC 5297 SIV-AES October 2008 + + +2.5. CTR + + CTR is a counter mode of AES. It takes as input a plaintext P of + arbitrary length, a key K of length 128, 192, or 256 bits, and a + counter X that is 128 bits in length, and outputs Z, which represents + a concatenation of a synthetic initialization vector V and the + ciphertext C, which is the same length as the plaintext. + + The ciphertext is produced by xoring the plaintext with the first + len(P) bits of the following string: + + E(K, X) || E(K, X+1) || E(K, X+2) || ... + + Before beginning counter mode, the 31st and 63rd bits (where the + rightmost bit is the 0th bit) of the counter are cleared. This + enables implementations that support native 32-bit (64-bit) addition + to increment the counter modulo 2^32 (2^64) in a manner that cannot + be distinguished from 128-bit increments, as long as the number of + increment operations is limited by an upper bound that safely avoids + carry to occur out of the respective pre-cleared bit. More formally, + for 32-bit addition, the counter is incremented as: + + SALT=leftmost(X,96) + + n=rightmost(X,32) + + X+i = SALT || (n + i mod 2^32). + + For 64-bit addition, the counter is incremented as: + + SALT=leftmost(X,64) + + n=rightmost(X,64) + + X+i = SALT || (n + i mod 2^64). + + Performing 32-bit or 64-bit addition on the counter will limit the + amount of plaintext that can be safely protected by SIV-AES to 2^39 - + 128 bits or 2^71 - 128 bits, respectively. + +2.6. SIV Encrypt + + SIV-encrypt takes as input a key K of length 256, 384, or 512 bits, + plaintext of arbitrary length, and a vector of associated data AD[ ] + where the number of components in the vector is not greater than 126 + (see Section 7). It produces output, Z, which is the concatenation + of a 128-bit synthetic initialization vector and ciphertext whose + length is equal to the length of the plaintext. + + + +Hawkins Informational [Page 10] + +RFC 5297 SIV-AES October 2008 + + + The key is split into equal halves, K1 = leftmost(K, len(K)/2) and K2 + = rightmost(K, len(K)/2). K1 is used for S2V and K2 is used for CTR. + + In the encryption mode, the associated data and plaintext represent + the vector of inputs to S2V, with the plaintext being the last string + in the vector. The output of S2V is a synthetic IV that represents + the initial counter to CTR. + + The encryption construction of SIV is as follows: + + +------+ +------+ +------+ +---+ + | AD 1 | | AD 2 |...| AD n | | P | + +------+ +------+ +------+ +---+ + | | | | + | | ... | ------------------| + \ | / / | + \ | / / +------------+ | + \ | / / | K = K1||K2 | | + \ | / / +------------+ V + \ | / / | | +-----+ + \ | / / K1 | | K2 | | + \ | / / ------/ \------>| CTR | + \ | / / / ------->| | + | | | | | | +-----+ + V V V V V | | + +------------+ +--------+ V + | S2V |------>| V | +----+ + +------------+ +--------+ | C | + | +----+ + | | + -----\ | + \ | + \ | + V V + +-----+ + | Z | + +-----+ + + where the plaintext is P, the associated data is AD1 through ADn, V + is the synthetic IV, the ciphertext is C, and Z is the output. + + Figure 8 + + + + + + + + + +Hawkins Informational [Page 11] + +RFC 5297 SIV-AES October 2008 + + + Algorithmically, SIV Encrypt can be described as: + + SIV-ENCRYPT(K, P, AD1, ..., ADn) { + K1 = leftmost(K, len(K)/2) + K2 = rightmost(K, len(K)/2) + V = S2V(K1, AD1, ..., ADn, P) + Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31) + m = (len(P) + 127)/128 + + for i = 0 to m-1 do + Xi = AES(K2, Q+i) + done + X = leftmost(X0 || ... || Xm-1, len(P)) + C = P xor X + + return V || C + } + + where the key length used by AES in CTR and S2V is len(K)/2 and will + each be either 128 bits, 192 bits, or 256 bits. + + The 31st and 63rd bit (where the rightmost bit is the 0th) of the + counter are zeroed out just prior to being used by CTR for + optimization purposes, see Section 5. + +2.7. SIV Decrypt + + SIV-decrypt takes as input a key K of length 256, 384, or 512 bits, + Z, which represents a synthetic initialization vector V concatenated + with a ciphertext C, and a vector of associated data AD[ ] where the + number of components in the vector is not greater than 126 (see + Section 7). It produces either the original plaintext or the special + symbol FAIL. + + The key is split as specified in Section 2.6 + + The synthetic initialization vector acts as the initial counter to + CTR to decrypt the ciphertext. The associated data and the output of + CTR represent a vector of strings that is passed to S2V, with the CTR + output being the last string in the vector. The output of S2V is + then compared against the synthetic IV that accompanied the original + ciphertext. If they match, the output from CTR is returned as the + decrypted and authenticated plaintext; otherwise, the special symbol + FAIL is returned. + + + + + + + +Hawkins Informational [Page 12] + +RFC 5297 SIV-AES October 2008 + + + The decryption construction of SIV is as follows: + + +------+ +------+ +------+ +---+ + | AD 1 | | AD 2 |...| AD n | | P | + +------+ +------+ +------+ +---+ + | | | ^ + | | ... / | + | | / /----------------| + | | / / | + \ | / / +------------+ | + \ | / / | K = K1||k2 | | + \ | / / +------------+ | + \ | / / | | +-----+ + \ | / / K1 | | K2 | | + \ | | | /-----/ \----->| CTR | + \ | | | | ------->| | + | | | | | | +-----+ + V V V V V | ^ + +-------------+ +--------+ | + | S2V | | V | +---+ + +-------------+ +--------+ | C | + | | ^ +---+ + | | | ^ + | | \ | + | | \___ | + V V \ | + +-------+ +---------+ +---+ + | T |----->| if != | | Z | + +-------+ +---------+ +---+ + | + | + V + FAIL + + Figure 10 + + + + + + + + + + + + + + + + +Hawkins Informational [Page 13] + +RFC 5297 SIV-AES October 2008 + + + Algorithmically, SIV-Decrypt can be described as: + + SIV-DECRYPT(K, Z, AD1, ..., ADn) { + V = leftmost(Z, 128) + C = rightmost(Z, len(Z)-128) + K1 = leftmost(K, len(K)/2) + K2 = rightmost(K, len(K)/2) + Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31) + + m = (len(C) + 127)/128 + for i = 0 to m-1 do + Xi = AES(K2, Q+i) + done + X = leftmost(X0 || ... || Xm-1, len(C)) + P = C xor X + T = S2V(K1, AD1, ..., ADn, P) + + if T = V then + return P + else + return FAIL + fi + } + + where the key length used by AES in CTR and S2V is len(K)/2 and will + each be either 128 bits, 192 bits, or 256 bits. + + The 31st and 63rd bit (where the rightmost bit is the 0th) of the + counter are zeroed out just prior to being used in CTR mode for + optimization purposes, see Section 5. + +3. Nonce-Based Authenticated Encryption with SIV + + SIV performs nonce-based authenticated encryption when a component of + the associated data is a nonce. For purposes of interoperability the + final component -- i.e., the string immediately preceding the + plaintext in the vector input to S2V -- is used for the nonce. Other + associated data are optional. It is up to the specific application + of SIV to specify how the rest of the associated data are input. + + If the nonce is random, it SHOULD be at least 128 bits in length and + be harvested from a pool having at least 128 bits of entropy. A non- + random source MAY also be used, for instance, a time stamp, or a + counter. The definition of a nonce precludes reuse, but SIV is + resistant to nonce reuse. See Section 1.3.2 for a discussion on the + security implications of nonce reuse. + + + + + +Hawkins Informational [Page 14] + +RFC 5297 SIV-AES October 2008 + + + It MAY be necessary to transport this nonce with the output generated + by S2V. + +4. Deterministic Authenticated Encryption with SIV + + When the plaintext to encrypt and authenticate contains data that is + unpredictable to an adversary -- for example, a secret key -- SIV can + be used in a deterministic mode to perform "key wrapping". Because + S2V allows for associated data and imposes no unnatural size + restrictions on the data it is protecting, it is a more useful and + general purpose solution than [RFC3394]. Protocols that use SIV for + deterministic authenticated encryption (i.e., for more than just + wrapping of keys) MAY define associated data inputs to SIV. It is + not necessary to add a nonce component to the AD in this case. + +5. Optimizations + + Implementations that cannot or do not wish to support addition modulo + 2^128 can take advantage of the fact that the 31st and 63rd bits + (where the rightmost bit is the 0th bit) in the counter are cleared + before being used by CTR. This allows implementations that natively + support 32-bit or 64-bit addition to increment the counter naturally. + Of course, in this case, the amount of plaintext that can be safely + protected by SIV is reduced by a commensurate amount -- addition + modulo 2^32 limits plaintext to (2^39 - 128) bits, addition modulo + 2^64 limits plaintext to (2^71 - 128) bits. + + It is possible to optimize an implementation of S2V when it is being + used as a key derivation function (KDF), for example in [WLAN]. This + is because S2V operates on a vector of distinct strings and typically + the data passed to a KDF contains constant strings. Depending on the + location of variant components of the input different optimizations + are possible. The CMACed output of intermediate and invariant + components can be computed once and cached. This can then be doubled + and xored with the running sum to produce the output. Or an + intermediate value that represents the doubled and xored output of + multiple components, up to the variant component, can be computed + once and cached. + +6. IANA Considerations + + [RFC5116] defines a uniform interface to cipher modes that provide + nonce-based Authenticated Encryption with Associated Data (AEAD). It + does this via a registry of AEAD algorithms. + + The Internet Assigned Numbers Authority (IANA) assigned three entries + from the AEAD Registry for AES-SIV-CMAC-256 (15), AES-SIV-CMAC-384 + (16), and AES-SIV-CMAC-512 (17) based upon the following AEAD + + + +Hawkins Informational [Page 15] + +RFC 5297 SIV-AES October 2008 + + + algorithm definitions. [RFC5116] defines operations in octets, not + bits. Limits in this section will therefore be specified in octets. + The security analysis for each of these algorithms is in [DAE]. + + Unfortunately, [RFC5116] restricts AD input to a single component and + limits the benefit SIV offers for dealing in a natural fashion with + AD consisting of multiple distinct components. Therefore, when it is + required to access SIV through the interface defined in [RFC5116], it + is necessary to marshal multiple AD inputs into a single string (see + Section 1.1) prior to invoking SIV. Note that this requirement is + not unique to SIV. All cipher modes using [RFC5116] MUST similarly + marshal multiple AD inputs into a single string, and any technique + used for any other AEAD mode (e.g., a scatter/gather technique) can + be used with SIV. + + [RFC5116] requires AEAD algorithm specifications to include maximal + limits to the amount of plaintext, the amount of associated data, and + the size of a nonce that the AEAD algorithm can accept. + + SIV uses AES in counter mode and the security guarantees of SIV would + be lost if the counter was allowed to repeat. Since the counter is + 128 bits, a limit to the amount of plaintext that can be safely + protected by a single invocation of SIV is 2^128 blocks. + + To prevent the possibility of collisions, [CMAC] recommends that no + more than 2^48 invocations be made to CMAC with the same key. This + is not a limit on the amount of data that can be passed to CMAC, + though. There is no practical limit to the amount of data that can + be made to a single invocation of CMAC, and likewise, there is no + practical limit to the amount of associated data or nonce material + that can be passed to SIV. + + A collision in the output of S2V would mean the same counter would be + used with different plaintext in counter mode. This would void the + security guarantees of SIV. The "Birthday Paradox" (see [APPCRY]) + would imply that no more than 2^64 distinct invocations to SIV be + made with the same key. It is prudent to follow the example of + [CMAC] though, and further limit the number of distinct invocations + of SIV using the same key to 2^48. Note that [RFC5116] does not + provide a variable to describe this limit. + + The counter-space for SIV is 2^128. Each invocation of SIV consumes + a portion of that counter-space and the amount consumed depends on + the amount of plaintext being passed to that single invocation. + Multiple invocations of SIV with the same key can increase the + possibility of distinct invocations overlapping the counter-space. + The total amount of plaintext that can be safely protected with a + + + + +Hawkins Informational [Page 16] + +RFC 5297 SIV-AES October 2008 + + + single key is, therefore, a function of the number of distinct + invocations and the amount of plaintext protected with each + invocation. + +6.1. AEAD_AES_SIV_CMAC_256 + + The AES-SIV-CMAC-256 AEAD algorithm works as specified in Sections + 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-256 as + defined by [RFC5116] are: + + K_LEN is 32 octets. + + P_MAX is 2^132 octets. + + A_MAX is unlimited. + + N_MIN is 1 octet. + + N_MAX is unlimited. + + C_MAX is 2^132 + 16 octets. + + The security implications of nonce reuse and/or misuse are described + in Section 1.3.2. + +6.2. AEAD_AES_SIV_CMAC_384 + + The AES-SIV-CMAC-384 AEAD algorithm works as specified in Sections + 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-384 as + defined by [RFC5116] are: + + K_LEN is 48 octets. + + P_MAX is 2^132 octets. + + A_MAX is unlimited. + + N_MIN is 1 octet. + + N_MAX is unlimited. + + C_MAX is 2^132 + 16 octets. + + The security implications of nonce reuse and/or misuse are described + in Section 1.3.2. + + + + + + +Hawkins Informational [Page 17] + +RFC 5297 SIV-AES October 2008 + + +6.3. AEAD_AES_SIV_CMAC_512 + + The AES-SIV-CMAC-512 AEAD algorithm works as specified in Sections + 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-512 as + defined by [RFC5116] are: + + K_LEN is 64 octets. + + P_MAX is 2^132 octets. + + A_MAX is unlimited. + + N_MIN is 1 octet. + + N_MAX is unlimited. + + C_MAX is 2^132 + 16 octets. + + The security implications of nonce reuse and/or misuse are described + in Section 1.3.2. + +7. Security Considerations + + SIV provides confidentiality in the sense that the output of SIV- + Encrypt is indistinguishable from a random string of bits. It + provides authenticity in the sense that an attacker is unable to + construct a string of bits that will return other than FAIL when + input to SIV-Decrypt. A proof of the security of SIV with an "all- + in-one" notion of security for an authenticated encryption scheme is + provided in [DAE]. + + SIV provides deterministic "key wrapping" when the plaintext contains + data that is unpredictable to an adversary (for instance, a + cryptographic key). Even when this key is made available to an + attacker the output of SIV-Encrypt is indistinguishable from random + bits. Similarly, even when this key is made available to an + attacker, she is unable to construct a string of bits that when input + to SIV-Decrypt will return anything other than FAIL. + + When the nonce used in the nonce-based authenticated encryption mode + of SIV-AES is treated with the care afforded a nonce or counter in + other conventional nonce-based authenticated encryption schemes -- + i.e., guarantee that it will never be used with the same key for two + distinct invocations -- then SIV achieves the level of security + described above. If, however, the nonce is reused SIV continues to + provide the level of authenticity described above but with a slightly + reduced amount of privacy (see Section 1.3.2). + + + + +Hawkins Informational [Page 18] + +RFC 5297 SIV-AES October 2008 + + + If S2V is used as a key derivation function, the secret input MUST be + generated uniformly at random. S2V is a pseudo-random function and + is not suitable for use as a random oracle as defined in [RANDORCL]. + + The security bound set by the proof of security of S2V in [DAE] + depends on the number of vector-based queries made by an adversary + and the total number of all components in those queries. The + security is only proven when the number of components in each query + is limited to n-1, where n is the blocksize of the underlying pseudo- + random function. The underlying pseudo-random function used here is + based on AES whose blocksize is 128 bits. Therefore, S2V must not be + passed more than 127 components. Since SIV includes the plaintext as + a component to S2V, that limits the number of components of + associated data that can be safely passed to SIV to 126. + +8. Acknowledgments + + Thanks to Phil Rogaway for patiently answering numerous questions on + SIV and S2V and for useful critiques of earlier versions of this + paper. Thanks also to David McGrew for numerous helpful comments and + suggestions for improving this paper. Thanks to Jouni Malinen for + reviewing this paper and producing another independent implementation + of SIV, thereby confirming the correctness of the test vectors. + +9. References + +9.1. Normative References + + [CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: The CMAC Mode for Authentication", NIST + Special Pulication 800-38B, May 2005. + + [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: Methods and Techniques", NIST Special + Pulication 800-38A, 2001 edition. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5116] McGrew, D., "An Interface and Algorithms for + Authenticated Encryption", RFC 5116, January 2008. + +9.2. Informative References + + [APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook + of Applied Cryptography", CRC Press Series on Discrete + Mathematics and Its Applications, 1996. + + + + +Hawkins Informational [Page 19] + +RFC 5297 SIV-AES October 2008 + + + [BADESP] Bellovin, S., "Problem Areas for the IP Security + Protocols", Proceedings from the 6th Usenix UNIX Security + Symposium, July 22-25 1996. + + [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with + CBC-MAC (CCM)", RFC 3610, September 2003. + + [DAE] Rogaway, P. and T. Shrimpton, "Deterministic + Authenticated Encryption, A Provable-Security Treatment + of the Key-Wrap Problem", Advances in Cryptology -- + EUROCRYPT '06 St. Petersburg, Russia, 2006. + + [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of + Operation (GCM)". + + [JUTLA] Jutla, C., "Encryption Modes With Almost Free Message + Integrity", Proceedings of the International Conference + on the Theory and Application of Cryptographic + Techniques: Advances in Cryptography. + + [OCB] Krovetz, T. and P. Rogaway, "The OCB Authenticated + Encryption Algorithm", Work in Progress, March 2005. + + [RADKEY] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS + Attributes for the Delivery of Keying Material", Work in + Progress, April 2007. + + [RANDORCL] Bellare, M. and P. Rogaway, "Random Oracles are + Practical: A Paradigm for Designing Efficient + Protocols", Proceeding of the First ACM Conference on + Computer and Communications Security, November 1993. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", + RFC 2548, March 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3217] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, + December 2001. + + + + + + +Hawkins Informational [Page 20] + +RFC 5297 SIV-AES October 2008 + + + [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard + (AES) Key Wrap Algorithm", RFC 3394, September 2002. + + [SP800-38D] Dworkin, M., "Recommendations for Block Cipher Modes of + Operation: Galois Counter Mode (GCM) and GMAC", NIST + Special Pulication 800-38D, June 2007. + + [VIRT] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder + than Real: Security Challenges in Virtual Machine Based + Computing Environments" In 10th Workshop on Hot Topics in + Operating Systems, May 2005. + + [WLAN] "Draft Standard for IEEE802.11: Wireless LAN Medium + Access Control (MAC) and Physical Layer (PHY) + Specification", 2007. + + [X9F1] Dworkin, M., "Wrapping of Keys and Associated Data", + Request for review of key wrap algorithms. Cryptology + ePrint report 2004/340, 2004. Contents are excerpts from + a draft standard of the Accredited Standards Committee, + X9, entitled ANS X9.102. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hawkins Informational [Page 21] + +RFC 5297 SIV-AES October 2008 + + +Appendix A. Test Vectors + + The following test vectors are for the mode defined in Section 6.1. + +A.1. Deterministic Authenticated Encryption Example + + Input: + ----- + Key: + fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0 + f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff + + AD: + 10111213 14151617 18191a1b 1c1d1e1f + 20212223 24252627 + + Plaintext: + 11223344 55667788 99aabbcc ddee + + S2V-CMAC-AES + ------------ + CMAC(zero): + 0e04dfaf c1efbf04 01405828 59bf073a + + double(): + 1c09bf5f 83df7e08 0280b050 b37e0e74 + + CMAC(ad): + f1f922b7 f5193ce6 4ff80cb4 7d93f23b + + xor: + edf09de8 76c642ee 4d78bce4 ceedfc4f + + double(): + dbe13bd0 ed8c85dc 9af179c9 9ddbf819 + + pad: + 11223344 55667788 99aabbcc ddee8000 + + xor: + cac30894 b8eaf254 035bc205 40357819 + + CMAC(final): + 85632d07 c6e8f37f 950acd32 0a2ecc93 + + + + + + + +Hawkins Informational [Page 22] + +RFC 5297 SIV-AES October 2008 + + + CTR-AES + ------- + CTR: + 85632d07 c6e8f37f 150acd32 0a2ecc93 + + E(K,CTR): + 51e218d2 c5a2ab8c 4345c4a6 23b2f08f + + ciphertext: + 40c02b96 90c4dc04 daef7f6a fe5c + + output + ------ + IV || C: + 85632d07 c6e8f37f 950acd32 0a2ecc93 + 40c02b96 90c4dc04 daef7f6a fe5c + +A.2. Nonce-Based Authenticated Encryption Example + + Input: + ----- + Key: + 7f7e7d7c 7b7a7978 77767574 73727170 + 40414243 44454647 48494a4b 4c4d4e4f + + AD1: + 00112233 44556677 8899aabb ccddeeff + deaddada deaddada ffeeddcc bbaa9988 + 77665544 33221100 + + AD2: + 10203040 50607080 90a0 + + Nonce: + 09f91102 9d74e35b d84156c5 635688c0 + + Plaintext: + 74686973 20697320 736f6d65 20706c61 + 696e7465 78742074 6f20656e 63727970 + 74207573 696e6720 5349562d 414553 + + + + + + + + + + + +Hawkins Informational [Page 23] + +RFC 5297 SIV-AES October 2008 + + + S2V-CMAC-AES + ------------ + CMAC(zero): + c8b43b59 74960e7c e6a5dd85 231e591a + + double(): + 916876b2 e92c1cf9 cd4bbb0a 463cb2b3 + + CMAC(ad1) + 3c9b689a b41102e4 80954714 1dd0d15a + + xor: + adf31e28 5d3d1e1d 4ddefc1e 5bec63e9 + + double(): + 5be63c50 ba7a3c3a 9bbdf83c b7d8c755 + + CMAC(ad2) + d98c9b0b e42cb2d7 aa98478e d11eda1b + + xor: + 826aa75b 5e568eed 3125bfb2 66c61d4e + + double(): + 04d54eb6 bcad1dda 624b7f64 cd8c3a1b + + CMAC(nonce) + 128c62a1 ce3747a8 372c1c05 a538b96d + + xor: + 16592c17 729a5a72 55676361 68b48376 + + xorend: + 74686973 20697320 736f6d65 20706c61 + 696e7465 78742074 6f20656e 63727966 + 2d0c6201 f3341575 342a3745 f5c625 + + CMAC(final) + 7bdb6e3b 432667eb 06f4d14b ff2fbd0f + + + + + + + + + + + + +Hawkins Informational [Page 24] + +RFC 5297 SIV-AES October 2008 + + + CTR-AES + ------- + CTR: + 7bdb6e3b 432667eb 06f4d14b 7f2fbd0f + + E(K,CTR): + bff8665c fdd73363 550f7400 e8f9d376 + + CTR+1: + 7bdb6e3b 432667eb 06f4d14b 7f2fbd10 + + E(K,CTR+1): + b2c9088e 713b8617 d8839226 d9f88159 + + CTR+2 + 7bdb6e3b 432667eb 06f4d14b 7f2fbd11 + + E(K,CTR+2): + 9e44d827 234949bc 1b12348e bc195ec7 + + ciphertext: + cb900f2f ddbe4043 26601965 c889bf17 + dba77ceb 094fa663 b7a3f748 ba8af829 + ea64ad54 4a272e9c 485b62a3 fd5c0d + + output + ------ + IV || C: + 7bdb6e3b 432667eb 06f4d14b ff2fbd0f + cb900f2f ddbe4043 26601965 c889bf17 + dba77ceb 094fa663 b7a3f748 ba8af829 + ea64ad54 4a272e9c 485b62a3 fd5c0d + +Author's Address + + Dan Harkins + Aruba Networks + + EMail: dharkins@arubanetworks.com + + + + + + + + + + + + +Hawkins Informational [Page 25] + +RFC 5297 SIV-AES October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Hawkins Informational [Page 26] + |