Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 6:41 AM, Theodore Ts'o wrote: > The bottom line is that I think we're really "pixel peeping" at this > point --- which is what obsessed digital photographers will do when > debating the quality of a Canon vs Nikon DSLR by blowing up a photo by > a

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin wrote: > Andy Lutomirski wrote: >> I don't even think it needs that. This is just adding a >> non-destructive final operation, right? > > It is, but the problem is that SipHash is intended for *small* inputs, > so the

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > Funny -- while you guys were sending this back & forth, I was writing > my reply to Andy which essentially arrives at the same conclusion. > Given that we're all arriving to the same thing, and that Ted shot in > this

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Andy Lutomirski wrote: > I don't even think it needs that. This is just adding a > non-destructive final operation, right? It is, but the problem is that SipHash is intended for *small* inputs, so the standard implementations aren't broken into init/update/final functions. There's just one big

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

Hi George, On Thu, Dec 22, 2016 at 4:55 AM, George Spelvin wrote: > Do we have to go through this? No, the benchmark was *not* bogus. > Then I replaced the kernel #includes with the necessary typedefs > and #defines to make it compile in user-space. > * I didn't

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

> Plus the benchmark was bogus anyway, and when I built a more specific > harness -- actually comparing the TCP sequence number functions -- > SipHash was faster than MD5, even on register starved x86. So I think > we're fine and this chapter of the discussion can come to a close, in > order to

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 3:49 AM, Jason A. Donenfeld wrote: > I did have two objections to this. The first was that my SipHash > construction is faster. But in any case, they're both faster than the > current MD5, so it's just extra rice. The second, and the more > important one,

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Andy & Hannes, On Thu, Dec 22, 2016 at 3:07 AM, Hannes Frederic Sowa wrote: > I wonder if Ted's proposal was analyzed further in terms of performance > if get_random_int should provide cprng alike properties? > > For reference: https://lkml.org/lkml/2016/12/14/351

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin >> After some thinking, I still like the "state-preserving" construct >> that's equivalent to the current MD5 code. Yes, we could just do >> siphash(current_cpu || per_cpu_counter, global_key), but it's nice to >> preserve a bit more. >> >> It

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Andy, On Thu, Dec 22, 2016 at 12:42 AM, Andy Lutomirski wrote: > So this is probably good enough, and making it better is hard. Changing it > to: > > u64 entropy = (u64)random_get_entropy() + current->pid; > result = siphash(..., entropy, ...); > secret->chaining +=

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Wed, Dec 21, 2016 at 6:07 PM, Hannes Frederic Sowa wrote: > On 22.12.2016 00:42, Andy Lutomirski wrote: >> On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: >>> unsigned int get_random_int(void) >>> { >>> - __u32 *hash; >>> -

George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin wrote: > As a separate message, to disentangle the threads, I'd like to > talk about get_random_long(). > > After some thinking, I still like the "state-preserving" construct > that's equivalent to the current MD5 code.

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 00:42, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: >> unsigned int get_random_int(void) >> { >> - __u32 *hash; >> - unsigned int ret; >> - >> - if (arch_get_random_int()) >> - return ret; >> -

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 9:25 AM, Linus Torvalds wrote: > On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin > wrote: >> >> How much does kernel_fpu_begin()/kernel_fpu_end() cost? > > It's now better than it used to be, but it's absolutely

Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF

On Thu, Dec 22, 2016 at 2:40 AM, Stephen Hemminger wrote: > The networking tree (net-next) which is where you are submitting to is > technically > closed right now. That's okay. At some point in the future it will be open. By then v83 of this patch set will be shiny

Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF

On Thu, 22 Dec 2016 00:02:11 +0100 "Jason A. Donenfeld" wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function, or as a > general

Re: HalfSipHash Acceptable Usage

As a separate message, to disentangle the threads, I'd like to talk about get_random_long(). After some thinking, I still like the "state-preserving" construct that's equivalent to the current MD5 code. Yes, we could just do siphash(current_cpu || per_cpu_counter, global_key), but it's nice to

Re: [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables

> 64-bit x86_64: > [0.509409] test_siphash: SipHash2-4 cycles: 4049181 > [0.510650] test_siphash: SipHash1-3 cycles: 2512884 > [0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920 > [0.512904] test_siphash:JenkinsHash cycles: 978267 I'm not sure what these numbers

Re: HalfSipHash Acceptable Usage

Theodore Ts'o wrote: > On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: >> SipHash annihilates the competition on 64-bit superscalar hardware. >> SipHash dominates the field on 64-bit in-order hardware. >> SipHash wins easily on 32-bit hardware *with enough registers*. >> On

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: > unsigned int get_random_int(void) > { > - __u32 *hash; > - unsigned int ret; > - > - if (arch_get_random_int()) > - return ret; > - > - hash = get_cpu_var(get_random_int_hash); >

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 12:02 AM, Jason A. Donenfeld wrote: > This duplicates the current algorithm for get_random_int/long I should have mentioned this directly in the commit message, which I forgot to update: this v7 adds the time-based key rotation, which, while not

[PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables

HalfSipHash, or hsiphash, is a shortened version of SipHash, which generates 32-bit outputs using a weaker 64-bit key. It has *much* lower security margins, and shouldn't be used for anything too sensitive, but it could be used as a hashtable key function replacement, if the output is never

[PATCH v7 5/6] syncookies: use SipHash in place of SHA1

SHA1 is slower and less secure than SipHash, and so replacing syncookie generation with SipHash makes natural sense. Some BSDs have been doing this for several years in fact. The speedup should be similar -- and even more impressive -- to the speedup from the sequence number fix in this series.

[PATCH v7 2/6] secure_seq: use SipHash in place of MD5

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 which gcc generates rather efficient code. For IPv4, we pass the

[PATCH v7 3/6] random: use SipHash in place of MD5

This duplicates the current algorithm for get_random_int/long, but uses siphash instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also separates hashed fields into three values instead of one, in order to increase diffusion.

[PATCH v7 4/6] md5: remove from lib and only live in crypto

The md5_transform function is no longer used any where in the tree, except for the crypto api's actual implementation of md5, so we can drop the function from lib and put it as a static function of the crypto file, where it belongs. There should be no new users of md5_transform, anyway, since

[PATCH v7 1/6] siphash: add cryptographically secure PRF

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first

[PATCH v7 0/6] The SipHash Patchset

Hey folks, Again we've made huge progress, with this latest version now shipping Jean-Phillipe Aumasson's HalfSipHash, which should be much more competitive with jhash (in addition to being more secure, of course). There are dozens of little cleanups and improvements right and left throughout

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 11:27 PM, Theodore Ts'o wrote: > And "with enough registers" includes ARM and MIPS, right? So the only > real problem is 32-bit x86, and you're right, at that point, only > people who might care are people who are using a space-radiation > hardened 386 ---

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

[PATCHv2] crypto: testmgr: Use heap buffer for acomp test input

Christopher Covington reported a crash on aarch64 on recent Fedora kernels: kernel BUG at ./include/linux/scatterlist.h:140! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162 Hardware name:

Re: algif for compression?

On Fri, Dec 16, 2016 at 07:41:23PM +0530, abed mohammad kamaluddin wrote: > > Thanks Herbert. Are there timelines or ongoing efforts for moving > IPcomp/Ipsec to use acomp? Or any proposals that have been or need to > be taken up in this regard. Someone needs to write the patches :) -- Email:

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 7:37 PM, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On

Re: HalfSipHash Acceptable Usage

Eric Dumazet wrote: > Now I am quite confused. > > George said : >> Cycles per byte on 1024 bytes of data: >> Pentium Core 2 Ivy >> 4 Duo Bridge >> SipHash-2-4 38.9 8.3 5.8 >> HalfSipHash-2-4 12.7 4.5 3.2 >> MD5

Re: HalfSipHash Acceptable Usage

Linus wrote: >> How much does kernel_fpu_begin()/kernel_fpu_end() cost? > > It's now better than it used to be, but it's absolutely disastrous > still. We're talking easily many hundreds of cycles. Under some loads, > thousands. I think I've been thoroughly dissuaded, but just to clarify one

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin wrote: > > How much does kernel_fpu_begin()/kernel_fpu_end() cost? It's now better than it used to be, but it's absolutely disastrous still. We're talking easily many hundreds of cycles. Under some loads, thousands. And

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, 2016-12-21 at 11:39 -0500, Rik van Riel wrote: > Does anybody still have a P4? > > If they do, they're probably better off replacing > it with an Atom. The reduced power bills will pay > for replacing that P4 within a year or two. Well, maybe they have millions of units to replace. >

Re: [PATCH] crypto: testmgr: Use linear alias for test input

On Mon, Dec 19, 2016 at 03:37:26PM -0800, Laura Abbott wrote: > Christopher Covington reported a crash on aarch64 on recent Fedora > kernels: > > kernel BUG at ./include/linux/scatterlist.h:140! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: > CPU: 2 PID: 752 Comm:

Re: Test AEAD/authenc algorithms from userspace

On Mon, Dec 19, 2016 at 04:08:11PM +0530, Harsh Jain wrote: > Hi Herbert, > > TLS default mode of operation is MAC-then-Encrypt for Authenc algos. > Currently framework only supports EtM used in IPSec. User space > programs like openssl cannot use af-alg interface to encrypt/decrypt > in TLS

Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage

On Wed, 2016-12-21 at 10:55 -0500, George Spelvin wrote: > Actually, DJB just made a very relevant suggestion. > > As I've mentioned, the 32-bit performance problems are an x86- > specific > problem.  ARM does very well, and other processors aren't bad at all. > > SipHash fits very nicely (and

Re: HalfSipHash Acceptable Usage

Hi Eric, On Wed, Dec 21, 2016 at 4:56 PM, Eric Dumazet wrote: > That really was for 1024 bytes blocks, so pretty much useless for our > discussion ? > > Reading your numbers last week, I thought SipHash was faster, but George > numbers are giving the opposite impression.

Re: HalfSipHash Acceptable Usage

Hi George, On Wed, Dec 21, 2016 at 4:55 PM, George Spelvin wrote: > Actually, DJB just made a very relevant suggestion. > > As I've mentioned, the 32-bit performance problems are an x86-specific > problem. ARM does very well, and other processors aren't bad at all. >

Re: HalfSipHash Acceptable Usage

On Wed, 2016-12-21 at 15:42 +0100, Jason A. Donenfeld wrote: > Hi Eric, > > I computed performance numbers for both 32-bit and 64-bit using the > actual functions in which talking about replacing MD5 with SipHash. > The basic harness is here [1] if you're curious. SipHash was a pretty > clear

Re: HalfSipHash Acceptable Usage

Actually, DJB just made a very relevant suggestion. As I've mentioned, the 32-bit performance problems are an x86-specific problem. ARM does very well, and other processors aren't bad at all. SipHash fits very nicely (and runs very fast) in the MMX registers. They're 64 bits, and there are 8

Re: HalfSipHash Acceptable Usage

Hi Eric, I computed performance numbers for both 32-bit and 64-bit using the actual functions in which talking about replacing MD5 with SipHash. The basic harness is here [1] if you're curious. SipHash was a pretty clear winner for both cases. x86_64: [1.714302]

Re: HalfSipHash Acceptable Usage

Hi George, On Wed, Dec 21, 2016 at 7:34 AM, George Spelvin wrote: > In fact, I have an idea. Allow me to make the following concrete > suggestion for using HalfSipHash with 128 bits of key material: > > - 64 bits are used as the key. > - The other 64 bits are used as

Re: [PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Hello I have some comment inline On Wed, Dec 21, 2016 at 11:56:12AM +, george.cher...@cavium.com wrote: > From: George Cherian > > Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit typo acceleration [...] > +static inline void

Re: dm-crypt optimization

On 12/20/2016 10:41 AM, Binoy Jayan wrote: > At a high level the goal is to maximize the size of data blocks that get > passed > to hardware accelerators, minimizing the overhead from setting up and tearing > down operations in the hardware. Currently dm-crypt itself is a big blocker as > it

[PATCH v3 3/3] drivers: crypto: Enable CPT options crypto for build

From: George Cherian Add the CPT options in crypto Kconfig and update the crypto Makefile Signed-off-by: George Cherian Reviewed-by: David Daney --- drivers/crypto/Kconfig | 1 + drivers/crypto/Makefile | 1 + 2

[PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

From: George Cherian Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit in Octeon-tx series of processors. Signed-off-by: George Cherian Reviewed-by: David Daney ---

[PATCH v3 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

From: George Cherian Enable the Physical Function diver for the Cavium Crypto Engine (CPT) found in Octeon-tx series of SoC's. CPT is the Cryptographic Acceleration Unit. CPT includes microcoded GigaCypher symmetric engines (SEs) and asymmetric engines (AEs).

[PATCH v3 0/3] Add Support for Cavium Cryptographic Acceleration Unit

From: George Cherian This series adds the support for Cavium Cryptographic Accelerarion Unit (CPT) CPT is available in Cavium's Octeon-Tx SoC series. The series