Re: [CFRG] SipHash recommendation?

[Jean-Philippe Aumasson <[e-mail]>]

This kind of claim without absolute evidence is usually how new symmetric
cryptography designs do. Unless you have a formal security proof with
reduction (rare in symkey), the best you can do is make security claims and
offer supporting arguments based on preliminary analysis and differential
cryptanalysis observations (as we have in the SipHash paper).

"I've not checked but believe": at the moment I only had time to do cursory
review and am not 100% sure of my claim's correctness, thus this
disclaimer. Sorry at the moment I don't have time to make an in-depth
review of these works.

There's been extensive discussions in the context of the Linux integration,
you may find them if you search in LKML archives.

SipHash was published in 2012 and we have evidence that some of the best
cryptanalysts in the world attempted to break it, so in my experience a
major cryptanalysis breakthrough is unlikely.







On Wed, Dec 16, 2020 at 5:34 PM Rene Struik <[e-mail]> wrote:

> My point was that one should not make all kind of claims and then not
> provide any supporting evidence. (It has, sadly, been a common refrain in
> some crypto papers, where it is hard for the reader to distinguish promise
> from overpromise/hype.)
>
> In the same vain, why reference subsequent papers as purported evidence if
> one adds disclaimer language "I've not checked but believe" in.
>
> For clarity: this does not mean SipHash is necessarily suspect, but
> perhaps there are some loose ends that, by uncareful language, may or may
> not have been brushed under the carpet.
>
> Rene
>
>
> On 2020-12-16 11:22 a.m., Jean-Philippe Aumasson wrote:
>
> The security goal of a PRF is to be indistinguishable from a random
> function, according to some formal and precise definition. I've not checked
> but I believe that these papers' distinguishers fall in this category (as
> opposed, for example, to "known-key distinguishers").
>
> AFAIU, these results don't seem to violate the claim of
> indistinguishability on Siphash-2-4 or 4-8.
>
> One limitation of SipHash is its tag size (64 bits). We've a 128-bit
> version in the github repo, but it's not in the paper, and arguably less
> analyzed than the original. Linux also has this "halfsiphash".
>
> What's important to keep in mind is that SipHash is a PRF/MAC, not a hash
> function (probably bad name choice), and should thus not be used as an
> unkeyed hash (unless you dont worry about collision resistance).
>
>
>
> On Wed, Dec 16, 2020 at 5:17 PM Rene Struik <[e-mail]> wrote:
>
>> 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
>> and
>>
>> https://askworkshop.github.io/ask2019/assets/slides/ask2019talk_yunwenliu.pdf
>>
>> Summary tables below, where distinguishers are the type of attacks
>> related to indistinguishabilty:
>>
>> [image: image.png]
>> [image: image.png]
>>
>> On Wed, Dec 16, 2020 at 4:59 PM Rene Struik <[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
>>>
>>> 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), 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]> 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/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]
>>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>>
>>>
>>> _______________________________________________
>>> CFRG mailing [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>> --
>>> email: [e-mail] | Skype: rstruik
>>> cell: [phone] | US: [phone]
>>>
>>>
>> --
>> email: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]
>>
>>
> --
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
>
>