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

[Neil Madden <[e-mail]>]

Hi Tony,

Comments in-line:

> On 22 Jan 2019, at 21:09, Tony Arcieri <[e-mail]> 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:
> 
> 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.

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