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

> I already did this. Check my branch. Do you think it should return "u32" (as you currently have it) or "unsigned long"? I thought the latter, since it doesn't cost any more and makes more > I wonder if this could also lead to a similar aliasing > with arch_get_random_int, since I'm pretty

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

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin wrote: > Ths advice I'd give now is: > - Implement > unsigned long hsiphash(const void *data, size_t len, const unsigned long > key[2]) > .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and >

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

> 64-bit security for an RNG is not reasonable even with rekeying. No no > no. Considering we already have a massive speed-up here with the > secure version, there's zero reason to start weakening the security > because we're trigger happy with our benchmarks. No no no. Just to clarify, I was

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: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 11:13 PM, George Spelvin wrote: > Remembering that on "real" machines it's full SipHash, then I'd say that > 64-bit security + rekeying seems reasonable. 64-bit security for an RNG is not reasonable even with rekeying. No no no. Considering we

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

On Fri, Dec 16, 2016 at 1:45 PM, Jason A. Donenfeld wrote: > Hi Andy, > > On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote: >> I think it would be nice to try to strenghen the PRNG construction. >> FWIW, I'm not an expert in PRNGs, and there's fairly

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

On Fri, Dec 16, 2016 at 2:13 PM, George Spelvin 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. >

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

> 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. This is tricky. The entire get_random_int() structure is an abuse of the hash function

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, Ted, I've made the requested changes. Keys now rotate and are per-CPU based. The chaining value is now additive instead of replacing. DavidL suggested I lower the velocity of `git-send-email` triggers, so if you'd like to take a look at this before I post v7, you can follow along at my

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote: > I think it would be nice to try to strenghen the PRNG construction. > FWIW, I'm not an expert in PRNGs, and there's fairly extensive > literature, but I can at least try. In an effort to keep this patchset

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: [PATCH v6 3/5] random: use SipHash in place of MD5

On Thu, Dec 15, 2016 at 7:03 PM, Jason A. Donenfeld wrote: > -static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) > - __aligned(sizeof(unsigned long)); > +static DEFINE_PER_CPU(u64, get_random_int_chaining); > [...] > unsigned long

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

Jason A. Donenfeld wrote: > I saw that jiffies addition in there and was wondering what it was all > about. It's currently added _after_ the siphash input, not before, to > keep with how the old algorithm worked. I'm not sure if this is > correct or if there's something wrong with that, as I

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: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 12:41 PM, George Spelvin wrote: > Tom Herbert wrote: >> Tested this. Distribution and avalanche effect are still good. Speed >> wise I see about a 33% improvement over siphash (20 nsecs/op versus 32 >> nsecs). That's about 3x of jhash speed (7

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

