Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753324AbcDNGsp (ORCPT ); Thu, 14 Apr 2016 02:48:45 -0400 Received: from mail-lf0-f51.google.com ([209.85.215.51]:35514 "EHLO mail-lf0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753180AbcDNGsm (ORCPT ); Thu, 14 Apr 2016 02:48:42 -0400 MIME-Version: 1.0 In-Reply-To: <570ECC28.3030008@intel.com> References: <20160306012044.6369.63924.stgit@tstruk-mobl1> <20160405112940.GB11852@gondor.apana.org.au> <57054DBC.8010507@intel.com> <20160408025250.GA7596@gondor.apana.org.au> <570CD852.7060003@redhat.com> <570ECC28.3030008@intel.com> From: Nikos Mavrogiannopoulos Date: Thu, 14 Apr 2016 08:47:54 +0200 X-Google-Sender-Auth: tUrNmV8Jpka9UYMai177rWYJuPI Message-ID: Subject: Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption To: Tadeusz Struk Cc: Fridolin Pokorny , Tom Herbert , Herbert Xu , Linux Crypto Mailing List , LKML , "David S. Miller" , Linux Kernel Network Developers , Dave Watson , fridolin.pokorny@gmail.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1358 Lines: 31 On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk 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