¿Existe una biblioteca ligera que pueda realizar el cifrado RSA-2048 para una aplicación integrada?

Estoy buscando una implementación C/C++ de RSA con una clave de 2048 bits (preferiblemente leída desde un archivo). Mi objetivo es una plataforma integrada, por lo que viene con algunas restricciones extrañas. El hardware nos impide usar el nuevo operador y tenemos que usar una versión especial de malloc proporcionada por el fabricante del hardware llamada "umalloc". Si es necesario, puedo profundizar en la fuente y reemplazar las llamadas malloc a mano, pero me gustaría evitar eso. La solución más ideal sería encontrar una biblioteca que pueda realizar el cifrado RSA pero sin usar excepciones ni asignación dinámica.

He estado investigando esto durante aproximadamente una semana y me he encontrado con varias bibliotecas diferentes en los distintos sitios web de stackexchange. Ver aquí y aquí . Quería reabrir esta pregunta ya que la mayoría de las preguntas que encontré tenían varios años y quiero ver si las opiniones sobre esas bibliotecas siguen siendo ciertas.

Hasta ahora aquí están las siguientes bibliotecas que he encontrado

  • OpenSSL: la opción más popular. Al ver que SOLO quiero hacer el cifrado RSA, OpenSSL parece una exageración. Además, reemplazar malloc en la fuente parece demasiado esfuerzo.
  • LibreSSL: Bifurcación de OpenSSL. Viene con los mismos problemas que OpenSSL.
  • crypto++: biblioteca de C++, pero usa excepciones. No se puede usar.
  • axTLS: parece muy ligero, y estoy investigando esta biblioteca en este momento. Sin embargo, me ha costado entender cómo leer una clave pública en su interfaz.
  • libcrypto: acabo de descubrir esta biblioteca hace unas horas. Actualmente investigando.

Idealmente, lo que espero es colocar algunos archivos y usar un puñado de funciones para comenzar. ¿Existen bibliotecas más allá de las que he enumerado que pueden realizar el cifrado RSA-2048 y hacerlo sin usar excepciones o asignación de memoria dinámica? Gracias

Una cosa que debe tener en cuenta e investigar son las restricciones de exportación que, al incluir el código RSA-2048 en su objetivo incrustado, inevitablemente se aplicarán a todo el dispositivo. Los EE. UU., y varios otros países, consideran la criptografía por encima de cierto nivel como tecnología de armas.
¿Estás hablando de ITAR? ¿Esto se refiere a algo que está encriptado con RSA-2048?
@HD_Mouse La mayoría de las cosas que encriptaría con RSA estarían cubiertas (básicamente cualquier cosa excepto una contraseña). Firmar está bien. Sin embargo, si la función del dispositivo no es principalmente realizar criptografía, el dispositivo en su conjunto no tendría las mismas restricciones que el código de cifrado. Sí, es un poco tonto. Lo que estoy escribiendo aquí es solo un resumen muy breve, investigue esto adecuadamente antes de comenzar a enviar software o hardware a través de las fronteras.
¿Podrías reemplazar RSA con ECC?
@CodesInChaos No creo que sea una opción, ya que solo estoy escribiendo un extremo de la ruta de datos. Se espera que los datos lleguen encriptados con una clave pública RSA y no creo que tenga la autoridad para cambiar eso.
@HD_Mouse: en los EE. UU., ITAR y EAR, pero otros países como el Reino Unido también tienen sus propias restricciones y las restricciones varían de vez en cuando y los condados involucrados. Algunos inspectores/asesores juzgarán sobre el uso y algunos lugares insistirán en el acceso a llaves/semillas u otras puertas traseras. Ver en.wikipedia.org/wiki/… y en.wikipedia.org/wiki/…
¿Ha considerado una versión anterior de Crypto ++? La versión 4.1 no usa excepciones en el código RSA y simplemente no puede compilar las partes de la biblioteca que las usan. No sé cuánto reemplazo de nuevo/eliminar sería necesario.
@Mark gracias por traerme eso a la atención. La página principal de Crypto++ no tenía una opción para descargar una versión anterior. Aunque desconfío de usar una versión anterior de una biblioteca criptográfica. ¿No estaría abierto a vulnerabilidades? ¿O es el componente RSA lo suficientemente maduro como para no requerir ninguna actualización?
@HD_Mouse, depende de lo que le preocupe. Si le preocupan los ataques de canal lateral, como que alguien deduzca la clave midiendo la salida de calor o el consumo de energía, una versión anterior podría tener problemas; de lo contrario, RSA es un algoritmo maduro y no debería haber vulnerabilidades en sus implementaciones.
Consulte también Implementaciones de bibliotecas criptográficas livianas (no estoy cerrando como un duplicado porque los requisitos no son exactamente los mismos y cada pregunta admite respuestas que no encajarían en la otra pregunta)
Una opción adicional puede ser BearSSL , que se dirige específicamente a entornos sin asignaciones de memoria dinámica y con poca disponibilidad de RAM. Además, su código está específicamente escrito para ser resistente y realizar operaciones en el tiempo independientemente de los valores secretos ("tiempo constante").

