[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXDmwHaJuvNo8vkzudfhL0E3b=0b4mP_OqDCYFqm82J5Q@mail.gmail.com>
Date: Fri, 14 Jan 2022 16:36:22 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Ard Biesheuvel <ardb@...nel.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
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
Hi Jason,
On Fri, Jan 14, 2022 at 4:20 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> I think the reason that Alexei doesn't think that the SHA-1 choice
> really matters is because the result is being truncated to 64-bits, so
> collisions are easy anyway, regardless of which hash function is
> chosen (birthday bound and all). But from Geert's perspective, that
> SHA-1 is still taking up precious bytes in m68k builds. And from my
> perspective, it's poor form and clutters vmlinux, and plus, now I'm
> curious about why this isn't using a more appropriately sized tag in
> the first place.
Not just on m68k. Same on other architectures.
Yes, people do make products with SoCs with 8 MiB of builtin SRAM,
running Linux. They might stay away from BPF, though ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists