]>
Synthetic IV (SIV) for non-AES ciphers and MACsForgeRockBroad Quay HousePrince StreetBristolBS1 4DJUnited Kingdomneil.madden@forgerock.com
Security
Internet-Draft
This document specifies how the Synthetic Initialization Vector (SIV) block cipher
mode of operation can be adapted to non-AES ciphers and message authentication
codes (MACs), with block sizes and MAC tag sizes other than 128 bits. Concrete
instantiations are defined using the XChaCha20 nonce-extended stream cipher
combined with HMAC-SHA256.
The Synthetic Initialization Vector (SIV) block cipher mode of operation provides either deterministic authenticated encryption (DAE) or
nonce-reuse misuse-resistant authenticated encryption (MRAE) .
It was originally specified for the combination of AES-CMAC for authenticity and
AES-CTR for confidentiality. The 128-bit AES-CMAC tag is used as the 128-bit (synthetic)
IV for AES-CTR. This document show how to apply SIV mode to ciphers and MACs with
IV and tag lengths other than 128 bits, including where the IV and tag length may
differ.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 when, and only when, they appear
in all capitals, as shown here.
Common IV-based authenticated encryption modes of operation require a unique
IV (or nonce) to be provided on each call to the encryption function with the same key.
If an IV is reused, either by accident or through malicious action, then some
combination of the confidentiality and/or authenticity properties is usually
lost. For the popular Galois Counter Mode (GCM) , NIST
states that "a breach of the requirement [...] for the uniqueness of the
initialization strings may compromise the security assurance almost entirely" (section 3
and Appendix A). The SIV mode of operation ,
when used with a unique nonce as part of the associated data, provides a measure
of protection against nonce reuse. If a nonce is reused with SIV mode then there
is no loss of authenticity, and a minimal loss of confidentiality: an attacker is
able to determine only whether the exact same message has been encrypted with the
same associated data and nonce using the same key.
While the SIV mode is specified as a generic composition of an IV-based encryption
scheme and a pseudorandom function (PRF), most uses of the mode have concentrated
on the one concrete instantiation of the mode given at the time: AES-SIV. AES-SIV
is built entirely from the AES block cipher, using AES-CMAC
as the PRF and AES in CTR mode for confidentiality. This combination is attractive
as it requires only an AES encryption operation to implement all aspects of the
mode. It also has the convenient property that AES-CMAC produces a 128-bit tag, and
AES-CTR requires a 128-bit IV, which allows the tag to be used directly as the
(synthetic) IV.
While AES-SIV has many attractive properties, there are good reasons for extending
SIV to other ciphers and PRFs. As stated in the rationale for adopting ChaCha20
and Poly1305 for IETF protocols , overreliance on a single
cipher design, however good, may cause difficulties if a weakness is ever
discovered in AES. Secondly, AES can be difficult to implement efficiently in
software while avoiding timing side-channels. Finally, there is the simple fact that
non-AES ciphers and PRFs exist and will continue to be used, and SIV mode is of
independent interest to users of those alternative primitives.
The generic SIV construction is defined in terms two primitive functions:
A PRF, F*, that takes a vector of strings as input.A length-preserving IV-based encryption scheme, E.
The S2V function can be used to build F* from a PRF, F, that takes a single
string input. The generalised version of this function is described in the next
section.
The following constants MUST be defined for any concrete instantiation of E and F*:
IV_LEN - the length of IV/nonce expected by E, in bits.TAG_LEN - the length of the output tag produced by F*, in bits.PRF_KEY_LEN - the length of key required for F*, in bits.CIPHER_KEY_LEN - the length of key required for E, in bits.
For any choice of E and F*, TAG_LEN MUST be greater than or equal to IV_LEN.
We denote the encryption operation of E as E.encrypt(key, iv, plaintext), and the
decryption operation as E.decrypt(key, iv, ciphertext).
Encryption takes as input a key, K, a plaintext P, and zero or more associated
data headers to be authenticated but not encrypted. The key K MUST be as long
as the sum of the key length of F* and the key length of E. For example, if
F* requires a 256-bit key and E requires a 128-bit key, then K must be
384 bits long.
Encryption proceeds as follows. Firstly, keys K1 and K2 are derived from K by
taking the leftmost PRF_KEY_LEN bits of K as K1, and the rightmost
CIPHER_KEY_LEN bits of K as K2. Secondly, the PRF F* is applied to K1, the
plaintext P, and all of the n associated data strings AD1, ..., ADn. This results
in an authentication tag, T. The SIV is defined as the leftmost IV_LEN bits of T.
If TAG_LEN = IV_LEN, then T is used in its entirety. The plaintext P is then
encrypted using E, with K2 as the key and SIV as the IV, producing ciphertext C.
The concatenation of T with C is returned as the output of the function.
In pseudocode, generalised SIV encryption is as follows:
Decryption takes as input a key, K, an authenticated ciphertext Z, and zero
or more associated data blocks to be authenticated but not decrypted.
Keys K1 and K2 are derived as for encryption. The leftmost TAG_LEN bits of Z
are taken as the tag T, while the remaining bits are the ciphertext C. As for
encryption, the SIV is taken as the leftmost IV_LEN bits of T.
The ciphertext C is then decrypted using E with the key K2 and
SIV as the IV, producing plaintext P. The expected authentication tag T' is then
computed using F* over the key K1, the associated data AD1, ..., ADn, and the
plaintext P. If T' exactly matches T then the plaintext P is returned. If T'
does not match T then the implementation MUST NOT return P and MUST destroy P and
T' and return a failure. Authentication tag comparisons SHOULD be performed in
constant time to avoid leaking the true value of T' through timing differences.
SIV requires a PRF that takes a vector of strings as input, while most
PRFs in current use are designed to only take a single string. In principle,
any unambiguous encoding can be used to convert a vector of inputs into
a single string, but SIV defines a particularly efficient encoding
provided by the function S2V (for "string to vector") that converts a
single-string PRF to a vector input PRF. S2V is defined
using bitwise exclusive OR (XOR) and a doubling operation in the finite field
GF(2^n) where n is the bit length of the output of the PRF. For AES-SIV,
which uses AES-CMAC as the PRF, this is GF(2^128). In this section we
show how to define S2V for PRFs with different tag lengths.
Points in the finite field GF(2^n) are represented as n-bit strings
a_(n-1) ... a_1 a_0, which can also be seen as binary coefficients for a polynomial
f(x) = a_(n-1) * x^(n-1) + ... + a_1 * x + a_0. Multiplication is then
defined as the product of two polynomials, with the remainder taken
after division by a fixed polynomial. In S2V, the fixed polynomial
is the lexicographically first minimum-weight primitive polynomial
(section 2). For GF(2^128), such a primitive polynomial is:
Primitive polynomials for other fields can be found in published tables, such
as . The following polynomials are indicated for
common PRF output sizes:
FieldPrimitive PolynomialGF(2^64)f(x) = x^64 + x^4 + x^3 + x + 1GF(2^96)f(x) = x^96 + x^10 + x^9 + x^6 + 1GF(2^128)f(x) = x^128 + x^7 + x^2 + x + 1GF(2^160)f(x) = x^160 + x^5 + x^3 + x^2 + 1GF(2^192)f(x) = x^192 + x^7 + x^2 + x + 1GF(2^224)f(x) = x^224 + x^9 + x^8 + x^3 + 1GF(2^256)f(x) = x^256 + x^10 + x^5 + x^2 + 1GF(2^384)f(x) = x^384 + x^12 + x^3 + x^2 + 1GF(2^512)f(x) = x^512 + x^8 + x^5 + x^2 + 1
Doubling for S2V is defined as multiplication with the binary value 0^(n-2)10 (i.e.,
the number 2 represented as an n-bit binary string). The doubling operation can
be efficiently implemented as a left-shift operation followed by a conditional
XOR with an n-bit constant derived from the binary coefficients of the primitive polynomial.
The condition being whether the most significant bit of the value being shifted off
is 1. For GF(2^128), the constant is 0^(120)10000111, with one bits corresponding
to x^7, x^2, x and 1 respectively. The following table lists the constants for common
PRF output sizes in binary and hexadecimal form. Leading zero octets are omitted from the
hexadecimal format.
FieldDoubling Constant - BinaryDoubling Constant - HexGF(2^64)0^(59)110110x1bGF(2^92)0^(150)11001000010x0321GF(2^128)0^(120)100001110x87GF(2^160)0^(154)1011010x2dGF(2^192)0^(184)100001110x87GF(2^224)0^(214)11000010010x0309GF(2^256)0^(245)100001001010x0425GF(2^384)0^(371)10000000011010x100dGF(2^256)0^(503)1001001010x0125
It is recommended that the conditional XOR be performed in constant time.
A constant time bit-sliced implementation is provided in Appendix A.
The S2V algorithm parameterised over a particular PRF, F, written S2V[F] is
as follows, where TAG_LEN is the output size of the PRF in bits, dbl(x) is the
appropriate doubling operation for TAG_LEN, and xorend is defined as in
. The constant <zero> is the TAG_LEN sequence of
all zero bits, and <one> is TAG_LEN-1 zero bits followed by a single 1 bit.
The function pad(X) pads the input to TAG_LEN bits by appending a single 1 bit
followed by as many 0 bits as necessary.
This section is non-normative.
The original AES-SIV mode of can be seen as
an instantiation of the generic SIV construction in this document,
with the following parameters:
F* = S2V[AES-CMAC]E = AES-CTR where the 31st and 63rd bits of the IV are zeroed prior to
use as described in section 2.5.PRF_KEY_LEN = 128, 192 or 256 bitsCIPHER_KEY_LEN = 128, 192 or 256 bits (to match PRF_KEY_LEN).IV_LEN = TAG_LEN = 128 bits.
ChaCha20 is a stream cipher that has been adopted for use in IETF protocols by
. It has several attractive properties, most notably that
it can be implemented efficiently in software and is relatively easy to make
resistant to cache-timing side-channel attacks. As originally specified, ChaCha20
takes a 256-bit key and a 64-bit nonce, which was extended to 96-bits when adopted
by the IETF. A 96-bit nonce is too small to be safely generated randomly (or
pseudorandomly as in SIV) without artificially limiting the number of messages
that can be encrypted with a single key. To address this problem, an extended nonce
variant known as XChaCha20 has been
proposed, which increase the nonce to 192-bits. This makes it an excellent choice
for an SIV instantiation, providing a MRAE cipher mode alternative to AES.
In principle, any PRF that produces at least a 192-bit output could be used with
XChaCha20. For concreteness, we specify the use of HMAC
with the SHA-256 secure hash function as HMAC-SHA256 is
widely implemented. The S2V function of section 2.3 is used to allow HMAC-SHA256
to take a vector of strings as input, with the primitive polynomial for GF(2^256)
used for point doubling and the leftmost 192 bits of the S2V[HMAC-SHA256] tag used
as the synthetic IV for XChaCha20.
The encryption and decryption procedures are as described in sections 2.1 and 2.2 above,
with the following constant values:
PRF_KEY_LEN = 256 bits.CIPHER_KEY_LEN = 256 bits.IV_LEN = 192 bits.TAG_LEN = 256 bits.
Test vectors for XChaCha20-HMAC-SHA256-SIV are provided in Appendix A.
This section registers AEAD algorithms as per the registry established in
. As specified in section
6, the interface of RFC 5116 only allows a single associated data (AD) component.
When SIV is accessed via this interface, multiple AD components must be
marshalled into a single string prior to calling the SIV procedures.
Need to get IANA to assign numbers for these.
The AEAD_XCHACHA20_SIV_HMAC_SHA256 algorithm is an instantiation of the generalised
SIV mode described in Sections 2.1 and 2.2 with the XChaCha20 extended-nonce
stream cipher and HMAC-SHA256 as the
PRF, as described in Section 3. XChaCha20 uses a 32-bit block counter and
a 512-bit block size, therefore the maximum size of plaintext that can be
encrypted in a single invocation is 2^38 octets, around 256 GB. The ciphertext
length is equal to the length of the plaintext plus 32 octets for the HMAC-SHA256
authentication tag (of which the leftmost 24 octets comprise the SIV).
The input and output lengths for AEAD_XCHACHA20_SIV_HMAC_SHA256 as defined by
are:
K_LEN is 64 octets.P_MAX is 2^38 octets.A_MAX is unlimited.N_MIN is 1 octet.N_MAX is unlimited.C_MAX is 2^38 + 32 octets.The security considerations of apply here.
The security proofs for SIV require that F* (and F if
constructing F* using S2V) behaves as a pseudorandom function (PRF). E must
be a length-preserving semantically-secure encryption scheme.
Section 4 of the DAE reference says that the encryption
scheme E (represented by a Greek upper-case pi symbol) is assumed to be
length-preserving for simplicity. I cannot see where this assumption is
discharged, so I assume that it is a requirement.
It is RECOMMENDED that SIV mode is always used with a unique random component included
as the last element of the header (associated data) to ensure semantic security. While
SIV mode loses a minimal amount of security if this component is omitted (or accidentally
reused), an attacker in this case is able to determine if the same plaintext has been
encrypted under the same key and with the same associated data. Depending on the application
this may still be a significant loss of confidentiality. For example, a service that
produces yes/no answers to questions would lose all confidentiality of its responses in
this case. The misuse resistance of SIV should be considered a failsafe and not as a
way to do without a nonce.
The requirement that E be length-preserving means that the ciphertext produced by SIV
mode will be equal in length to the input plaintext, plus the authentication tag (which
is of fixed size for any concrete instantiation of this mode). If the length of the
plaintext on its own may reveal information then care should be taken to obscure this
prior to encryption -- by padding to a known maximum length, for example. In the case
of the yes/no answer service the English words "yes" and "no" can be distinguished
purely by length, to give a simple example.
In , Chatterjee, Menezes and Sarkar show an attack on SIV
within the multi-user setting. It is RECOMMENDED that concrete instantiations intended
for such use define a MAC_KEY_LENGTH of at least 256 bits or describe other countermeasures.
The recommendation for a large MAC_KEY_LENGTH is based on the
comment made by Daniel Bleichenbacher to the CFRG mailing list:
https://mailarchive.ietf.org/arch/msg/cfrg/bnom-bt5wBPmdQfvbeYcus9gXP0
The number of components passed to any invocation of S2V (including the plaintext) must
not exceed TAG_LEN - 1. For example, a 128-bit PRF such as AES-CMAC should allow no more
than 127 components. For XChaCha20-HMAC-SHA256-SIV no more than 255 components should be
allowed.
&RFC5116;
&RFC5297;
&RFC8174;
&XCHACHA;
&RFC2104;
&RFC4493;
&RFC6234;
&RFC8439;
Deterministic Authenticated-Encryption. A Provable-Security Treatment of the Key-Wrap Problem.University of California at DavisPortland State UniversityThe SIV Mode of Operation for Deterministic Authenticated-Encryption
(Key Wrap) and Misuse-Resistant Nonce-Based Authenticated-Encryption.University of California at DavisPortland State UniversityRecommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.NISTTable of Low-Weight Binary Irreducible PolynomialsHewlett PackardAnother Look at TightnessIndian Institute of ScienceUniversity of WaterlooIndian Statistical Institute