Re: [Cfrg] SIV for non-AES ciphers first draft

Neil Madden <> Wed, 23 January 2019 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FFE5130E25 for <>; Wed, 23 Jan 2019 03:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, 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 kUT2B3eVKm1x for <>; Wed, 23 Jan 2019 03:31:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21FED128BCC for <>; Wed, 23 Jan 2019 03:31:41 -0800 (PST)
Received: by with SMTP id m1so1637912wml.2 for <>; Wed, 23 Jan 2019 03:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgz1L2bNtMGZg8HAyMPpz5cRxyPEd9UthbaaIGp1aMQ=; b=kM1pEzMOvYhpGiv3DZ5iwMgw/p1rO512bHy1BczEw30iKT59RH9j4U5ORs8WO9ZZSM mfqMz5gaIRsJkR8zl9Ov0YNaLlx9FMKFZcTUCb0WPfudLt99TggLMPr2PHrY7aqSS9aT rACYsa7LwjIl/I+vAW9jzRfcRlpP2hNyh76hBmqWLkYnBdIK7nhFc6n9wPU0b+F/UhOG wopu8WsPtF6vsiJsyhwgcFJs5vC8pzuT9ckF+wdtUquaZxK9JUwiPAW51tocN1Vil9t3 /0eM8BvzuDpbilJXye+Lh5DpE0teFvV4eld7qUl07EEyQ750Vysd/7zdG+qv1fYgqYie J8+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgz1L2bNtMGZg8HAyMPpz5cRxyPEd9UthbaaIGp1aMQ=; b=S6KmV/iYwW6DFPqIWQhwBzMFDdQ+EDAPiyCeSAfS7EXZ2h+fnYozrhHg+nf32kvLph ROGUNQp2ftZB4m2FsFfOpmp2QELG2Tv3uR5xcP+MpDIV9hBwjt71jBQJKCJs6oHcReSn l8S/cVynV2AeNkMNr9nmApT7ZNpZqu5zbndW00KuZ6hKE5o6tXsCaM9Ex6L5IdL0L+yu NwNwe3dISag5sVQ28rge5DVj4PMbqd9zpvbiPXWwMLqG3Zszx0PVYGNcunsNUeMsE/rK /YM2PVu5svcG0lzh+A8Tu+Q7wKQLZecwCmWJsQZ1Y6OJGqSD/HggPe+qfpK6Mwo7oid9 428A==
X-Gm-Message-State: AJcUukdZuRFhy4B66stgqdiGc4ZRTxtUqgsyGx5esZW4HbvskVVv6m62 2LGfgYzcIzJwPK2bjtwqJwI=
X-Google-Smtp-Source: ALg8bN7BUiGmGHVpayGxypkOYmiroGZrHLzcuUIktPFaZlcILcQVLeUpPHwxok46X8z6oIEfhHsbwQ==
X-Received: by 2002:a1c:d082:: with SMTP id h124mr2216766wmg.21.1548243099457; Wed, 23 Jan 2019 03:31:39 -0800 (PST)
Received: from guest2s-mbp.lan ( []) by with ESMTPSA id o16sm142113091wrn.11.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 03:31:38 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden <>
In-Reply-To: <>
Date: Wed, 23 Jan 2019 11:31:37 +0000
Cc: "Paterson, Kenny" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Tony Arcieri <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Cfrg] SIV for non-AES ciphers first draft
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: Wed, 23 Jan 2019 11:31:43 -0000

Hi Tony,

Comments in-line:

> On 22 Jan 2019, at 21:09, Tony Arcieri <> wrote:
> 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). 

The vector-input aspect of SIV/S2V is useful to me, so I’d 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.
> Though I didn't opine on this thread, I wrote a bit more of a long-form response to this draft here:
> 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 := KDF(k, nonce)
    tag := MAC*(k_mac, AD[0], …, AD[n], nonce, msg)
    siv := tag[0..IV_LEN]
    c = ENC(k_enc, siv, msg)
    return (c, tag)

You could then define the original RFC 5297 AES-SIV as:
 - KDF(k, nonce) = leftmost(k, KEY_LEN), rightmost(k, KEY_LEN)  [i.e., ignoring the nonce completely]
 - IV_LEN = 16

AES-GCM-SIV could be defined as:
 - KDF = the AES-based KDF described in the draft
 - MAC* = 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.
 - IV_LEN = 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’t an option for ChaCha20.

— Neil