Re: [Cfrg] Building a vector-input MAC by chained construction

[Tony Arcieri <[e-mail]>]

On Tue, Dec 18, 2018 at 10:52 AM Neil Madden <[e-mail]>
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.
>

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..


> You’re 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.
>

These things seem easy enough to add to this construction for
"belt-and-suspenders" value, even in the context of a SIV mode.

--

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".

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:

- 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.
- 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".

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.

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.