Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1371404 > unrolled thread

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Herbert Xu <herbert@gondor.apana.org.au> - 2016-04-05 13:30 +0200
    Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Tadeusz Struk <tadeusz.struk@intel.com> - 2016-04-06 20:10 +0200
      Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Tom Herbert <tom@herbertland.com> - 2016-04-08 05:00 +0200
        Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Fridolin Pokorny <fpokorny@redhat.com> - 2016-04-12 13:20 +0200
          Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Tadeusz Struk <tadeusz.struk@intel.com> - 2016-04-14 01:00 +0200
            Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Nikos Mavrogiannopoulos <nmav@gnutls.org> - 2016-04-14 08:50 +0200
      Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption Herbert Xu <herbert@gondor.apana.org.au> - 2016-04-08 05:00 +0200

#1371404 — Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

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?

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?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [next] | [standalone]

#1372711

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

[toc] | [prev] | [next] | [standalone]

#1373943

On Thu, Apr 7, 2016 at 11:52 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote:
>>
>> 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.
>
> There have been suggestions to implement TLS data-path within
> the kernel.  So we should decide whether we pursue that or go
> with your approach before we start adding algorithms.
>
Yes, please see Dave Watson's patches on this.

Tom

> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [next] | [standalone]

#1376708

On 08.04.2016 04:58, Tom Herbert wrote:
> On Thu, Apr 7, 2016 at 11:52 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote:
>>>
>>> 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.
>>
>> There have been suggestions to implement TLS data-path within
>> the kernel.  So we should decide whether we pursue that or go
>> with your approach before we start adding algorithms.
>>
> Yes, please see Dave Watson's patches on this.
> 


Hi Tadeusz,

we were experimenting with this. We have a prove of concept of a kernel
TLS type socket, so called AF_KTLS, which is based on Dave Watson's
RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not
ready now to be proposed here. There are still issues which should be
solved (but mostly user space API design) [1]. If you are interested, we
could combine efforts.

Regards,
Fridolin Pokorny

[1] https://github.com/fridex/af_ktls

[toc] | [prev] | [next] | [standalone]

#1378331

Hi Fridolin,
On 04/12/2016 04:13 AM, Fridolin Pokorny wrote:
> we were experimenting with this. We have a prove of concept of a kernel
> TLS type socket, so called AF_KTLS, which is based on Dave Watson's
> RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not
> ready now to be proposed here. There are still issues which should be
> solved (but mostly user space API design) [1]. If you are interested, we
> could combine efforts.
> 
> Regards,
> Fridolin Pokorny
> 
> [1] https://github.com/fridex/af_ktls

I had a quick look and it looks like is limited only to gcm(aes). 
I would be more interested to have a generic interface that could do generic algorithm
suits like aes-cbc-hmac-sha1 also.
This also seems to work in a synchronous (send one and wait) mode, which is a not good
solution for HW accelerators, which I'm trying to enable.
Thanks,
-- 
TS

[toc] | [prev] | [next] | [standalone]

#1378525

On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk <tadeusz.struk@intel.com> wrote:
> Hi Fridolin,
> On 04/12/2016 04:13 AM, Fridolin Pokorny wrote:
>> we were experimenting with this. We have a prove of concept of a kernel
>> TLS type socket, so called AF_KTLS, which is based on Dave Watson's
>> RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not
>> ready now to be proposed here. There are still issues which should be
>> solved (but mostly user space API design) [1]. If you are interested, we
>> could combine efforts.
>>
>> Regards,
>> Fridolin Pokorny
>>
>> [1] https://github.com/fridex/af_ktls
> I had a quick look and it looks like is limited only to gcm(aes).
> I would be more interested to have a generic interface that could do generic algorithm
> suits like aes-cbc-hmac-sha1 also.

This is not a real limitation but an advantage. The cbc-hmac-sha1
needs a lot of hacks to be implemented correct (just take a look at
one of the existing implementations). There is no point to bring such
hacks into kernel especially since these ciphersuites are banned from
HTTP/2.0 (see RFC7540), and have been dropped from TLS 1.3.

> This also seems to work in a synchronous (send one and wait) mode, which is a not good
> solution for HW accelerators, which I'm trying to enable.

Is that something that cannot be addressed?

regards,
Nikos

[toc] | [prev] | [next] | [standalone]

#1373944

On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote:
> 
> 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.

There have been suggestions to implement TLS data-path within
the kernel.  So we should decide whether we pursue that or go
with your approach before we start adding algorithms.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web