On Fri, Jul 28, 2017 at 4:00 PM, Matt Corallo <linux@xxxxxxxxxxx> wrote: > > Even worse, when I'm looking at tcpcrypt, not adding undue complication, > or, really, overhead, is a pretty important goal for something in the > tcp stack (especially for someone who doesn't know the TCP stack, and > avoiding complexity is a good target for avoiding breaking things), and > while a pool of "workers" should work fine, spending time optimizing > that to ensure it properly frees workers if load decreases (or memory > load increases) while avoiding hitting the slowpath all the time strikes > me as non-ideal complexity. For performance reasons, we're probably going to want to go the route of generating one ECDH share every N seconds for small N, since computing the public share for a randomly-selected point requires an EC point multiplication that you don't necessarily want to do on every connection. (You already have to do one per connection for the actual key agreement; better to avoid doing two.) Every few seconds isn't long-term, but it does mean that a pool has somewhat different implications as keys can be shared between them, assuming they're const. You could refcount them, always use the newest one when a connection is opened, and then throw away old ones when the refcount hits zero. Kyle
