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: <CAHOTMVK76Acag9orV1O47y9C+UQmbXmEFyt3qpGwHPixUTNgHQ@mail.gmail.com>
Date: Wed, 19 Dec 2018 10:25:18 +0000
Cc: Mihir Bellare <mihir@eng.ucsd.edu>,
 cfrg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2831A1F7-C620-40E4-83BE-B5047BBE5864@gmail.com>
References: <A44A80BE-030B-4D1E-9889-F727EB0BF142@gmail.com>
 <CACEhwkQKHkHEyLbmZ6oeDtvuvmwgifyuTUsb6Xy1CDR+4RE9PA@mail.gmail.com>
 <F9E1D18B-2C9E-4ED1-8F23-C25A0A8AF2C6@gmail.com>
 <CAHOTMVK76Acag9orV1O47y9C+UQmbXmEFyt3qpGwHPixUTNgHQ@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/hGRLYDoDBxg7wVDgWtFy_wUmShg>
Subject: Re: [Cfrg] Building a vector-input MAC by chained construction
Precedence: list

|On 18 Dec 2018, at 20:34, Tony Arcieri <bascule@gmail.com> wrote:
>=20
> On Tue, Dec 18, 2018 at 10:52 AM Neil Madden <neil.e.madden@gmail.com> =
wrote:
> In the context of SIV, encrypting the last input prevents any further =
extension, as any extension will destroy the SIV rendering the plaintext =
undecryptable and the tag then unverifiable.
>=20
> This is true, although the presence of a length extension attack in =
what feels to me like something which could easily be a secure "vMAC" =
seems like something of a sharp edge, even if it isn't (at least as you =
claim to have proven) strictly necessary for this case..
> =20
> You=E2=80=99re right that as a general purpose MAC it would either =
need to have a fixed number of inputs or else encode the length into the =
first input.
>=20
> These things seem easy enough to add to this construction for =
"belt-and-suspenders" value, even in the context of a SIV mode.

I agree. I=E2=80=99ll park it for now, and maybe revisit it later.

>=20
> --
>=20
> A more general note (and I hope I'm not hijacking your thread here, =
let me know if you think I should make a new thread or feel free to =
respond in a separate one): I've implemented AES-SIV as specified in RFC =
5297, and also played around with swapping CMAC for PMAC resulting in a =
construction I've been calling "AES-PMAC-SIV".
>=20
> I've now implemented POLYVAL and am looking at implementing the rest =
of AES-GCM-SIV soon. In doing so, I see a lot of parts of the =
AES-GCM-SIV construction which are desirable over the RFC 5297 =
construction:
>=20
> - Deriving unique keys per message provides better-than-birthday-bound =
(BBB) security, and generally eliminates worries about long-term key =
usage. For SIV modes this is important because they're useful for =
keywrapping and in contexts like KMS services which hold a Key =
Encrypting Key and encrypting large numbers of Data Encrypting Keys. =
There was a talk at RealWorldCrypto this year by AWS about the =
challenges of doing this with AES-GCM, and the RFC 5297-specified =
AES-SIV suffers the same problem.

I agree that deriving a unique key for each message is useful. That is =
what XChaCha20 does too, after all.

Just to be clear though, even without beyond birthday bound security =
with AES-SIV you can encrypt 2^48 messages before you reach a 2^-32 =
chance of a collision - that=E2=80=99s over 281 trillion messages. =
Admittedly you don=E2=80=99t want to get close to that bound, but the =
birthday bound for a 128-bit block cipher is still quite a lot. It=E2=80=99=
s specifically GCM that has worse security bounds that limits to 2^32 =
messages.

(I=E2=80=99d need to dig into my notes to remember if these bounds are =
for messages or blocks, but for symmetric key-wrapping you are typically =
only encrypting one or two blocks anyway).

In my own sketches for JOSE improvements I specified that all usage of a =
key must go through one of HKDF (for symmetric) or ECDH (for public =
key). The main reason was not primarily a worry about overuse of a key =
(although I=E2=80=99d certainly sleep better at night), but rather so =
that I can feed in some context information so that if the same key is =
used for different purposes then separate keys will be derived with high =
probability.

> - Moving the SIV tag from the front to the end of the message, while =
precluding "streaming decryption", makes the overall construction less =
weird. When I talk about "weird": there are many in-place AEAD APIs in =
which you provide a buffer containing the plaintext and extra space to =
add the MAC tag. For the RFC 5297 construction, this involves putting =
this extra space at the beginning of a buffer and shifting the plaintext =
over. Doing this avoids the need for special case handling of "SIV modes =
as opposed to AEAD modes" in APIs and protocols: SIV modes can present =
an otherwise standard AEAD API which is potentially just a wrapper =
around a more powerful "SIV API=E2=80=9D.

I full agree with this. =E2=80=9CStreaming decryption=E2=80=9D is =
something of an anti-pattern anyway, as it is dangerous to release =
plaintext before you have verified the tag.

>=20
> I've tried various methods of abstracting over these differences, and =
I think I've mostly been successful in building abstractions that =
generalize over both constructions. However in doing so, and especially =
lately, I've been thinking a lot about how AES-GCM-SIV is probably a =
better framework for "new SIV modes", and am thinking about what a new =
AES-PMAC-SIV would look like which shares more of its design in common =
with AES-GCM-SIV.
>=20
> I think that's something you might consider with a ChaCha20 + Poly1305 =
SIV mode as well, especially as AES-GCM-SIV is already designed to work =
with a universal hash function. I'd be curious to hear your thoughts on =
this, especially if you can thing of any drawbacks for your particular =
use cases.

I think you=E2=80=99re probably right about this. I will re-read the =
AES-GCM-SIV papers and have a think about what is best practice here.

Kind regards,

Neil