Hmm, fair, I hadn't considered the desire to pre-cache keys with the rest, in which case I suppose the existing API is likely about as good as you'd need (+/- duplicative extra tfm overhead, which annoys me, but likely isn't actually worth worrying about). I'll retract my criticism until I've written a full "worker" cache and see what it looks like.
Matt On 07/28/17 16:20, Kyle Rose wrote: > On Fri, Jul 28, 2017 at 4:00 PM, Matt Corallo <li...@bluematt.me> 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 >
