Received-SPF: pass (google.com: domain of linux-wireless+bounces-5094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240313233227.56391-1-ebiggers@kernel.org> <CZXWE5J2QMIN.1L4QKQU7C7UMN@kernel.org>
 <20240321041015.GB2387@sol.localdomain>
In-Reply-To: <20240321041015.GB2387@sol.localdomain>
From: Andrew Zaborowski <balrogg@googlemail.com>
Date: Thu, 21 Mar 2024 15:44:28 +0100
Message-ID: <CAOq732+nyLtnafARgfx_dByRNxdw9E0hE8zWvKrPayUrx+MNgg@mail.gmail.com>
Subject: Re: [PATCH] Revert "crypto: pkcs7 - remove sha1 support"
To: Eric Biggers <ebiggers@kernel.org>
Cc: Jarkko Sakkinen <jarkko@kernel.org>, linux-crypto@vger.kernel.org, 
	Herbert Xu <herbert@gondor.apana.org.au>, keyrings@vger.kernel.org, 
	linux-wireless@vger.kernel.org, iwd@lists.linux.dev, 
	James Prestwood <prestwoj@gmail.com>, Dimitri John Ledkov <dimitri.ledkov@canonical.com>, 
	Karel Balej <balejk@matfyz.cz>
Content-Type: text/plain; charset="UTF-8"

On Thu, 21 Mar 2024 at 05:10, Eric Biggers <ebiggers@kernel.org> wrote:
> On Tue, Mar 19, 2024 at 07:20:54PM +0200, Jarkko Sakkinen wrote:
> > I'd like to think that there is common will to eventually get rid of
> > all of SHA-1, and thus in cases where it is not yet possible it would
> > make sense to guide what to needs to be done to make it happen, right?
> >
> > BR, Jarkko
>
> This is supposed to just be a revert, so it's best not to mess around with
> adding additional stuff that wasn't in the original commit.  The sha1 signatures
> are also not unique; iwd is also forcing the kernel to keep supporting MD4, RC4,
> KEYCTL_DH_COMPUTE, KEYCTL_PKEY_{QUERY,ENCRYPT,DECRYPT,SIGN,VERIFY}, etc.
> Probably more than I don't know about.  I guess all of this should be documented
> in the code in appropriate places.  Probably the iwd folks should step in to do
> this, as they know best what they're using and they got a lot of this added to
> the kernel in the first place.

As far as I know none of these were added specifically for iwd but I
could be wrong.  RC4 is not in the kernel anymore.

With regards to SHA1 it is used by iwd directly through an API but
more importantly it's a dependency for x509 support in practice.
Outside of module signing most x509 certificates in the wild use SHA1:
wifi, https.  This thread originally talked about the removal of SHA1
access through some API, not SHA1 in general.

Regarding the use of the kernel crypto in iwd, IIRC some of the motivation was:

* to avoid duplication.  On a small system it's hard to justify having
the same algorithms in the kernel and in userspace.  openssl is
probably larger than all of ell+iwd.

* (various arguments can be made about how duplication doesn't help
security, but an argument can be made the other way as well)

* there is (was?) a plan to use the kernel keys API to abstract
passing keys/keyrings between processes to greatly reduce the presence
of the actual key contents in memory/filesystem.  Network Manager
could load a key from file or a PKCS11 device and pass its kernel
handle to iwd or other userspace instead of file paths, with the files
necessarily being readable by multiple processes and loaded multiple
times into memory.  The keys could also be loaded once on boot.  Or
the keys could be in TPM and never be seen in main memory, only their
API handles.

Best regards