Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1543814

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

From "George Spelvin" <linux@sciencehorizons.net>
Newsgroups linux.kernel
Subject Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
Date 2016-12-16 23:50 +0100
Message-ID <sP9u9-1bb-5@gated-at.bofh.it> (permalink)
References <sP8oq-zl-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


An idea I had which mght be useful:

You could perhaps save two rounds in siphash_*u64.

The final word with the length (called "b" in your implementation)
only needs to be there if the input is variable-sized.

If every use of a given key is of a fixed-size input, you don't need
a length suffix.  When the input is an even number of words, that can
save you two rounds.

This requires an audit of callers (e.g. you have to use different
keys for IPv4 and IPv6 ISNs), but can save time.

(This is crypto 101; search "MD-strengthening" or see the remark on
p. 101 on Damgaard's 1989 paper "A design principle for hash functions" at
http://saluc.engr.uconn.edu/refs/algorithms/hashalg/damgard89adesign.pdf
but I'm sure that Ted, Jean-Philippe, and/or DJB will confirm if you'd
like.)

Jason A. Donenfeld wrote:
> Oh, okay, that is exactly what I thought was going on. I just thought
> you were implying that jiffies could be moved inside the hash, which
> then confused my understanding of how things should be. In any case,
> thanks for the explanation.

No, the rekeying procedure is cleverer.

The thing is, all that matters is that the ISN increments fast enough,
but not wrap too soon.

It *is* permitted to change the random base, as long as it only
increases, and slower than the timestamp does.

So what you do is every few minutes, you increment the high 4 bits of the
random base and change the key used to generate the low 28 bits.

The base used for any particular host might change from 0x10000000
to 0x2fffffff, or from 0x1fffffff to 0x20000000, but either way, it's
increasing, and not too fast.

This has the downside that an attacker can see 4 bits of the base,
so only needs to send send 2^28 = 256 MB to flood the connection,
but the upside that the key used to generate the low bits changes
faster than it can be broken.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-16 22:00 +0100
  Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF "George Spelvin" <linux@sciencehorizons.net> - 2016-12-16 22:30 +0100
    Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add  cryptographically secure PRF "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-16 22:40 +0100
      Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF "George Spelvin" <linux@sciencehorizons.net> - 2016-12-16 23:50 +0100

csiph-web