netdev - Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEM62YLP2oLEA447hCFidTqE0E76XrTO02B373=sa0Jkw@mail.gmail.com>
Date: Thu, 13 Nov 2025 08:25:28 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Eric Biggers <ebiggers@...nel.org>, netdev@...r.kernel.org, bpf@...r.kernel.org, 
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code
 instead of AF_ALG

On Wed, 12 Nov 2025 at 21:12, Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> On Mon, 29 Sep 2025 12:46:48 -0700
> Eric Biggers <ebiggers@...nel.org> wrote:
>
> > diff --git a/lib/sha1.c b/lib/sha1.c
> > new file mode 100644
> > index 00000000..1aa8fd83
> > --- /dev/null
> > +++ b/lib/sha1.c
> > @@ -0,0 +1,108 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * SHA-1 message digest algorithm
> > + *
> > + * Copyright 2025 Google LLC
> > + */
>
> Not a big fan of having actual crypto in iproute2.
> It creates even more technical debt.

I understand your position, and I agree with it in principle.

However, the usual motivation for not re-inventing/re-implementing
your own crypto is the risk associated with getting it wrong, or with
failing to keep up with bug fixes etc. Given that SHA-1 is already
considered broken beyond repair for its original purpose, and is now
merely a glorified checksumming algorithm that is only kept around to
retain backward compatibility, I'd argue that the situation is a bit
different here.

Also, I strongly agree with Eric that a syscall interface to perform
crypto s/w arithmetic that could easily execute in user space is
something that should have never been added, and creates portability
concerns for no good reason.