Respuestas (2)

Sí, LibTomCrypt . LibTomCrypt implementa las primitivas criptográficas más comunes (y muchas poco comunes) , incluido RSA (modos PKCS#1 v1.5, PSS y OAEP). El código es C limpio y portátil, por lo que puede vincularlo a aplicaciones escritas en prácticamente cualquier lenguaje de programación. La biblioteca está hecha de objetos pequeños para que solo el código que realmente necesita se vincule a su binario. La licencia te permite hacer, literalmente, lo que quieras.

Las operaciones matemáticas se realizan mediante la biblioteca complementaria LibTomMath (código altamente portátil y legible) o TomsFastMath (con optimizaciones para algunas plataformas, incluido ARM).

Usos de LibTomCrypt mallocy co. para la gestión de la memoria de forma predeterminada, pero puede sustituir otros cuando construya la biblioteca ( #define XMALLOC umallocetc.).


LibTomCrypt solo hace cripto primitivos, no hace certificados o protocolos de red. Si necesita SSL/TLS, le sugeriremos tentativamente mbed TLS , anteriormente conocido como PolarSSL. Tentativamente porque nunca lo he usado en un proyecto integrado.

Es mantenido por ARM, por lo que puede esperar un código que funcione bien en las plataformas ARM (aunque, que yo sepa, no hay optimizaciones particulares, por ejemplo, no hay un ensamblaje ARM opcional, solo C portátil). Para proyectos de código abierto, la biblioteca tiene licencia GNU GPL (no LGPL), que es restrictiva, pero hay excepciones que permiten la vinculación con código fuente abierto que no es GPL. Una licencia que permite la distribución de código cerrado también está disponible por una tarifa.

El código fuente es C bastante limpio y portátil. Parte del código central no se usa mallocen absoluto, y el código que sí siempre usa polarssl_mallocy polarssl_free(no se usa realloc), lo que facilita la sustitución de otros asignadores si es necesario.

Las curvas elípticas también son compatibles si migra a algo más rápido y más pequeño que RSA en algún momento.

¡Gracias por presentarme esto! Esto parece muy prometedor, pero la licencia GPL es definitivamente restrictiva. Discutiré con mis colegas si estaríamos dispuestos a pagar la tarifa por una distribución de fuente cerrada. Me abstendré de aceptar esto como la respuesta en caso de que se revele una solución más prometedora.
La biblioteca ahora también tiene licencia de la versión 2 de Apache. Lo que significa que puede usarse incluso en proyectos comerciales patentados de código cerrado sin ningún costo. Mientras buscaba una biblioteca RSA mucho más pequeña, no pude encontrar algo, así que tomé esta respuesta también. No puedo entender por qué no hay una solución de un archivo pequeño para ello.
@Lothar Mirando hacia atrás en esta respuesta, ¿por qué alguna vez recomendé polar? Eso es para SSL, pero eso no es lo que hace la pregunta. Editado. ¡Usa libtomcrypt!
@HD_Mouse Mirando hacia atrás en esta respuesta, ¿por qué alguna vez recomendé polar? Eso es para SSL, pero eso no es lo que hace la pregunta. Editado. ¡Usa libtomcrypt!

En 2019, la mejor biblioteca C de criptografía integrada es probablemente BearSSL . Además de que, en mi opinión, es bastante seguro (considera mucho los ataques de canal lateral), es muy compacto y está diseñado para no asignar memoria de forma dinámica (por ejemplo, no llama a malloc).