From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: tadeusz.struk@intel.com, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 0/3] AF_ALG interface for akcipher
Date: Wed, 22 Jul 2015 09:14:51 +0200 [thread overview]
Message-ID: <1819774.HTm7Ulf2x1@tachyon.chronox.de> (raw)
In-Reply-To: <20150722013241.GA31240@gondor.apana.org.au>
Am Mittwoch, 22. Juli 2015, 09:32:41 schrieb Herbert Xu:
Hi Herbert,
>
> I think we should finish the conversion of the only in-kernel
> user of RSA before we add the user-space interface. Otherwise
> this unnecessarily ties our hands to the current API.
Agreed.
After my question around the SGL vs linear buffers I was under the impression
that it was decided.
So I will wait until the discussion is completed.
>
> For example, do we want an SG interface for the input and output?
The question is whether the SGL overhead is still acceptable for the small
buffer size we have to consider when talking about raw asymmetric ciphers. For
RSA, it seems that the max size 4096 bits for the generic implementation. For
other implementations, I would not expect much larger sizes. Thus, we talk
about 512 bytes or one 1kbytes maximum operation size.
When ECC comes into picture, the sizes are even significanly smaller.
If I understood correctly, we do not want to support full hybrid asymmetric
operations (like PKCS1, OAEP and the like) where large buffers are to be
handled.
On the other hand, what about using struct scatterlist as the API input
parameter. In addition, we allow cipher implementations to traverse only one
SG entry which implies a linear buffer operation. But the API is open for full
SG operation if needed in the future. To inform the caller about the minimum
size of an SG entry, we may use another integer value similar to alignmask.
So, if Tadeusz's hardware wants one linear buffer, the integer is 256 or 512
where the caller must create the buffers of at least this size. As all input
data would fit into that one buffer, there the caller only needs to allocate
one SG.
--
Ciao
Stephan
prev parent reply other threads:[~2015-07-22 7:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 22:12 [PATCH 0/3] AF_ALG interface for akcipher Stephan Mueller
2015-07-21 22:12 ` [PATCH 1/3] crypto: af_alg - add sig gen / verify API Stephan Mueller
2015-07-21 22:13 ` [PATCH 2/3] crypto: algif_akcipher user space interface Stephan Mueller
2015-07-22 16:01 ` Tadeusz Struk
2015-07-22 18:55 ` Stephan Mueller
2015-07-22 22:04 ` Tadeusz Struk
2015-07-22 22:29 ` Stephan Mueller
2015-07-21 22:13 ` [PATCH 3/3] crypto: algif_akcipher - enable compilation Stephan Mueller
2015-07-22 1:32 ` [PATCH 0/3] AF_ALG interface for akcipher Herbert Xu
2015-07-22 4:19 ` Tadeusz Struk
2015-07-22 4:21 ` Herbert Xu
2015-07-22 11:58 ` Horia Geantă
2015-07-23 1:53 ` Herbert Xu
2015-07-23 5:14 ` Tadeusz Struk
2015-07-23 5:19 ` Herbert Xu
2015-07-23 10:16 ` Stephan Mueller
2015-07-22 7:14 ` Stephan Mueller [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=1819774.HTm7Ulf2x1@tachyon.chronox.de \
--to=smueller@chronox.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox