KPP API and Temporary Keys

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

 



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 much targeted at
long-term keys (likely cause most of the crypto API is used that way -
bring up an instance of AES for your drive encryption and keep it around
with the same key forever), and gets rather inefficient if you want to
use it with short-term keys.

eg if you were to implement tcpcrypt with the current API, you're going
to call crypto_alloc_kpp (and, thus, do a locked scan of
crypto_alg_list, a module_get, etc) on every new TCP connection that
successfully negotiates encryption, only to free it in a packet or two
when you've negotiated session keys, and probably keep around an extra
one always to create a module dependency (or am I missing how something
works, there?).

Since I mostly don't know what I'm doing, I figured I should ask what
people think about tweaking the API somewhat:

(0) I missed something obvious about the API (or some other part of
linux-crypto) and should be using it in a much smarter way.

(1) add some new kpp-like API that lets you get a crypto_alg which
doesn't store its own private key but lets you do DH with a provided
private key in the request?

(2) Tweak the KPP API to look more like the above (it has rather few
users in-tree at the moment).

(3) Do some dirty higher-level hack like keeping a pool of crypto_kpps.

I'm happy to work on a patch to do any of the above :).

Thanks,
Matt



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

  Powered by Linux