On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk <tadeusz.struk@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
