sáb 25 enero 2014
Por Javier Cantero
En Linux .
etiq.: criptografia bibliotecas debian
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