From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
Subject: Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption
Date: Wed, 6 Apr 2016 10:56:12 -0700 [thread overview]
Message-ID: <57054DBC.8010507@intel.com> (raw)
In-Reply-To: <20160405112940.GB11852@gondor.apana.org.au>
Hi Herbert,
On 04/05/2016 04:29 AM, Herbert Xu wrote:
> On Sat, Mar 05, 2016 at 05:20:44PM -0800, Tadeusz Struk wrote:
>> > Hi,
>> > The following series adds TLS type authentication. To do this a new
>> > template, encauth, is introduced. It is derived from the existing authenc
>> > template and modified to work in "first auth then encrypt" mode.
>> > The algif interface is also changed to work with the new authentication type.
> What is the point of this patch-set? Who is going to be the user?
The intend is to enable HW acceleration of the TLS protocol.
The way it will work is that the user space will send a packet of data
via AF_ALG and HW will authenticate and encrypt it in one go.
>
> Also you're including padding into the algorithm. That goes against
> the way we implemented IPsec. What is the justification for doing
> it in the crypto layer instead of the protocol layer?
This is because of how the TLS protocol work. In IPSEC the stack does the job
of aligning the packet to block size and the crypto layer doesn't need to worry
about padding. In TLS we need to make sure that after auth the buff is still
block size align, and that is why we need padding.
Do you think we should make the user to provide the data in a big enough buffer
to accommodate the digest and padding and the padding itself?
Thanks,
--
TS
next prev parent reply other threads:[~2016-04-06 18:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 1:20 [PATCH 0/3] crypto: af_alg - add TLS type encryption Tadeusz Struk
2016-03-06 1:20 ` [PATCH 1/3] crypto: authenc " Tadeusz Struk
2016-03-07 9:05 ` Cristian Stoica
2016-03-07 14:31 ` Tadeusz Struk
2016-03-08 8:20 ` Cristian Stoica
2016-03-08 16:49 ` Tadeusz Struk
2016-03-06 1:20 ` [PATCH 2/3] crypto: af_alg - add AEAD operation type Tadeusz Struk
2016-03-06 1:21 ` [PATCH 3/3] crypto: algif_aead - modify algif aead interface to work with encauth Tadeusz Struk
2016-04-05 11:29 ` [PATCH 0/3] crypto: af_alg - add TLS type encryption Herbert Xu
2016-04-06 17:56 ` Tadeusz Struk [this message]
2016-04-08 2:52 ` Herbert Xu
2016-04-08 2:58 ` Tom Herbert
2016-04-12 11:13 ` Fridolin Pokorny
2016-04-13 22:46 ` Tadeusz Struk
2016-04-14 6:47 ` Nikos Mavrogiannopoulos
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=57054DBC.8010507@intel.com \
--to=tadeusz.struk@intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).