From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935287AbcLUOm4 (ORCPT ); Wed, 21 Dec 2016 09:42:56 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:34074 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932908AbcLUOmi (ORCPT ); Wed, 21 Dec 2016 09:42:38 -0500 MIME-Version: 1.0 In-Reply-To: <1482298164.8944.8.camel@edumazet-glaptop3.roam.corp.google.com> References: <20161221032829.3031.qmail@ns.sciencehorizons.net> <1482298164.8944.8.camel@edumazet-glaptop3.roam.corp.google.com> From: "Jason A. Donenfeld" Date: Wed, 21 Dec 2016 15:42:33 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HalfSipHash Acceptable Usage To: Eric Dumazet Cc: George Spelvin , "Theodore Ts'o" , Andi Kleen , David Miller , David Laight , "Daniel J . Bernstein" , Eric Biggers , Hannes Frederic Sowa , Jean-Philippe Aumasson , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , LKML , Andy Lutomirski , Netdev , Tom Herbert , Linus Torvalds , Vegard Nossum Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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] secure_tcpv6_sequence_number_md5# cycles: 102373398 [ 1.747685] secure_tcp_sequence_number_md5# cycles: 92042258 [ 1.773522] secure_tcpv6_sequence_number_siphash# cycles: 70786533 [ 1.798701] secure_tcp_sequence_number_siphash# cycles: 68941043 x86: [ 1.635749] secure_tcpv6_sequence_number_md5# cycles: 106016335 [ 1.670259] secure_tcp_sequence_number_md5# cycles: 95670512 [ 1.708387] secure_tcpv6_sequence_number_siphash# cycles: 105988635 [ 1.740264] secure_tcp_sequence_number_siphash# cycles: 88225395 >>> 102373398 > 70786533 True >>> 92042258 > 68941043 True >>> 106016335 > 105988635 True >>> 95670512 > 88225395 True While MD5 is probably faster for some kind of large-data cycles-per-byte, due to its 64-byte internal state, SipHash -- the "Sip" part standing "Short Input PRF" -- is fast for shorter inputs. In practice with the functions we're talking about replacing, there's no need to hash 64-bytes. So, SipHash comes out faster and more secure. I also haven't begun to look focusedly at the assembly my SipHash implemention is generating, which means there's still window for even more performance improvements. Jason [1] https://git.zx2c4.com/linux-dev/tree/net/core/secure_seq.c?h=siphash-bench#n194