¿Qué son buenas pruebas para comparar una biblioteca de cifrado?¿Cómo se compara una biblioteca de cifrado?
¿Qué unidad (tiempo, ciclos de CPU ...) deberíamos usar para comparar las diferentes bibliotecas de cifrado?
¿Existen herramientas, procedimientos ...?
Cualquier idea, comentario es bienvenido!
¡Gracias por tus entradas!
¿Qué son buenas pruebas para comparar una biblioteca de cifrado?
Las respuestas a continuación se encuentran en el contexto de Crypto ++. Ahora no me refiero a otras bibliotecas, como OpenSSL, Botan, BouncyCastle, etc.
La biblioteca Crypto ++ tiene una suite de benchmarking incorporada.
Cual unidad (tiempo, los ciclos de CPU ...) debemos utilizar para comparar los differents bibliotecas criptográficas?
Por lo general, mide el rendimiento en ciclos por byte. Los ciclos por byte dependen de la frecuencia de la CPU. Otra métrica relacionada es el rendimiento medido en MB/s. También depende de la frecuencia de la CPU.
¿Hay herramientas, procedimientos ....?
git clone https://github.com/weidai11/cryptopp.git
cd cryptopp
make static cryptest.exe
# 2.0 GHz (use KB=1024; not 1000)
make bench CRYPTOPP_CPU_SPEED=1.8626
make bench creará un archivo llamado benchmark.html.
Si desea ejecutar manualmente las pruebas, entonces:
./cryptest.exe b <time in seconds> <cpu speed in GHz>
Se dará salida a una tabla HTML-como sin <HEAD> y <BODY> etiquetas. Aún podrá verlo en un navegador web.
También puede consultar la página de referencia de Crypto ++ en Crypto++ Benchmarks. La información está fechada, y está en nuestra lista de TODO.
También necesita un presupuesto para lo que parece correcto. Por ejemplo, SSE4.2 y ARMv8 tienen una instrucción CRC32. Los ciclos por byte deben ir de aproximadamente 3 o 5 cpb (solo software) a aproximadamente 1 o 1.5 cpb (aceleración de hardware). Debería equivaler a un cambio de aproximadamente 300 o 500 MB/s (solo software) a aproximadamente 1.5 GB/s (aceleración de hardware) en hardware moderno que corre alrededor de 2 GHz.
Otras tecnologías, como SSE2 y NEON, son más difíciles de trabajar. Hay ciclos teóricos por byte y rendimiento que debería ver, pero es posible que no sepa de qué se trata. Es posible que deba ponerse en contacto con los autores del algoritmo para averiguarlo. Por ejemplo, nos pusimos en contacto con los autores de BLAKE2 para saber si nuestra implementación ARMv7/ARMv8 NEON funcionaba como se esperaba porque era missing benchmark results en la página principal del autor.
También he encontrado que GCC 4.6 (y superior) y -O3 pueden hacer una gran diferencia en las implementaciones de solo software. Esto se debe a que GCC se vectoriza fuertemente en -O3, y es posible que observe una aceleración de 2x a 2.5x. Por ejemplo, el compilador puede generar código que se ejecuta a 40 cpb en -O2. En -O3 puede funcionar a 15 o 19 cpb. Una buena implementación de SSE2 o NEON debe superar la implementación solo de software en al menos unos ciclos por byte. En el mismo ejemplo, la implementación de SSE2 o NEON puede ejecutarse entre 8 y 13 cpb.
También hay sitios como OpenBenchmarking.org que quizás puedan proporcionarle algunas métricas.
Dejando a un lado mis comentarios, el gobierno de EE. UU. Tiene el FIPS program que tal vez quiera consultar. No es perfecto (por una posibilidad remota), pero es un comienzo: puede hacerse una idea de las cosas que estaban viendo cuando evaluaban la criptografía.
También sugiero mirar el Computer Security Division of the NIST.
Además, en una nota al margen ... repasando lo que el maestro tiene que decir (Bruce Schneier) sobre el tema de Security Pitfalls in Cryptography siempre es bueno. También: Security is harder than it looks.
Supongo que se refiere a los puntos de referencia de rendimiento. Yo diría que tanto el tiempo como los ciclos son puntos de referencia válidos, ya que algunos códigos pueden ejecutarse de manera diferente en diferentes arquitecturas (tal vez de forma muy diferente si son lo suficientemente diferentes).
Si es extremadamente importante para usted, yo mismo lo haría. Puede usar algunos temporizadores (casi todos los idiomas tienen uno) o puede usar algún generador de perfiles (casi todos los idiomas tienen uno de estos también) para determinar el rendimiento exacto de los algoritmos que está buscando en su plataforma de destino.
Si está buscando un algoritmo frente a otro, puede buscar datos que otros ya han reunido y que le darán una idea aproximada. Por ejemplo, estos son algunos puntos de referencia de Crypto ++: http://www.cryptopp.com/benchmarks.html
Tenga en cuenta que usan MB/Second y Cycles/Byte como métricas. Creo que esas son muy buenas opciones.
Algunas respuestas muy buenas antes que yo, pero tenga en cuenta que las optimizaciones son una muy buena forma de filtrar el material clave por timing attack (por ejemplo, consulte how devastating it can be for AES). Si hay alguna posibilidad de que un atacante pueda sincronizar sus operaciones, no quiere la biblioteca de tiempo más rápida pero constante disponible (y posiblemente el uso de energía más constante disponible, si hay alguna posibilidad de que alguien pueda monitorear la suya). OpenSSL hace un gran trabajo al estar al tanto de los ataques actuales, no necesariamente puede decir lo mismo de otras bibliotecas.
Va a depender de la biblioteca y los esquemas de encriptación disponibles, y de las opciones de plataforma que tiene disponibles para usted. Por ejemplo: ¿Está probando la clave simétrica o el cifrado de clave asimétrica? ¿Estás probando el cifrado o solo la generación de firma digital? ¿La fortaleza de la clave o el rendimiento bruto son más importantes para usted? –