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: Wed, 12 Jan 2022 17:33:44 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Toke Høiland-Jørgensen <toke@...hat.com> Cc: "Jason A. Donenfeld" <Jason@...c4.com>, Network Development <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 <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 5:14 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. Nack. It's part of api. We cannot change it.
Powered by blists - more mailing lists