Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden <neil.e.madden@gmail.com>
In-Reply-To: <CAHOTMVLLK2XaywpHTXjozzeTEBKnzpJu+DtD8FxZvw_XM3CMig@mail.gmail.com>
Date: Wed, 23 Jan 2019 11:31:37 +0000
Cc: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>,
 "cfrg@irtf.org" <cfrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <66FC66E5-4004-4141-BB88-FF2CC0425FB2@gmail.com>
References: <0D91AF7A-F26F-4E20-A009-B7D75BF8107D@gmail.com>
 <D78B82CF-7C62-41AB-8D65-ABD409618B7A@rhul.ac.uk>
 <E2CFB0E2-4F2A-4520-9735-03CF7A096070@gmail.com>
 <9A644EC9-97B5-4330-95C8-A4AC57F17EAC@rhul.ac.uk>
 <0AE677D2-AFF2-4D0F-89E3-04E304CFBC3A@gmail.com>
 <7BC3E788-0D90-4736-A339-B5BFA1CC0416@rhul.ac.uk>
 <CAHOTMV+82dLWgMEtg-sFYbp1_mhLWF0yY=QfUAqcUgQi44gt5w@mail.gmail.com>
 <CAHOTMVLLK2XaywpHTXjozzeTEBKnzpJu+DtD8FxZvw_XM3CMig@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MkfM7iF6wAsiLm6OuR4XDQi43LU>
Subject: Re: [Cfrg] SIV for non-AES ciphers first draft
Precedence: list

Hi Tony,

Comments in-line:

> On 22 Jan 2019, at 21:09, Tony Arcieri <bascule@gmail.com> wrote:
>=20
> Perhaps I should add: specifically what I would like to see is a =
generalized framework for SIV modes and some new instantiations of that =
framework, and perhaps one which looks a little more like =
draft-irtf-cfrg-gcmsiv than what is presently in this draft (which looks =
a lot more like RFC 5297) .

It may be difficult to have one RFC that describes a generalised version =
of both algorithms. While draft-irtf-cfrg-gcmsiv is SIV-like, in =
practice the interface is quite different. AES-SIV (RFC 5297) takes a =
vector of additional data strings (one of which can be an arbitrary-size =
nonce), while draft-irtf-cfrg-gcmsiv takes just one additional data =
string and requires an explicit nonce (of a fixed size).=20

The vector-input aspect of SIV/S2V is useful to me, so I=E2=80=99d =
rather not drop it entirely. You could apply S2V to POLYVAL (and =
Poly1305) though.

> More concretely I'm thinking of a framework which could describe both =
AES-GCM-SIV and a new concrete instantiation using (X)ChaCha20. Since =
AES-GCM-SIV is already designed to work with a universal hash function, =
I think such a construction could potentially be paired with Poly1305, =
which seems like a more natural pairing to me.
>=20
> Though I didn't opine on this thread, I wrote a bit more of a =
long-form response to this draft here:
>=20
> https://mailarchive.ietf.org/arch/msg/cfrg/d4EgD1pNgKPVD61PYQumxqKkJxU
>=20
> This is all to say: I like the spirit of this draft, but I can see why =
people might be a bit off-put by the particular details of the current =
proposal.

Is the following a fair summary of what you would like to see included?

1. Include a KDF to derive per-message keys from an explicit nonce, =
rather than taking a single key that is split into two halves.

2. Move the SIV to be appended to the ciphertext rather than prepended.

3. Describe how to instantiate an SIV mode with a universal hash =
function using the approach from AES-GCM-SIV.

Would a generic description that looked something like the following fit =
the bill?

func SIV-Encrypt[KDF, ENC, MAC*](key, AD[0..n], nonce, msg) {
    k_mac, k_enc :=3D KDF(k, nonce)
    tag :=3D MAC*(k_mac, AD[0], =E2=80=A6, AD[n], nonce, msg)
    siv :=3D tag[0..IV_LEN]
    c =3D ENC(k_enc, siv, msg)
    return (c, tag)
}

You could then define the original RFC 5297 AES-SIV as:
 - KDF(k, nonce) =3D leftmost(k, KEY_LEN), rightmost(k, KEY_LEN)  [i.e., =
ignoring the nonce completely]
 - MAC* =3D S2V[AES-CMAC]
 - ENC=3D AES-CTR
 - IV_LEN =3D 16

AES-GCM-SIV could be defined as:
 - KDF =3D the AES-based KDF described in the draft
 - MAC* =3D the POLYVAL scheme described in the draft, with the =
limitation that there can only be a single AD, with the tag encrypted as =
described in section 4.
 - ENC=3D AES-CTR
 - IV_LEN =3D 16

ChaCha20-Poly1305-SIV could then be relatively straightforwardly defined =
using HChaCha for the KDF, although the tag encryption would need some =
thought as AES-GCM-SIV encrypts it with the raw AES block cipher (i.e., =
ECB) which isn=E2=80=99t an option for ChaCha20.

=E2=80=94 Neil=