Re: [Cfrg] Extending SIV to other ciphers and MAC algorithms

I have had a look. As I understand it the only MRAE design still in the finalists is Deoxys-II, which is itself based on the AES round function.

— Neil

> On 4 Oct 2018, at 13:05, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
> 
> Dear Neil,
> 
> Speaking without my co-chair hat on: I think this could be interesting and useful. Have you by any chance looked at the portfolio of AEADs that has come out of the CAESAR competition to see if any of them would meet your needs?
> 
> https://competitions.cr.yp.to/caesar-submissions.html
> 
> Best wishes,
> 
> Kenny
> 
> 
> -----Original Message-----
> From: Cfrg <cfrg-bounces@irtf.org> on behalf of Neil Madden <neil.e.madden@gmail.com>
> Date: Thursday, 4 October 2018 at 11:12
> To: "cfrg@ietf.org" <cfrg@ietf.org>
> Subject: [Cfrg] Extending SIV to other ciphers and MAC algorithms
> 
>    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
> 
> 