Re: [Cfrg] Farfalle-SANSE

Hi Gilles,

I'm interested in this construction but I'd like to know more. What sort of
applications do you think this function would have within the IETF? Would
it be useful as a general replacement for PRFs in, for example, TLS? Can it
leverage hardware-specific instructions?

Best,
Nick

On Fri, Nov 2, 2018 at 5:34 AM Gilles Van Assche <gilles.vanassche@st.com>
wrote:

> Dear all,
>
> On a related note, we published at ToSC last year (and presented at FSE
> 2018) the Kravatte pseudo-random function [1], to which an SIV mode can
> be attached. More specifically, we recently specified the SIV-based
> authenticated encryption scheme Kravatte-SANSE [2]. As a feature, it
> also supports sessions, for use cases where multiple messages are
> exchanged and where each tag authenticates all messages already sent so
> far in the session.
>
> This function is based on the 6-round Keccak-p permutation and performs
> well in software without AES hardware acceleration. For instance,
> Kravatte-SANSE processes plaintext and metadata at 1.32 cycles/byte on
> Skylake and at 0.84 c/b on SkylakeX processors.
>
> Would this be of interest to CFRG?
>
> Kind regards,
> Guido, Joan, Seth, Michaël, Gilles and Ronny
>
> [1] https://tosc.iacr.org/index.php/ToSC/article/view/855
> [2] https://keccak.team/2018/kravatte_sane_sanse.html
>
>
> On 4/10/18 12:12, Neil Madden wrote:
> > Hi,
> >
> > I am interested in adapting the SIV construction to other ciphers and
> MAC algorithms. As currently specified in RFC 5297, the mode is only
> defined for a MAC (AES-CMAC) that produces a 128-bit tag length.
> Furthermore, it assumes that the tag length is exactly the same as the
> nonce/IV required by the cipher (i.e., also 128-bits for AES-CTR). This
> restriction to limit the authentication strength of the AEAD based on the
> length of the required nonce for confidentiality seems somewhat artificial
> to me.
> >
> > As a concrete example, I am interested in SIV constructions based on
> XSalsa20 (or XChaCha20 as recently proposed on this list) together with
> some keyed hash MAC, such as HMAC-SHA256 or Blake2. XSalsa20 requires a
> nonce of 192-bits, while HMAC-SHA256 produces a MAC tag of 256 bits. I have
> a draft recommending MRAE modes for JOSE, and would like to include one
> non-AES algorithm that can be implemented well in software on platforms
> without AES hardware acceleration.
> >
> > I believe that there are just two adaptions needed to make this work:
> >
> > 1. Adjusting the conditional XOR constant used in the doubling operation
> in s2v (https://tools.ietf.org/html/rfc5297#section-2.3) to account for
> other field sizes.
> > 2. Defining the nonce used as input to the cipher as the left-most n
> bits of the authentication tag returned from s2v, where n is the size of
> the nonce required by the cipher (i.e., the full tag is output, but a
> truncation of it is used as the nonce).
> >
> > For step 1, based on the comments in [1] and the table of primitive
> polynomials from [2], I think the polynomials and corresponding constants
> to use for different values of n (bit length of MAC output) are:
> >
> > n = 128 gives x^128 + x^7 + x^2 + x + 1 and constant = 0^{120}10000111
> (= 0x87 with leading 0s)
> > n = 192 gives x^192 + x^7 + x^2 + x + 1 and constant = 0^{184}10000111
> (= 0x87 with more leading 0s)
> > n = 256 gives x^256 + x^10 + x^5 + x^2 + 1 and constant =
> 0^{245}10000100101 (= 0x00..0425)
> >
> > Is this something that CFRG might support if I submitted a draft?
> >
> > Regards,
> >
> > Neil
> >
> > [1]: http://web.cs.ucdavis.edu/~rogaway/papers/siv.pdf
> > [2]:
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.365.1806&rep=rep1&type=pdf
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> >
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>