[Cfrg] Farfalle-SANSE

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
>