On Fri, Dec 16, 2016 at 9:17 PM, George Spelvin wrote: > My (speaking enerally; I should walk through every hash table you've > converted) opinion is that: > > - Hash tables, even network-facing ones, can all use hsiphash as long > as an attacker can only see

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

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

On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote: > > That's a nice analysis. Might one conclude from that that hsiphash is > > not useful for our purposes? Or does it still remain useful for > > network facing code? > > I think for attacks where the threat is a DoS, it's usable.

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

On Fri, Dec 16, 2016 at 9:41 PM, George Spelvin wrote: > What are you testing on? And what input size? And does "33% improvement" > mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate? How that I've published my hsiphash implementation to my tree,

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

Tom Herbert wrote: > Tested this. Distribution and avalanche effect are still good. Speed > wise I see about a 33% improvement over siphash (20 nsecs/op versus 32 > nsecs). That's about 3x of jhash speed (7 nsecs). So that might closer > to a more palatable replacement for jhash. Do we lose any

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

Hi JP, On Fri, Dec 16, 2016 at 2:22 PM, Jean-Philippe Aumasson wrote: > It needs some basic security review, which I'll try do next week (check for > security margin, optimality of rotation counts, etc.). But after a lot of > experience with this kind of

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

>> On a 64-bit machine, 64-bit SipHash is *always* faster than 32-bit, and >> should be used always. Don't even compile the 32-bit code, to prevent >> anyone accidentally using it, and make hsiphash an alias for siphash. > Fascinating! Okay. So I'll alias hsiphash to siphash on 64-bit then. I >

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

On Fri, Dec 16, 2016 at 4:39 AM, Jason A. Donenfeld wrote: > Hey JP, > > On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson > wrote: >> Here's a tentative HalfSipHash: >> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c >> >>

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

Hi George, On Fri, Dec 16, 2016 at 6:36 PM, George Spelvin wrote: > A 128-bit output option was added to SipHash after the initial publication; > this is just the equivalent in 32-bit. > Personally, I'd put in a comment saying that "there's a 64-bit output > variant

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

> It appears that hsiphash can produce either 32-bit output or 64-bit > output, with the output length parameter as part of the hash algorithm > in there. When I code this for my kernel patchset, I very likely will > only implement one output length size. Right now I'm leaning toward > 32-bit. A

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

Hi David, On Fri, Dec 16, 2016 at 6:06 PM, David Laight wrote: > A 32bit hash would also remove all the issues about the alignment > of IP addresses (etc) on 64bit systems. The current replacements of md5_transform with siphash in the v6 patch series will continue to

RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF

From: George Spelvin > Sent: 15 December 2016 23:29 > > If a halved version of SipHash can bring significant performance boost > > (with 32b words instead of 64b words) with an acceptable security level > > (64-bit enough?) then we may design such a version. > > I was thinking if the key could be

Re: [PATCH v5 3/4] secure_seq: use SipHash in place of MD5

Hi David, On Fri, Dec 16, 2016 at 10:59 AM, David Laight wrote: > You are still putting over-aligned data on stack. > You only need to align it to the alignment of u64 (not the size of u64). > If an on-stack item has a stronger alignment requirement than the stack > the

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

Hi JP & George, My function names: - SipHash -> siphash - HalfSipHash -> hsiphash It appears that hsiphash can produce either 32-bit output or 64-bit output, with the output length parameter as part of the hash algorithm in there. When I code this for my kernel patchset, I very likely will only

RE: [PATCH v5 2/4] siphash: add Nu{32,64} helpers

Jason A. Donenfeld wrote: > Isn't that equivalent to: > v0 = key[0]; > v1 = key[1]; > v2 = key[0] ^ (0x736f6d6570736575ULL ^ 0x646f72616e646f6dULL); > v3 = key[1] ^ (0x646f72616e646f6dULL ^ 0x7465646279746573ULL); (Pre-XORing key[] with the first two constants which, if

Re: algif for compression?

> > The compression interface is currently in a state of flux. We > should make it settle down first before exporting it to user-space. > > For a start it would be good to actually switch IPsec/IPcomp over > to the new compression interface. Thanks Herbert. Are there timelines or ongoing

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

Am Freitag, 16. Dezember 2016, 20:31:27 CET schrieb Herbert Xu: Hi Herbert, > > > > You are right, this will introduce a memleak. But with the immediate > > freeing of sreq->tsg in the current code, the AIO interface cannot > > support multiple IOCBs. > > > > Thus, the entire memory handling in

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

Hey JP, On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson wrote: > Here's a tentative HalfSipHash: > https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c > > Haven't computed the cycle count nor measured its speed. This is incredible. Really.

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

On Fri, Dec 16, 2016 at 01:27:50PM +0100, Stephan Müller wrote: > Am Freitag, 16. Dezember 2016, 19:54:36 CET schrieb Herbert Xu: > > Hi Herbert, > > > On Tue, Dec 13, 2016 at 09:42:45PM +0100, Stephan Müller wrote: > > > + /* > > > + * The async operation may have processed

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

Am Freitag, 16. Dezember 2016, 19:54:36 CET schrieb Herbert Xu: Hi Herbert, > On Tue, Dec 13, 2016 at 09:42:45PM +0100, Stephan Müller wrote: > > + /* > > +* The async operation may have processed only a subset of > > +* the data that was initially received from

Re: [PATCH v2] crypto: marvell - Copy IVDIG before launching partial DMA ahash requests

Romain Perier wrote: > Currently, inner IV/DIGEST data are only copied once into the hash > engines and not set explicitly before launching a request that is not a > first frag. This is an issue especially when multiple ahash reqs are > computed in parallel or

Re: [PATCH] crypto: AF_ALG - fix memory management of aio with multiple iocbs

On Tue, Dec 13, 2016 at 09:42:45PM +0100, Stephan Müller wrote: > > + /* > + * The async operation may have processed only a subset of > + * the data that was initially received from the caller. > + * Thus, we only can release the data that a

[no subject]

внимания; аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

RE: [PATCH v5 2/4] siphash: add Nu{32,64} helpers

From: Jason A. Donenfeld > Sent: 15 December 2016 20:30 > These restore parity with the jhash interface by providing high > performance helpers for common input sizes. ... > +#define PREAMBLE(len) \ > + u64 v0 = 0x736f6d6570736575ULL; \ > + u64 v1 = 0x646f72616e646f6dULL; \ > + u64 v2

RE: [PATCH v5 3/4] secure_seq: use SipHash in place of MD5

From: Jason A. Donenfeld > Sent: 15 December 2016 20:30 > This gives a clear speed and security improvement. Siphash is both > faster and is more solid crypto than the aging MD5. > > Rather than manually filling MD5 buffers, for IPv6, we simply create > a layout by a simple anonymous struct, for