From: Steve French <smfrench@gmail.com>
To: Simo Sorce <simo@redhat.com>
Cc: ronnie sahlberg <ronniesahlberg@gmail.com>,
Ard Biesheuvel <ardb@kernel.org>,
Eric Biggers <ebiggers@kernel.org>,
linux-cifs <linux-cifs@vger.kernel.org>,
Steve French <sfrench@samba.org>,
"samba-technical@lists.samba.org"
<samba-technical@lists.samba.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: Building cifs.ko without any support for insecure crypto?
Date: Tue, 24 Aug 2021 11:41:01 -0500 [thread overview]
Message-ID: <CAH2r5mtsgYXi2VxQZ5bDLdsAgmgjgJVqeXUxe5Sb1CiA_RyFQA@mail.gmail.com> (raw)
In-Reply-To: <627872ec0f8cc52a06f8f58598f96b72b5b9645a.camel@redhat.com>
On Mon, Aug 23, 2021 at 5:05 AM Simo Sorce <simo@redhat.com> wrote:
<snip>
> Another way to handle this part is to calculate the hash in userspace
> and handle the kernel just the hashes. This would allow you to remove
> MD4 from the kernel. I guess it would break putting a password on the
> kernel command line, but is that really a thing to do? Kernels do not
> boot from cifs shares so you can always use userspace tools (or pass
> hexed hashes directly on the command line in a pinch).
We can boot from cifs (and given the security features of SMB3.1.1 it probably
makes more sense than some of the alternatives) albeit with some POSIX
restrictions unless booting from ksmbd with POSIX extensions enabled.
Paulo added the support for booting from cifs.ko in the 5.5 kernel.
> > I have patches for both DES removal and forking ARC4 prepared for linux-cifs.
> > MD4 will require more work since we use it via the crypto_alloc_hash()
> > api but we will do that too.
> >
> > What about MD5? Is it also scheduled for removal? if so we will need
> > to fork it too.
>
> MD5 is still used for a ton of stuff, however it may make sense to
> consider moving it in /lib and our of /lib/crypto as it is not usable
> in cryptographic settings anymore anyway.
Seems reasonable
--
Thanks,
Steve
prev parent reply other threads:[~2021-08-24 16:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 3:23 Building cifs.ko without any support for insecure crypto? Eric Biggers
2021-08-13 4:46 ` ronnie sahlberg
2021-08-13 20:19 ` Eric Biggers
2021-08-15 10:38 ` ronnie sahlberg
2021-08-16 22:19 ` Eric Biggers
2021-08-17 5:35 ` Steve French
2021-08-18 11:44 ` Ard Biesheuvel
2021-08-19 3:43 ` ronnie sahlberg
2021-08-19 3:53 ` Andrew Bartlett
2021-08-23 10:04 ` Simo Sorce
2021-08-24 16:41 ` Steve French [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH2r5mtsgYXi2VxQZ5bDLdsAgmgjgJVqeXUxe5Sb1CiA_RyFQA@mail.gmail.com \
--to=smfrench@gmail.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=ronniesahlberg@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=simo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).