From: Eric Biggers <ebiggers3@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: "Stephan Müller" <smueller@chronox.de>,
keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>,
mathew.j.martineau@linux.intel.com,
"Eric Biggers" <ebiggers@google.com>
Subject: Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF
Date: Thu, 27 Apr 2017 22:26:52 -0700 [thread overview]
Message-ID: <20170428052652.GA7172@zzz> (raw)
In-Reply-To: <28956.1493306119@warthog.procyon.org.uk>
On Thu, Apr 27, 2017 at 04:15:19PM +0100, David Howells wrote:
> Eric Biggers <ebiggers3@gmail.com> wrote:
>
> > > > By the way: do we really need this in the kernel at all, given that it's
> > > > just doing some math on data which userspace has access to?
> > >
> > > It is the question about how we want the keys subsystem to operate. The DH
> > > shared secret shall not be used as a key. But the DH operation is part of
> > > the key subsystem. If there is never a case where the result of the DH
> > > operation is used in the kernel, then the KDF can be removed and my
> > > patches could be reverted. However, in this case, the entire DH business
> > > could be questioned as this can easily be done in user space as well.
> > >
> >
> > Well, who exactly is asking for Diffie-Hellman in the kernel at all? If it
> > can be done in userspace then it should be done there. Having it in the
> > kernel means having yet another API that's callable by unprivileged users
> > and needs to be audited for security vulnerabilities. Just because the
> > kernel can support doing hashes or has an arbitrary-precision arithmetic
> > library or whatever doesn't mean it's the right place to do random crypto
> > stuff.
>
> I understood that there is the possibility of offloading this to hardware.
>
Okay, but where is this hardware, where are drivers for it, and how do we know
this API is actually going to be compatible with it? Will it be just for
performance, or for other reasons too? None of this seems to have been
explained.
Eric
next prev parent reply other threads:[~2017-04-28 5:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 5:46 [PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension Eric Biggers
2017-04-20 5:46 ` [PATCH 1/5] KEYS: DH: forbid using digest_null as the KDF hash Eric Biggers
2017-04-20 5:46 ` [PATCH 2/5] KEYS: DH: don't feed uninitialized "otherinfo" into KDF Eric Biggers
2017-04-20 5:46 ` [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory " Eric Biggers
2017-04-20 13:27 ` Stephan Müller
2017-04-20 17:46 ` Eric Biggers
2017-04-20 18:38 ` Stephan Müller
2017-04-21 3:44 ` Eric Biggers
2017-04-27 15:15 ` David Howells
2017-04-28 5:26 ` Eric Biggers [this message]
2017-04-20 5:46 ` [PATCH 4/5] KEYS: DH: ensure the KDF counter is properly aligned Eric Biggers
2017-04-20 5:46 ` [PATCH 5/5] KEYS: DH: add __user annotations to keyctl_kdf_params Eric Biggers
2017-04-28 15:53 ` [PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension David Howells
2017-04-28 15:56 ` Stephan Müller
2017-05-01 14:52 ` Stephan Müller
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=20170428052652.GA7172@zzz \
--to=ebiggers3@gmail.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=smueller@chronox.de \
/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).