# Re: \[PATCH iproute2-next v2\] lib/bpf\_legacy: Use userspace SHA-1 code instead of AF\_ALG

- From: Ard Biesheuvel \<ardb@kernel.org\>
- Date: 2025-11-13 07:25:41 
- List: netdev
- Page: https://ratatoskr.run/netdev/2025/11/7939766
- Thread: https://ratatoskr.run/netdev/2025/09/7933413/t.md

```text
On Wed, 12 Nov 2025 at 21:12, Stephen Hemminger
[ref] wrote:
>
> On Mon, 29 Sep 2025 12:46:48 -0700
> Eric Biggers [ref] 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.
```