Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

On Mon, Jul 31, 2017 at 3:16 PM, Dave Watson <davejwat...@fb.com> wrote: > On 07/29/17 01:12 PM, Tom Herbert wrote: >> On Wed, Jun 14, 2017 at 11:37 AM, Dave Watson <davejwat...@fb.com> wrote: >> > Add the infrustructure for attaching Upper Layer Protocols (ULPs

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

On Fri, Jun 16, 2017 at 5:14 PM, Christoph Paasch wrote: > Hello, > > On 14/06/17 - 11:37:14, Dave Watson wrote: >> Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP >> sockets. Based on a similar infrastructure in tcp_cong. The idea is that

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

On Wed, Jun 14, 2017 at 11:37 AM, Dave Watson wrote: > Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP > sockets. Based on a similar infrastructure in tcp_cong. The idea is that any > ULP can add its own logic by changing the TCP proto_ops structure

Re: [PATCH v3 net-next 0/4] kernel TLS

On Wed, Jun 14, 2017 at 3:17 PM, Dave Watson <davejwat...@fb.com> wrote: > On 06/14/17 01:54 PM, Tom Herbert wrote: >> On Wed, Jun 14, 2017 at 11:36 AM, Dave Watson <davejwat...@fb.com> wrote: >> > This series adds support for kernel TLS encryption over TCP socke

Re: [PATCH v3 net-next 0/4] kernel TLS

On Wed, Jun 14, 2017 at 11:36 AM, Dave Watson wrote: > This series adds support for kernel TLS encryption over TCP sockets. > A standard TCP socket is converted to a TLS socket using a setsockopt. > Only symmetric crypto is done in the kernel, as well as TLS record > framing.

Re: [RFC TLS Offload Support 05/15] tcp: Add TLS socket options for TCP sockets

On Tue, Mar 28, 2017 at 6:26 AM, Aviad Yehezkel wrote: > This patch adds TLS_TX and TLS_RX TCP socket options. > > Setting these socket options will change the sk->sk_prot > operations of the TCP socket. The user is responsible to > prevent races between calls to the

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 12:41 PM, George Spelvin <li...@sciencehorizons.net> wrote: > Tom Herbert wrote: >> Tested this. Distribution and avalanche effect are still good. Speed >> wise I see about a 33% improvement over siphash (20 nsecs/op versus 32 >> nsecs). That's

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 4:39 AM, Jason A. Donenfeld wrote: > Hey JP, > > On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson > wrote: >> Here's a tentative HalfSipHash: >> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c >> >>

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hey Tom, > > On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert <t...@herbertland.com> wrote: >> Those look good, although I would probably just do 1,2,3 words and >> then have a function tha

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 4:53 AM, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:51 AM, David Laight > wrote: >> From: Jason A. Donenfeld >>> Sent: 14 December 2016 00:17 >>> This gives a clear speed and security improvement. Rather

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > "super fast" is

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

On Thu, Apr 7, 2016 at 11:52 PM, Herbert Xu 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

Re: ipsec impact on performance

On Wed, Dec 2, 2015 at 1:12 PM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (12/02/15 13:07), Tom Herbert wrote: >> That's easy enough to add to flow dissector, but is SPI really >> intended to be used an L4 entropy value? We would need to consider the &g

Re: ipsec impact on performance

On Wed, Dec 2, 2015 at 12:50 PM, Sowmini Varadhan wrote: > On (12/02/15 12:41), David Laight wrote: >> You are getting 0.7 Gbps with ass-ccm-a-128, scale the esp-null back to >> that and it would use 7/18*71 = 27% of the cpu. >> So 69% of the cpu in the a-128 case is

Re: ipsec impact on performance

On Tue, Dec 1, 2015 at 9:59 AM, Sowmini Varadhan wrote: > > I instrumented iperf with and without ipsec, just using esp-null, > and 1 thread, to keep things simple. I'm seeing some pretty dismal > performance numbers with ipsec, and trying to think of ways to >