RFC 5297 – Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)
Network Working Group D. Harkins
Request for Comments: 5297 Aruba Networks
Category: Informational October 2008
synthetic Initialization Vector ( SIV ) Authenticated encoding
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 20081. Introduction1.1. BackgroundBADESP]) 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 20081.2. DefinitionsRFC 2119 [RFC2119]. 1.3. Motivation1.3.1. Key WrappingRFC2865] 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/ReuseSP800-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 2008VIRT]). 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 DerivationWLAN]) 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 20081.3.4. Robustness versus PerformanceGCM] 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 Primitives2. Specification of SIV2.1. Notation Hawkins Informational [ Page 6 ]
RFC 5297 SIV-AES October 2008Section 2.3). a^b indicates a string that is "b" bits, each having the value "a".indicates a string that is 128 zero bits. 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. Overview2.3. Doubling Hawkins Informational [ Page 7 ]
RFC 5297 SIV-AES October 2008 Hawkins Informational [ Page 9 ]
RFC 5297 SIV-AES October 20082.5. CTR2.6. SIV EncryptSection 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 Hawkins Informational [ Page 11 ]
RFC 5297 SIV-AES October 2008Section 5. 2.7. SIV DecryptSection 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 Hawkins Informational [ Page 13 ]Read more: Dual_EC_DRBG - Wikipedia
RFC 5297 SIV-AES October 20084. Deterministic Authenticated Encryption with SIVRFC3394]. 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. OptimizationsWLAN]. 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 ConsiderationsRFC5116] 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 2008RFC5116] 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 20086.1. AEAD_AES_SIV_CMAC_256RFC5116] 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_384RFC5116] 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 20086.3. AEAD_AES_SIV_CMAC_512RFC5116] 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 ConsiderationsDAE]. 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 2008RANDORCL]. 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. Acknowledgments9. References9.1. Normative ReferencesCMAC] 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 ReferencesAPPCRY] 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 2008RFC3394] 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 2008A.2. Nonce-Based Authenticated Encryption Example Hawkins Informational [ Page 23 ]
RFC 5297 SIV-AES October 2008 Hawkins Informational [ Page 24 ]Read more: Ciphertext indistinguishability - Wikipedia
RFC 5297 SIV-AES October 2008 Hawkins Informational [ Page 25 ]
RFC 5297 SIV-AES October 2008BCP 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]