[gnutls-devel] plans for plugin support?

[Nikos Mavrogiannopoulos]

On Mon, 2015-06-01 at 18:26 +0200, Benedikt Klotz wrote:
> Hi Nikos,
> 
> On 01.06.2015 at 15:23 Nikos Mavrogiannopoulos wrote:
> > Hi Benedikt, We have such a plugin API for public key and signature
> > algorithms. The supported plugins are PKCS #11 modules or even custom
> > ones when imported with gnutls_privkey_import_ext3(). 
> If I understand this correctly these functions can only be used from
> within an application, that links with GnuTLS? What I mean with a plugin
> mechanism, is a shared object that is loaded by GnuTLS at runtime. This
> shared object registers an external crypto provider [1] for GnuTLS.

Not really. PKCS #11 modules are shared objects which provide a fixed
API called cryptoki. When for example you use smart cards with gnutls
you are loading the opensc-pkcs11.so under the hoods. gnutls can select
the appropriate module to use when it is configured with p11-kit in the
local system (in most systems it is setup by the distribution).

See:
http://www.gnutls.org/manual/html_node/Smart-cards-and-HSMs.html#Smart-cards-and-HSMs
for more information.

> > For symmetric key algorithms we support cryptodev (i.e., /dev/crypto)
> > on systems that support it. Are there any other plugin mechanisms you
> > are interested at?
> If I understand this correctly /dev/crypto is a kernel device. I am more
> interested in /lib/accelerated, because the external provider does not
> use /dev/crypto.
> I could write my code in a module under /lib/accelerated. However my
> code needs to call dlopen(), because the only right way [3] to enable
> the external provider is through another library.
> Is this something you would accept?

What API does that module provide? If it is PKCS #11 or some other
standardized API that would be indeed quite interesting.

> However this would not solve the problem that an application can not
> change the crypto backend to another provider. I would still prefer a
> plugin concept, where an application (or GnuTLS for the application) can
> load a shared object, that setups the external provider. This would give
> the maximum flexibility. 

For asymmetric keys this flexibility is currently available, so your
argument is about symmetric algorithm if I understand correctly. Let's
first settle on what module API we are talking about and then we see
(because if for example this is about a PKCS #11 API we can have this
flexibility using p11-kit again).

regards,
Nikos