CFRG S. Gueron
Internet-Draft University of Haifa and Intel Corporation
Intended status: Informational A. Langley
Expires: September 10, 2016 Google
Y. Lindell
Bar Ilan University
March 9, 2016
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryptiondraft-gueron-gcmsiv-02
Abstract
This memo specifies two authenticated encryption algorithms that are
nonce misuse-resistant - that is that they do not fail
catastrophically if a nonce is repeated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2016.
Copyright Notice
Copyright (c) 2016 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gueron, et al. Expires September 10, 2016 [Page 1]

Internet-Draft aes-gcm-siv March 2016
We suggest that these AEADs be considered in any situation where
there is the slightest doubt about nonce uniqueness.
2. Requirements Language
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].
3. POLYVAL
The GCM-SIV construction is similar to GCM: the block cipher is used
in counter mode to encrypt the plaintext and a polynomial
authenticator is used to provide integrity. The authenticator in
GCM-SIV is called POLYVAL.
POLYVAL, like GHASH, operates in a binary field of size 2^128. The
field is defined by the irreducible polynomial x^128 + x^127 + x^126
+ x^121 + 1. The sum of any two elements in the field is the result
of XORing them. The product of any two elements is calculated using
standard polynomial multiplication followed by reduction by the
irreducible polynomial.
We define another binary operation on elements of the field: dot(a,
b), where dot(a, b) = a * b * x^-128. The value x^-128 is equal to
x^127 + x^124 + x^121 + x^114 + 1. Since the result of
multiplications in the field is defined to be reduced, the result of
dot(a, b) is another field element.
Polynomials in this field are converted to and from 128-bit strings
by taking the least-significant bit of the first byte to be the
coefficient of x^0, the most-significant bit of the first byte to the
the coefficient of x^7 and so on, until the most-significant bit of
the last byte is the coefficient of x^127.
POLYVAL takes a field element, H, and a series of field elements X_1,
..., X_s. Its result is S_s, where S is defined by the iteration S_0
= 0; S_j = dot(S_{j-1} + X_j, H).
We note that POLYVAL(H, X_1, X_2, ...) is equal to
ByteSwap(GHASH(x*H, ByteSwap(X_1), ByteSwap(X_2), ...)), where
ByteSwap is a function that converts a field element to a 128-bit
string, reverses the order of the bytes, and interprets the result as
a field element again.
Gueron, et al. Expires September 10, 2016 [Page 3]

Internet-Draft aes-gcm-siv March 20164. Encryption
AES-GCM-SIV encryption takes a 16-byte authentication key, a 16- or
32-byte AES key, a 128-bit nonce, and arbitrary-length plaintext and
additional data inputs. It outputs an authenticated ciphertext that
will be 16 bytes longer than the plaintext.
If the AES key is 16 bytes long then define the _record-encryption
key_ as the encryption of the nonce using the AES key. If AES-256 is
being used then this is insufficient as 256 bits of key material are
needed. Therefore the record-encryption key in this case is the
concatenation of the result of encrypting, using the AES key, the
nonce with the least-significant bit of the first byte set to zero
and then to one.
Define the _length block_ as a 16-byte value that is the
concatenation of the 64-bit, little-endian encodings of
len(additional_length)*8 and len(plaintext)*8. Pad the plaintext and
additional data with zeros until they are each a multiple of 16
bytes, the AES block size. Then X_1, X_2, etc (the series of field
elements that are inputs to POLYVAL) are the concatenation of the
padded additional data, the padded plaintext and the length block.
Calculate S_s = POLYVAL(authentication_key, X_1, X_2, ...), XOR it
with the nonce and then set the most-significant bit of the last byte
to zero. Encrypt the result with AES using the record-encryption key
to produce the tag.
The ciphertext is produced by using AES in counter mode on the
unpadded plaintext. The initial counter is the tag with the most-
significant bit of the last byte set to one and the first 32 bits set
to zero. The counter advances by incrementing the first 32 bits
interpreted as an unsigned, little-endian integer. The result of the
encryption is the resulting ciphertext followed by the tag.
5. Decryption
Decryption takes a 16-byte authentication key, a 16- or 32-byte AES
key, a 128-bit nonce, and arbitrary-length ciphertext and additional
data inputs. It either fails, or outputs a plaintext that is 16
bytes shorter than the ciphertext.
Firstly, the record-encryption key is derived in the same manner as
when encrypting.
If the ciphertext is less than 16 bytes or more than 2^36 + 16 bytes,
then fail. Otherwise split the input into the encrypted plaintext
and a 16-byte tag. Decrypt the encrypted plaintext with the record-
Gueron, et al. Expires September 10, 2016 [Page 4]

