[gnutls-devel] plans for plugin support?

[Benedikt Klotz]

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.

This could be used if an applications wants to use  an external crypto
provider as the default implementation for some crypto algorithms (e.g.
a provider that uses a crypto card to accelerate specific crypto
algorithms) . Of course, the application can use
gnutls_crypto_register_cipher/digest()  to use another implementation.
However with these functions the application has to write the glue code
himself.  If this glue code is moved in a shared object the application
does only need to load this shared object. For an application this would
also allow to easily change the cryptographic backend of GnuTLS at
runtime [2].


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

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. 
>
> regards,
> Nikos

regards,
Benedikt

---------------------------
[1]: E.g. opens the library of the external crypto provider with
dlopen() and then overrides specific crypto algorithms of the default
backend with the implementation from the external provider.
[2]: This could be interesting for a testing application that wants to
compare different crypto implementations with GnuTLS.
[3]: I do not want to reinvent the wheel.