Re: KPP API and Temporary Keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <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
> 



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux