lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 14 Jan 2022 18:04:14 -0500 From: Jeffrey Walton <noloader@...il.com> To: Toke Høiland-Jørgensen <toke@...hat.com> Cc: "Jason A. Donenfeld" <Jason@...c4.com>, Netdev <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Herbert Xu <herbert@...dor.apana.org.au>, Ard Biesheuvel <ardb@...nel.org>, Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, bpf@...r.kernel.org Subject: Re: [PATCH RFC v1 1/3] bpf: move from sha1 to blake2s in tag calculation On Wed, Jan 12, 2022 at 8:13 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote: > > [ adding the bpf list - please make sure to include that when sending > BPF-related patches, not everyone in BPF land follows netdev ] > > "Jason A. Donenfeld" <Jason@...c4.com> writes: > > > BLAKE2s is faster and more secure. SHA-1 has been broken for a long time > > now. This also removes quite a bit of code, and lets us potentially > > remove sha1 from lib, which would further reduce vmlinux size. > > AFAIU, the BPF tag is just used as an opaque (i.e., arbitrary) unique > identifier for BPF programs, without any guarantees of stability. Which > means changing it should be fine; at most we'd confuse some operators > who have memorised the tags of their BPF programs :) > > The only other concern I could see would be if it somehow locked us into > that particular algorithm for other future use cases for computing > hashes of BPF programs (say, signing if that ends up being the direction > we go in). But obviously SHA1 would not be a good fit for that anyway, > so the algorithm choice would have to be part of that discussion in any > case. > > So all in all, I don't see any issues with making this change for BPF. Somewhat related, if BPF is going to move from SHA to something, then consider SipHash. Here are the numbers I regularly observe. They remain relative the same on 64-bit platforms: * SHA-1: 4.31 cpb using SSE2 * BLAKE2s: 4.84 cpb using SSE4.1 * BLAKE2b: 3.49 cpb using SSE4.1 * SipHash 2-4: 1.54 cpb using C/C++ * SipHash 4-8: 2.55 cpb using C/C++ If BPF is Ok with 64-bit tags, then SipHash 2-4 is probably what you want on the wish list. Jeff
Powered by blists - more mailing lists