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

Hi Ted, On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o wrote: > On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: >> >> - Ted, Andy Lutorminski and I will try to figure out a construction of >> >> get_random_long() that we all like. > > We don't have to find the

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

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

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

On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: > >> - Ted, Andy Lutorminski and I will try to figure out a construction of > >> get_random_long() that we all like. We don't have to find the most optimal solution right away; we can approach this incrementally, after all. So

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

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.

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

Hi George, On Fri, Dec 16, 2016 at 10:25 PM, George Spelvin wrote: > But yes, the sequence number is supposed to be (random base) + (timestamp). > In the old days before Canter & Siegel when the internet was a nice place, > people just used a counter that started at

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

On Fri, Dec 16, 2016, at 22:01, Jason A. Donenfeld wrote: > Yes, on x86-64. But on i386 chacha20 incurs nearly the same kind of > slowdown as siphash, so I expect the comparison to be more or less > equal. There's another thing I really didn't like about your chacha20 > approach which is that it

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

Hi Daniel, On Fri, Dec 16, 2016 at 9:44 PM, Daniel Micay wrote: > On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote: >> >> That's about 3x of jhash speed (7 nsecs). So that might closer >> to a more palatable replacement for jhash. Do we lose any security >> advantages

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

Hi Ted, On Fri, Dec 16, 2016 at 9:43 PM, Theodore Ts'o wrote: > What should we do with get_random_int() and get_random_long()? In > some cases it's being used in performance sensitive areas, and where > anti-DoS protection might be enough. In others, maybe not so much. > > If we

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

On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote: > > That's about 3x of jhash speed (7 nsecs). So that might closer > to a more palatable replacement for jhash. Do we lose any security > advantages with halfsiphash? Have you tested a lower round SipHash? Probably best to stick with the