On Thu, 13 Jan 2022 at 04:24, Sandy Harris <sandyinchina@xxxxxxxxx> wrote: > > Jason A. Donenfeld <Jason@xxxxxxxxx> 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.
