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

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 21 Jan 2019 17:42:31 +0000

Dear CFRG,

This email begins a 2-week adoption call for draft-madden-generalised-siv available from

https://datatracker.ietf.org/doc/draft-madden-generalised-siv/

(with code at: https://github.com/NeilMadden/draft-madden-generalised-siv)

Please express your opinions on whether this draft should be adopted by CFRG or not.

Thanks,

Kenny (for the chairs)

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 22 Jan 2019 11:26:28 -0800

I support adoption of this draft as a WG item.

There are some alternative constructions I'd like to see explored, but I'd
be happy to help discuss/review and potentially even contribute to an I-D
on this topic.

On Mon, Jan 21, 2019 at 9:42 AM Paterson, Kenny <[email-masked]>
wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 22 Jan 2019 13:09:20 -0800

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

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:

https://mailarchive.ietf.org/arch/msg/cfrg/d4EgD1pNgKPVD61PYQumxqKkJxU

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.

-- 
Tony Arcieri

---

From: Neil Madden <[email-masked]>
Date: Wed, 23 Jan 2019 11:31:37 +0000

Hi Tony,

Comments in-line:

> On 22 Jan 2019, at 21:09, Tony Arcieri <[email-masked]> 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]
 - MAC* = S2V[AES-CMAC]
 - ENC= AES-CTR
 - 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.
 - ENC= AES-CTR
 - 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

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Jan 2019 07:41:12 -0800

On Wed, Jan 23, 2019 at 3:31 AM Neil Madden <[email-masked]> wrote:

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

That's the general idea, yes. I'm not saying it's the only way, but I think
it's worth exploring.

Really I mention this just in case other members of the group were getting
hung up on the details. We can hammer them out after the adoption call ;)

-- 
Tony Arcieri