linux-kernel - Re: [PATCH 0/3] crypto: af_alg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57054DBC.8010507@intel.com>
Date:	Wed, 6 Apr 2016 10:56:12 -0700
From:	Tadeusz Struk <tadeusz.struk@...el.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	davem@...emloft.net
Subject: Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

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