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 11:24:10 +0800 From: Sandy Harris <sandyinchina@...il.com> To: "Jason A. Donenfeld" <Jason@...c4.com> Cc: 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>, "Ted Ts'o" <tytso@....edu> Subject: Re: [PATCH RFC v1 0/3] remove remaining users of SHA-1 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. 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.
Powered by blists - more mailing lists