All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Andrew Zaborowski <balrogg@googlemail.com>
Cc: Mat Martineau <mathew.j.martineau@linux.intel.com>,
	Tadeusz Struk <tadeusz.struk@intel.com>,
	David Howells <dhowells@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-api@vger.kernel.org, marcel@holtmann.org,
	linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	davem@davemloft.net
Subject: Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
Date: Thu, 16 Jun 2016 10:05:48 +0200	[thread overview]
Message-ID: <10863259.oUiAus9m9y@positron.chronox.de> (raw)
In-Reply-To: <CAOq732+ZyjD2Wv3Pt7x+jfurvgVq5pcUA--+G6VQM5t861n-fQ@mail.gmail.com>

Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski:

Hi Andrew,

> > 
> > I think we have agreed on dropping the length enforcement at the interface
> > level.
> 
> Separately from this there's a problem with the user being unable to
> know if the algorithm is going to fail because of destination buffer
> size != key size (including kernel users).  For RSA, the qat
> implementation will fail while the software implementation won't.  For
> pkcs1pad(...) there's currently just one implementation but the user
> can't assume that.

If I understand your issue correctly, my initial code requiring the caller to 
provide sufficient memory would have covered the issue, right? If so, we seem 
to have implementations which can handle shorter buffer sizes and some which 
do not. Should a caller really try to figure the right buffer size out? Why 
not requiring a mandatory buffer size and be done with it? I.e. what is the 
gain to allow shorter buffer sizes (as pointed out by Mat)? So, bottom line, I 
am wondering whether we should keep the algif_akcipher code to require a 
minimum buffer size.

If there is really a good argument to allow shorter buffers, then I guess we 
need an in-kernel API call (which should be reported to user space) which 
gives us the smallest usable buffer size. I guess that call would only be 
valid after a setkey operation as the output size depends on the key size. 
Instead of inventing a complete new API call, shouldn't the call 
crypto_akcipher_maxsize() be converted for this purpose? I requested that API 
call during the time the akcipher API was developed explicitly for getting the 
minimum buffer size the caller needs to provide.

Ciao
Stephan

  reply	other threads:[~2016-06-16  8:05 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-05 19:50 [PATCH RESEND v5 0/6] crypto: algif - add akcipher Tadeusz Struk
2016-05-05 19:50 ` Tadeusz Struk
2016-05-05 19:50 ` [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API Tadeusz Struk
2016-05-06 10:36   ` Stephan Mueller
2016-05-05 19:50 ` [PATCH RESEND v5 2/6] crypto: AF_ALG -- add setpubkey setsockopt call Tadeusz Struk
2016-05-05 19:51 ` [PATCH RESEND v5 3/6] crypto: AF_ALG -- add asymmetric cipher interface Tadeusz Struk
2016-05-05 19:51 ` [PATCH RESEND v5 4/6] crypto: algif_akcipher - enable compilation Tadeusz Struk
2016-05-05 19:51 ` [PATCH RESEND v5 5/6] crypto: algif_akcipher - add ops_nokey Tadeusz Struk
2016-05-05 19:51 ` [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id Tadeusz Struk
2016-05-05 19:51   ` Tadeusz Struk
2016-05-06 11:46   ` Stephan Mueller
2016-05-13 23:32   ` Mat Martineau
2016-05-13 23:32     ` Mat Martineau
2016-05-16 14:23     ` Tadeusz Struk
2016-05-11 14:25 ` [PATCH RESEND v5 0/6] crypto: algif - add akcipher David Howells
     [not found]   ` <5123.1462976721-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2016-05-15  4:16     ` [PATCH v6 " Tadeusz Struk
2016-05-15  4:16       ` Tadeusz Struk
2016-05-15  4:16       ` [PATCH v6 1/6] crypto: AF_ALG -- add sign/verify API Tadeusz Struk
2016-05-15  4:16       ` [PATCH v6 2/6] crypto: AF_ALG -- add setpubkey setsockopt call Tadeusz Struk
2016-05-15  4:17       ` [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface Tadeusz Struk
2016-06-08  0:28         ` Mat Martineau
2016-06-08  5:31           ` Stephan Mueller
2016-06-08 19:14             ` Mat Martineau
2016-06-08 19:14               ` Mat Martineau
2016-06-09  9:28               ` Stephan Mueller
2016-06-09 18:18                 ` Mat Martineau
2016-06-09 18:24                   ` Stephan Mueller
2016-06-09 18:27                     ` Mat Martineau
     [not found]                       ` <alpine.OSX.2.20.1606091126420.21471-zaFMaa3cLiZe6KzckbbZvYT4S9po1h25@public.gmane.org>
2016-06-09 18:36                         ` Stephan Mueller
2016-06-09 18:36                           ` Stephan Mueller
2016-06-09 18:36                           ` Stephan Mueller
2016-06-10 14:42                           ` Tadeusz Struk
2016-06-22 22:45                             ` Mat Martineau
     [not found]                               ` <alpine.OSX.2.20.1606221515040.16377-zaFMaa3cLiZe6KzckbbZvYT4S9po1h25@public.gmane.org>
2016-06-23  5:07                                 ` Stephan Mueller
2016-06-23  5:07                                   ` Stephan Mueller
     [not found]                                   ` <3250613.UAo0YkFYZb-gNvIQDDl/k7Ia13z/PHSgg@public.gmane.org>
2016-06-23 15:22                                     ` Denis Kenzior
2016-06-23 15:22                                       ` Denis Kenzior
2016-06-13 22:16               ` Andrew Zaborowski
2016-06-14  5:12                 ` Stephan Mueller
     [not found]                   ` <1759070.fi90mrsgKn-jJGQKZiSfeo1haGO/jJMPxvVK+yQ3ZXh@public.gmane.org>
2016-06-14  7:42                     ` Andrew Zaborowski
2016-06-14  7:42                       ` Andrew Zaborowski
2016-06-16  8:05                       ` Stephan Mueller [this message]
2016-06-16 14:59                         ` Andrew Zaborowski
2016-06-16 15:38                           ` Stephan Mueller
2016-06-17  0:39                             ` Andrew Zaborowski
2016-06-14 17:22         ` Mat Martineau
2016-06-14 17:22           ` Mat Martineau
2016-06-15  7:04           ` Stephan Mueller
2016-05-15  4:17       ` [PATCH v6 4/6] crypto: algif_akcipher - enable compilation Tadeusz Struk
2016-05-15  4:17       ` [PATCH v6 5/6] crypto: algif_akcipher - add ops_nokey Tadeusz Struk
2016-05-15  4:17       ` [PATCH v6 6/6] crypto: AF_ALG - add support for key_id Tadeusz Struk
2016-05-26  0:45         ` Mat Martineau
2016-05-26  0:45           ` Mat Martineau
2016-05-31 17:44           ` Tadeusz Struk
2016-05-15 11:59       ` [PATCH v6 0/6] crypto: algif - add akcipher Stephan Mueller
2016-05-16 20:46       ` Tadeusz Struk

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=10863259.oUiAus9m9y@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=balrogg@googlemail.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=tadeusz.struk@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.