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: Thu, 13 Jan 2022 09:08:40 +0100 From: Ard Biesheuvel <ardb@...nel.org> To: Sandy Harris <sandyinchina@...il.com> Cc: "Jason A. Donenfeld" <Jason@...c4.com>, "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Herbert Xu <herbert@...dor.apana.org.au>, Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, "Ted Ts'o" <tytso@....edu> Subject: Re: [PATCH RFC v1 0/3] remove remaining users of SHA-1 On Thu, 13 Jan 2022 at 04:24, Sandy Harris <sandyinchina@...il.com> wrote: > > Jason A. Donenfeld <Jason@...c4.com> wrote: > > > There are currently two remaining users of SHA-1 left in the kernel: bpf > > tag generation, and ipv6 address calculation. > > I think there are three, since drivers/char/random.c also uses it. > Moreover, there's some inefficiency there (or was last time I > looked) since it produces a 160-bit hash then folds it in half > to give an 80-bit output. > That code was removed, hence the two /remaining/ users. > A possible fix would be to use a more modern 512-bit hash. > SHA3 would be the obvious one, but Blake2 would work, > Blake3 might be faster & there are several other possibilities. > Hash context size would then match ChaCha so you could > update the whole CC context at once, maybe even use the > same context for both. > > That approach has difficulties, Extracting 512 bits every > time might drain the input pool too quickly & it is overkill > for ChaCha which should be secure with smaller rekeyings. > > If you look at IPsec, SSL & other such protocols, many > have now mostly replaced the hash-based HMAC > constructions used in previous generations with things > like Galois field calculations (e.g. AES-GCM) or other > strange math (e,g. poly 1305). These have most of the > desirable properties of hashes & are much faster. As > far as I know, they all give 128-bit outputs. > > I think we should replace SHA-1 with GCM. Give > ChaCha 128 bits somewhat more often than current > code gives it 256. You are conflating MACs with hashes. A MAC does is not suitable for backtrack resistance, and GHASH in particular is really only suited to be used in the context of GCM.
Powered by blists - more mailing lists