Re: [CFRG] SipHash recommendation?

[Rene Struik <[e-mail]>]

Hi Jean-Philippe:

So, it seems your 2012 paper does not provide any evidence of the 
indistinguishability claim in the introduction hereof, but there has 
been some subsequent work in this direction (your 2019 pointers). Isn't 
an indistinguishability claim different from an attack actually building 
a distinguisher with high complexity?

Best regards, Rene

On 2020-12-16 11:05 a.m., Jean-Philippe Aumasson wrote:
> The most recent results are these 2019 works:
>
> https://eprint.iacr.org/2019/865.pdf 
> <https://eprint.iacr.org/2019/865.pdf>
> and
> https://askworkshop.github.io/ask2019/assets/slides/ask2019talk_yunwenliu.pdf 
> <https://askworkshop.github.io/ask2019/assets/slides/ask2019talk_yunwenliu.pdf>
>
> Summary tables below, where distinguishers are the type of attacks 
> related to indistinguishabilty:
>
> image.png
> image.png
>
> On Wed, Dec 16, 2020 at 4:59 PM Rene Struik <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Jean-Philippe:
>
>     Section 3 of the SipHash paper [1] writes "We define SipHash-c-d
>     for smaller c and d to provide targets for cryptanalysis.
>     Cryptanalysts are thus invited to break", while Section 1 writes
>     "Our concrete proposal SipHash-2-4 was designed and evaluated to
>     be a cryptographically strong PRF (pseudorandom function), i.e.,
>     indistinguishable from a uniform random function.
>     This implies its strength as a MAC."
>
>     I am curious about the cryptanalysis that went into supporting the
>     indistinguishability claim. From a cursory look at [1] and [2] I
>     could not immediately find this.
>
>     Is indistinguishability the (or one of the) "security goals"
>     alluded to, but not mentioned, on the last slide of the
>     presentation [2]?
>
>     Best regards, Rene
>
>     Ref:
>     [1] Hash Functions - SipHash, A Fast Short-Input PRF
>     (Jean-Philippe Aumasson, Daniel Bernstein, DIAC 2012)
>     [2] https://cr.yp.to/talks/2012.12.12/slides.pdf
>     <https://cr.yp.to/talks/2012.12.12/slides.pdf>
>
>     On 2020-12-16 9:58 a.m., Jean-Philippe Aumasson wrote:
>>     SipHash co-author here, that draft uses the 2-4 versions (like
>>     the Linux kernel,
>>     https://www.kernel.org/doc/html/latest/security/siphash.html
>>     <https://www.kernel.org/doc/html/latest/security/siphash.html>),
>>     which has lower security margin than 4-8, but I’m not aware of
>>     any cryptanalysis result that would affect any of these in the
>>     context of this proposed application.
>>
>>
>>
>>     On Wed 16 Dec 2020 at 01:03, Benjamin Kaduk <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi all,
>>
>>         We have a document (draft-ietf-dnsop-server-cookies) in front
>>         of the IESG
>>         that proposes to use the SipHash-2-4 algorithm
>>         (https://www.aumasson.jp/siphash/
>>         <https://www.aumasson.jp/siphash/>,
>>         https://www.aumasson.jp/siphash/siphash.pdf
>>         <https://www.aumasson.jp/siphash/siphash.pdf>) as a MAC over
>>         what is in some
>>         sense a return-routability and freshness token, the "DNS
>>         cookie" originally
>>         specified in RFC 7873.
>>
>>         Unfortunately, the authors of this draft have not yet written
>>         down a clear
>>         description of what properties they believe are needed from
>>         this MAC for
>>         this usage, which makes it slightly hard to confirm that
>>         SipHash is a
>>         suitable algorithm for this purpose, though that is certainly
>>         a question
>>         that I am interested in.
>>
>>         Regardless of that, I would also like to get the CFRG's input
>>         on whether
>>         SipHash is a suitable algorithm for its stated goals
>>         (paraphrasing
>>         slightly): a performant keyed (family of) PRF suitable for
>>         use as a MAC,
>>         with the security goal for a MAC being considered to be that
>>         an attacker,

>>         even after seeing tags for many messages (perhaps selected by the
>>         attacker), is unable to guess tags for any other messages.
>>
>>         In short: is SipHash fit for this purpose?
>>
>>         There does seem to be a decent amount of literature analyzing
>>         SipHash, but
>>         I have not attempted to review it to any significant degree.
>>
>>         Thanks,
>>
>>         Ben
>>
>>         _______________________________________________
>>         CFRG mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.irtf.org/mailman/listinfo/cfrg
>>         <https://www.irtf.org/mailman/listinfo/cfrg>
>>
>>
>>     _______________________________________________
>>     CFRG mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.irtf.org/mailman/listinfo/cfrg  <https://www.irtf.org/mailman/listinfo/cfrg>
>
>
>     -- 
>     email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>     cell: [phone] | US: [phone]
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]