Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: Andrew Zaborowski <balrogg@googlemail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API
Date: Mon, 14 Aug 2017 08:03:19 +0200	[thread overview]
Message-ID: <3253864.NSkFVeIncy@tauon.chronox.de> (raw)
In-Reply-To: <alpine.OSX.2.21.1708111158510.37345@bciftcio-mobl.amr.corp.intel.com>

Am Freitag, 11. August 2017, 21:43:15 CEST schrieb Mat Martineau:

Hi Mat,

> 
> I also would like to have more of those algorithms exposed to userspace,
> and I'd like to make sure the API is a good fit. There was extensive
> discussion of AF_ALG akcipher last year. v8 of the patch set updates the
> implementation but doesn't address the API concerns that kept the previous
> versions from being merged, so we seem to be at just as much of an impasse
> as before.

During last year's discussion, I think we have concluded (and please correct 
me if I miss something), that the export of the asymmetric HW implementations 
to user space should

- allow a streaming mode where the user space uses the kernel as an 
accelerator (maybe user space has another way of storing keys)

- allow the private key to be retained in kernel space (or even in hardware 
only) -- i.e. user space only has a handle to the key for a full asym 
operation

The first part is clearly where AF_ALG fits and keyctl does not. This is 
provided with the current patch set. As the keyctl API only handles, well, 
keys, access to the raw ciphers may not be possible through this API. And let 
us face it, a lot of user space code shall support many different OSes. Thus, 
if you have a crypto lib in user space who has its own key management (which 
is a core element of such libraries and thus cannot be put into an 
architecture-dependent code part), having only the keyctl API on Linux for 
accelerated asym support may not be helpful.

The second part is a keyctl domain. I see in-kernel support for this scenario, 
but have not yet seen the kernel/user interface nor the user space support.

Both options are orthogonal, IMHO.

Tadeusz Struck provided a patch to link the kernel crypto API / algif_akcipher 
with the keys subsystem to allow the second requirement to be implemented in 
algif_akcipher. That patch is on my desk and I plan to integrate it and even 
make it generic to allow its use for all different cipher types. I have not 
yet integrated it to allow a small patch set to be reviewed. If it is the will 
of the council, I can surely add that code to the initial patch set and 
resubmit.


Ciao
Stephan

  reply	other threads:[~2017-08-14  6:03 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10  6:39 [PATCH v8 0/4] crypto: add algif_akcipher user space API Stephan Müller
2017-08-10  6:39 ` [PATCH v8 1/4] crypto: AF_ALG -- add sign/verify API Stephan Müller
2017-08-10 12:49   ` Tudor Ambarus
2017-08-10 13:03     ` Stephan Mueller
2017-08-10 13:59       ` Tudor Ambarus
2017-08-10 14:06         ` Stephan Müller
2017-08-10  6:39 ` [PATCH v8 2/4] crypto: AF_ALG -- add setpubkey setsockopt call Stephan Müller
2017-08-10  6:40 ` [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher Stephan Müller
2017-08-11 12:51   ` Tudor Ambarus
2017-08-19 13:53     ` Stephan Müller
2017-08-21  8:55       ` Tudor Ambarus
2017-08-21  9:23         ` Tudor Ambarus
2017-08-21  9:39           ` Stephan Mueller
2017-08-10  6:40 ` [PATCH v8 4/4] crypto: algif_akcipher - enable compilation Stephan Müller
2017-08-11 12:56   ` Tudor Ambarus
2017-08-11 13:03     ` Stephan Mueller
2017-08-11  0:48 ` [PATCH v8 0/4] crypto: add algif_akcipher user space API Mat Martineau
2017-08-11  5:13   ` Marcel Holtmann
2017-08-11  6:30     ` Stephan Müller
2017-08-11 16:02       ` Marcel Holtmann
2017-08-14  6:24         ` Stephan Mueller
2017-08-14  6:42           ` Marcel Holtmann
2017-08-11  7:18   ` Stephan Mueller
2017-08-11 16:05     ` Marcel Holtmann
2017-08-13  8:52       ` Gilad Ben-Yossef
2017-08-14  6:01         ` Stephan Mueller
2017-08-17 13:17       ` Tudor Ambarus
2017-08-30  6:15         ` Tudor Ambarus
2017-08-30  7:21           ` Marcel Holtmann
2017-08-30  8:17             ` Tudor Ambarus
2017-08-30 12:36               ` Marcel Holtmann
2017-08-11 10:18   ` Andrew Zaborowski
2017-08-11 19:43     ` Mat Martineau
2017-08-14  6:03       ` Stephan Mueller [this message]
2017-08-14  6:26         ` Marcel Holtmann
2017-08-14  7:23           ` Stephan Mueller
2017-08-14  9:26             ` Marcel Holtmann
2017-10-02 14:15 ` Tudor Ambarus
2017-10-03  0:09   ` Mat Martineau

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=3253864.NSkFVeIncy@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=balrogg@googlemail.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mathew.j.martineau@linux.intel.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