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 writt
On Fri, Jul 28, 2017 at 4:00 PM, Matt Corallo 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
Yea, and while I understand this API is very useful for hardware
accelerated (and, more often, secured) crypto and generally being very
neatly pluggable, its, IMO, significantly less useful for many key
agreement uses-cases.
At least in the ever-more-used pattern of doing temporary key agreement
f
Am Freitag, 28. Juli 2017, 02:16:24 CEST schrieb Matt Corallo:
Hi Matt,
> Hi linux-crypto,
>
> Working on hacking together a tcpcrypt implementation which needs to use
> KPP/ECDH based on new temporary keys for each new connections which uses
> encryption. Sadly, the KPP API seems to be very muc