Internet-Draft aes-gcm-siv March 2016
encryption key in counter mode, where the initial counter is the tag
with the most-significant bit of the last byte set to one and the
first 32 bits set to zero. The counter advances in the same way as
for encryption.
Pad the additional data and plaintext with zeros until they are each
a multiple of 16 bytes, the AES block size. Calculate length_block
and X_1, X_2, etc as above and compute S_s =
POLYVAL(authentication_key, X_1, X_2, ...). Compute the expected tag
by XORing S_s and the nonce, setting the most-significant byte of the
last byte to zero and encrypting with the record-encryption key.
Compare the provided and expected tag values in constant time. If
they do not match, fail. Otherwise return the plaintext.
6. AEADs
We define two AEADs, in the format of RFC 5116, that use AES-GCM-SIV:
AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV. They differ only in
the size of the AES key used.
Since the definition of an AEAD requires that the key be a single
value we define AEAD_AES_128_GCM_SIV to take a 32-byte key: the first
16 bytes of which are used as the authentication key and the
remaining 16 bytes are used as the AES key. Likewise
AEAD_AES_256_GCM_SIV takes an 48-byte key: the first 16 bytes are
again the authentication key and the remaining 32 bytes is the AES
key.
The parameters for AEAD_AES_128_GCM_SIV are then: K_LEN is 32, P_MAX
is 2^36, A_MAX is 2^61 - 1, N_MIN and N_MAX are 16 and C_MAX is 2^36
+ 16.
The parameters for AEAD_AES_256_GCM_SIV differ only in the key size:
K_LEN is 48, P_MAX is 2^36, A_MAX is 2^61 - 1, N_MIN and N_MAX are 16
and C_MAX is 2^36 + 16.
7. Field operation examples
Polynomials in this document will be written as 16-byte values. For
example, the sixteen bytes 01000000000000000000000000000492 would
represent the polynomial x^127 + x^124 + x^121 + x^114 + 1, which is
also the value of x^-128 in this field.
If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and b =
ff000000000000000000000000000000 then a+b =
99e94bd4ef8a2c3b884cfa59ca342b2e, a*b =
37856175e9dc9df26ebc6d6171aa0ae9 and dot(a, b) =
ebe563401e7e91ea3ad6426b8140c394.
Gueron, et al. Expires September 10, 2016 [Page 5]

Internet-Draft aes-gcm-siv March 20168. Worked example
Consider the encryption of the plaintext "Hello world" with the
additional data "example" under key
4f2229294acbdf99c4584ec0e6e23638fab3a110b8ae672eba07d91ba52d6cea
using AEAD_AES_128_GCM_SIV. The random nonce that we'll use for this
example is 752abad3e0afb5f434dc4310f71f3d21.
The record encryption key will be AES(key =
fab3a110b8ae672eba07d91ba52d6cea, data =
752abad3e0afb5f434dc4310f71f3d21) = b55e60e9e8886006db16db23e1e0e103.
The length block contains the encoding of the bit-lengths of the
additional data and plaintext, respectively, which are and 56 and 88.
Thus length_block is 38000000000000005800000000000000.
The input to POLYVAL is the padded additional data, padded plaintext
and then the length block. This is 6578616d706c650000000000000000004
8656c6c6f20776f726c64000000000058000000000000003800000000000000.
The POLYVAL key will be the first 16 bytes of the AEAD key, namely
4f2229294acbdf99c4584ec0e6e23638. Calling POLYVAL with that key and
the input above results in S_s = 0b9ae2c5bd7fe4dcd17a007d11ac280e.
XORing this with the nonce gives 7eb058165dd05128e5a6436de6b3152f.
Before encrypting the most-significant bit of the last byte is
cleared. This again gives 7eb058165dd05128e5a6436de6b3152f because
that bit happened to be zero already. Encrypting with the record key
gives the tag, which is 8e2d69ed54c0997cae05d8b2be1d963e.
In order to form the initial counter block, the most-significant bit
of the last byte of the tag is set to one and a 32-bit, little-endian
counter is written to the first four bytes. This gives
0000000054c0997cae05d8b2be1d96be. Encrypting this with the record
key gives the first block of the keystream:
b30b19ed9ba05d29b6aecc0146b7fb19.
The final ciphertext is the result of XORing the plaintext with the
keystream and appending the tag. That gives
fb6e7581f4802a46c4c2a88e2d69ed54c0997cae05d8b2be1d963e.
9. Security Considerations
The AEADs defined in this document calculate fresh AES keys for each
nonce. This allows a larger number of plaintexts to be encrypted
under a given key. Without this step, each SIV encryption would be
like a standard GCM encryption with a random nonce. Since the nonce
size for GCM is only 12 bytes, NIST set a limit [GCM] of 2^32
Gueron, et al. Expires September 10, 2016 [Page 6]

Internet-Draft aes-gcm-siv March 2016
encryptions before the probability of duplicate nonces becomes too
high.
The authors felt that, while large, 2^32 wasn't so large that this
limit could be safely ignored. For example, consider encrypting the
contents of a hard disk where the AEAD record size is 512 bytes, to
match the traditional size of a disk sector. This process would have
encrypted 2^32 records after processing 2TB, yet hard drives of
multiple terabytes are now common.
Deriving fresh AES keys for each nonce eliminates this problem.
It's worth noting that the 2^32 limit still applies as the number of
distinct messages that can be encrypted under a fixed nonce. Nonces
should be unique and the misuse-resistance of these AEADs should not
be depended on to the extent that 2^32 duplicates may occur. (Or
2^31 duplicates in the case of AEAD_AES_256_GCM_SIV.)
The construction of the record-encryption key in AEAD_AES_256_GCM_SIV
cannot result in the first and second halves of the key having the
same value. Thus 2^128 of the 2^256 keys cannot occur. We consider
this to be insignificant.
A security analysis of a similar scheme appears in [GCM-SIV].
10. IANA Considerations
This document has no actions for IANA.
11. Acknowledgements12. References12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP-
800-38D, November 2007,
<http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf>.
Gueron, et al. Expires September 10, 2016 [Page 7]