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

Tony Arcieri <> Tue, 18 December 2018 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16669130F23 for <>; Tue, 18 Dec 2018 12:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dsCip77ONA13 for <>; Tue, 18 Dec 2018 12:34:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F893128D0C for <>; Tue, 18 Dec 2018 12:34:56 -0800 (PST)
Received: by with SMTP id u16so16958505otk.8 for <>; Tue, 18 Dec 2018 12:34:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w/WvYQ9smkvHK13cdOJV8OdWcsRoHGKLg0BNeBb5BwQ=; b=GopV3einvdO5FJwJbSkKXfmTstcbYXVwykiB09uMWWUeCKnNhn8Sk+Tdd+b1V1+0iF 3z6HeobAbWV3OdFqI4OWtlsATAvWAlX3hOESruKBAXpqCbdojpT83Mf7eF1X7TpqiE59 Un7PyMXC3XZfAPLRciRZP51hLmLtaYBgCn+e/wUM7uFDsmANXIqCc67ezR5xdm0gsIvi U+PbgmeIKyFd60XxwnxZbPu5mgrnGxht3x8txec2HtICfEpGOC4CJOD5oN2TyR1C0K6J Wtb0EqIjH+vudM/0cFLWd8k7cVBA49s6LQeG8lKwa4KCrgOkhBM/4jvbr8FH5JDklpZY YQvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w/WvYQ9smkvHK13cdOJV8OdWcsRoHGKLg0BNeBb5BwQ=; b=Mu3f4UQ46m+DPNOyXGM/6Ar71thSVBH4lpBFhUa+wcmdYO1NbamXdoS41Y9nUiVPOZ cTRGQCP+KYfizolKSSu2oQsW5qGA3qeYG2HfrUAlJcPxmS9DkJ4XXFxD5htOOfhpDbOa 8ZoeiL0BXTEDKw+G5+0WGOgmR5ELSIdb+N1IoBIFNQT1l9/LzfsDKMPSGjPXql+AdBrR 2Me2PVlBcycKGg8b0iQiUMD9JOZTKTB/6efni7egwPm+T8yNPxV4OYybwYmiNgXiV7IH ZgYnUp2/gUOo+XkNXXW0eb2M8GhXk2ibfa9RCjQbcOsWb2/qnzdAm4ScBqdYPlgniGev ybWw==
X-Gm-Message-State: AA+aEWZoQdBPPNyZ8czKXXk9oQj+Y4+NzONOf8TY53CxRJ1UQeLk4AXQ PBehRajYMbIoW7yHaB2/fmzxsqn2sayxpusWIrA=
X-Google-Smtp-Source: AFSGD/XkqcxlQm2W6eYDOzITae0TF0SW1v/GiC6EG+SHcwdV1G3A7x3pkQFrsK7fXx3z1FoH199UbVnESxPDpN9NypY=
X-Received: by 2002:a9d:3d24:: with SMTP id a33mr13663170otc.365.1545165295803; Tue, 18 Dec 2018 12:34:55 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tony Arcieri <>
Date: Tue, 18 Dec 2018 12:34:45 -0800
Message-ID: <>
To: Neil Madden <>
Cc: Mihir Bellare <>,
Content-Type: multipart/alternative; boundary="0000000000009366d3057d51d4af"
Archived-At: <>
Subject: Re: [Cfrg] Building a vector-input MAC by chained construction
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Dec 2018 20:34:59 -0000

On Tue, Dec 18, 2018 at 10:52 AM Neil Madden <>

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