Anteriormente en este mismo diario:

Lo que sí me parece buena idea es la intención de unificar claves y certificados en un único lugar (y formato). Pero para ello no hace falta tanto una reescritura de aplicaciones como la creación de un estándar, por ejemplo alrededor de los de FreeDesktop. FreeDesktop ya tiene estandarizados directorios para datos de aplicaciones, configuración o ficheros temporales, y no costaría mucho ampliarlo para claves y certificados. Añadiendo uno (o varios) formatos para reconocer los diferentes objetos, quedaría al albur de cada biblioteca implementar el estándar en su código. Algo bastante menos intrusivo que mandar parches a decenas de aplicaciones.

Pues resulta que ese proyecto existe: p11-glue:

On the desktop today we have a variety of technically excelent crypto libraries (such as NSS, GnuTLS, OpenSSL etc.) The diversity allows each to excel and progress in its area of focus. Applications choose to use different crypto libraries for all sorts of good reasons.

Users suffer because the desktop lacks a consistent way to use certificates or keys with all the various applications. For example different applications look for their trust anchor certificates in different places, and configuring each application with a client certificate is a laborious task. [...]

PKCS#11 is a standard for accessing crypto objects like keys and certificates and performing cryptographic operations on them.

By using PKCS#11 to provide a plugable way for crypto libraries and other software to access keys, certificate, and things like trust anchors, we can solve the above problems.

Y es que no hay nada nuevo bajo el sol.

Lo descubrí porque casualmente ayer se me actualizó el paquete libp11-kit0, que forma parte de p11-kit.

Otra biblioteca que no mencioné y creo que es interesante hacerlo es nettle (en Debian dividida en dos bibliotecas, libnettle y libhogweed):

Nettle is a cryptographic library that is designed to fit easily in more or less any context: In crypto toolkits for object-oriented languages (C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in kernel space.

It tries to solve a problem of providing a common set of cryptographic algorithms for higher-level applications by implementing a context-independent set of cryptographic algorithms. In that light, Nettle doesn't do any memory allocation or I/O, it simply provides the cryptographic algorithms for the application to use in any environment and in any way it needs.

This package contains the symmetric and one-way cryptographic algorithms. To avoid having this package depend on libgmp, the asymmetric cryptos reside in a separate library, libhogweed.

Estas bibliotecas sirven para resolver el otro problema del que hablé: la implementación de algoritmos criptográficos. En vez de intentar implementar un algoritmo por tu cuenta, nettle ya te ofrece implementaciones de cifras simétricas como DES, Triple DES, AES, Blowfish, Twofish, Camellia, funciones hash como MD5, SHA1, SHA256, SHA3, y de cifras asimétricas como RSA, DSA, de curva elíptica, diferentes modos de cifrado, HMAC, etc, etc. Es una suite muy completa y raro sería que no encontraras todo lo que necesitas ya implementado ahí.

Nettle es LGPL y se usa como alternativa a libgcrypt en partes de GnuTLS (o al menos eso dice Wikipedia).

Por último, echemos un vistazo (parcial) a las dependencias de estas bibliotecas en mi Debian. He intentado incluir sólo paquetes sigficativos (instalados) que dependen de cada biblioteca para poner de relieve su uso:

(Ampliar - Fichero .dot)

He marcado con naranja las bibliotecas criptográficas mencionadas en este artículo. Los paquetes azul claro (hay de 2 tipos) son gnupg y gnupg versión 2. Se observa que gnupg no usa ninguna criptobiblioteca, mientras que la versión 2 usa libgcrypt (pero no libnettle).

En cuanto a la cripto-consolidación, la mayoría de los paquetes en Debian usan GnuTLS versión 2.12, y muy pocos han migrado a la versión estable actual GnuTLS 3.2. Los principales usuarios de libnss en mi instalación son firefox/iceweasel y libreoffice, y OpenSSL apenas lo usan paquetes. Las cifras totales de dependencias inversas de cada uno ahora mismo son estas:

$ apt-cache rdepends libgnutls26 | wc -l
277
$ apt-cache rdepends libgnutls28 | wc -l
24
$ apt-cache rdepends openssl | wc -l
95
$ apt-cache rdepends libnss3 | wc -l
124

La impresión que uno saca de estos datos es que Debian sigue una línea distinta de la que pretende Fedora, primando GnuTLS sobre las otras.

:wq