performance - simetrica - ¿Cuál es la diferencia de rendimiento de pki en encriptación simétrica?

estándar internacional de infraestructura de claves públicas pki (6)

Estamos buscando hacer algunos requisitos de seguridad pesados en nuestro proyecto, y tenemos que hacer una gran cantidad de encriptación que es altamente eficiente.

Creo que sé que PKI es mucho más lento y más complejo que el cifrado simétrico, pero no puedo encontrar los números para respaldar mis sentimientos.

Aparentemente es 1000 veces peor. ( http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html ). Pero a menos que realmente esté trabajando con muchos datos, no va a importar. Lo que puede hacer es usar un cifrado asimétrico para intercambiar una clave de cifrado simétrica.

En una Macbook que ejecuta OS X 10.5.5 y una compilación en stock de OpenSSL, la velocidad "openssl" encierra AES-128-CBC en 46,000 bloques de 1024 bits por segundo. Esa misma caja marca RSA de 1024 bits a 169 firmas por segundo. AES-128-CBC es el algoritmo de cifrado de bloques "libro de texto", y RSA 1024 es el algoritmo de clave pública "libro de texto". Son manzanas a naranjas, pero la respuesta es: RSA es mucho, mucho más lento .

Sin embargo, esa no es la razón por la cual no se debe usar el cifrado de clave pública. Aquí están las verdaderas razones:

Las operaciones de cifrado de clave pública no están pensadas para el cifrado de datos sin formato . Algoritmos como Diffie-Hellman y RSA se idearon como una forma de intercambiar claves para algoritmos de criptografía de bloques. Entonces, por ejemplo, usaría un generador seguro de números aleatorios para generar una clave aleatoria de 128 bits para AES y encriptaría esos 16 bytes con RSA.
Algoritmos como RSA son mucho menos "amigables para el usuario" que AES . Con una clave aleatoria, un bloque de texto sin formato que alimente a AES saldrá al azar a cualquiera que no tenga la clave. Ese no es realmente el caso con RSA, que es --- más que AES --- solo una ecuación matemática. Por lo tanto, además de almacenar y administrar las claves correctamente, debe ser extremadamente cuidadoso con la forma en que formatea sus bloques de texto simple RSA, o termina con vulnerabilidades.
La clave pública no funciona sin una infraestructura de administración de claves . Si no tienes un esquema para verificar las claves públicas, los atacantes pueden sustituir sus propios pares de claves por los reales para lanzar ataques de "hombre en el medio". Esta es la razón por la que SSL te obliga a pasar por el rigamarole de certificados. Los algoritmos de criptografía en bloque como AES también sufren este problema, pero sin una PKI, AES no es menos seguro que RSA.
Las operaciones de cifrado de clave pública son susceptibles a más vulnerabilidades de implementación que AES . Por ejemplo, ambos lados de una transacción RSA tienen que acordar parámetros , que son números alimentados a la ecuación de RSA. Hay valores malvados que los atacantes pueden sustituir para desactivar silenciosamente el cifrado. Lo mismo vale para Diffie Hellman y aún más para Elliptic Curve. Otro ejemplo es la vulnerabilidad de RSA Signature Forgery que ocurrió hace 2 años en múltiples implementaciones SSL de alta gama.
Usar la clave pública es evidencia de que estás haciendo algo "fuera de lo normal" . Fuera de lo común es exactamente lo que nunca quieres ser con la criptografía; más allá de los algoritmos, los diseños de criptografía son auditados y probados por años antes de que se los considere seguros.

Para nuestros clientes que desean utilizar la criptografía en sus aplicaciones, hacemos dos recomendaciones:

Para "datos en reposo", use PGP . ¡De Verdad! PGP ha sido golpeado por más de una década y se considera seguro contra errores de implementación tontos. Hay versiones de código abierto y comerciales de la misma.
Para "datos en vuelo", use TLS / SSL . Ningún protocolo de seguridad en el mundo se comprende mejor y se prueba mejor que TLS; las instituciones financieras de todo el mundo lo aceptan como un método seguro para mover los datos más confidenciales.

Aquí hay un escrito decente [matasano.com] y Nate Lawson, un criptógrafo profesional, escribió hace unos años. Cubre estos puntos con más detalle.

Los sistemas de encriptación basados en PKI prácticos usan cifrado asimétrico para encriptar una clave simétrica, y luego cifrado simétrico con esa clave para encriptar los datos (una vez dicho esto, alguien señalará un contraejemplo).

Por lo tanto, la sobrecarga adicional impuesta por los algoritmos criptográficos asimétricos sobre la de simétrica es fija: no depende del tamaño de los datos, solo de los tamaños de clave.

La última vez que probé esto, validar una cadena de 3 o más certificados X.509 [editar para agregar: y los datos que estaban firmando] estaba tomando una fracción de segundo en un ARM corriendo a 100MHz más o menos (promediado sobre muchas repeticiones, obviamente). No puedo recordar lo pequeño, no desdeñable, pero menos de un segundo.

Lo siento, no puedo recordar los detalles exactos, pero el resumen es que a menos que esté en un sistema muy restringido o haciendo un montón de encriptación (como si quiere aceptar el mayor número posible de conexiones SSL por segundo), aprobado por el NIST los métodos de encriptación asimétrica son rápidos.

Quizás pueda agregar algunos detalles sobre su proyecto para que pueda obtener respuestas de mejor calidad. ¿Qué estás tratando de asegurar? ¿De quien? Si pudiera explicar los requisitos de su seguridad, obtendrá una respuesta mucho mejor. El rendimiento no significa mucho si el mecanismo de cifrado no protege lo que usted cree que es.

Por ejemplo, los certificados X509 son una forma estándar industrial de asegurar puntos finales de cliente / servidor. El blindaje de PGP se puede usar para proteger los archivos de licencia. Para simplificar, el encadenamiento de bloques Cipher con Blowfish (y una gran cantidad de otras cifras) es fácil de usar en Perl o Java, si controla ambos puntos finales.

Gracias.

Sí, el cifrado puramente asimétrico es mucho más lento que los cifrados simétricos (como DES o AES), por lo que las aplicaciones reales usan criptografía híbrida : las costosas operaciones de clave pública se realizan solo para cifrar (e intercambiar) una clave de cifrado para el algoritmo simétrico va a ser utilizado para encriptar el mensaje real.

El problema que resuelve la criptografía de clave pública es que no hay un secreto compartido. Con un cifrado simétrico, debe confiar en todas las partes involucradas para mantener la clave en secreto. Este problema debería ser mucho más preocupante que el rendimiento (que puede mitigarse con un enfoque híbrido)

Use el comando de speed OpenSSL para comparar los algoritmos y ver por usted mismo.

[dave@hal9000 ~]$ openssl speed aes-128-cbc Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc''s in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc''s in 3.00s ... The ''numbers'' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 139343.68k 152748.27k 155215.70k 155745.61k 157196.29k [dave@hal9000 ~]$ openssl speed rsa2048 Doing 2048 bit private rsa''s for 10s: 9267 2048 bit private RSA''s in 9.99s Doing 2048 bit public rsa''s for 10s: 299665 2048 bit public RSA''s in 9.99s ... sign verify sign/s verify/s rsa 2048 bits 0.001078s 0.000033s 927.6 29996.5