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.¿Cuál es la diferencia de rendimiento de pki con el cifrado simétrico?
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.
Sí, el cifrado puramente asimétrico es mucho más lento que las cifras simétricas (como DES o AES), por lo que las aplicaciones reales usan hybrid cryptography: las costosas operaciones de clave pública se realizan solo para cifrar (e intercambiar) una clave de cifrado algoritmo simétrico que se utilizará para cifrar 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)
Utilice el comando OpenSSL speed para comparar los algoritmos y verlo usted mismo.
[[email protected] ~]$ 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
[[email protected] ~]$ 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
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.
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 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] tomaba 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 mucha encriptación (como si quiere aceptar el mayor número posible de conexiones SSL por segundo) , Los métodos de encriptación asimétrica aprobados por NIST 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 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.
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, no es por eso que no se debe usar el cifrado de clave pública. He aquí las razones reales:
operaciones criptográficas de clave pública no están destinados para el cifrado de datos en bruto. 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 "fáciles de usar" 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 gestió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 do 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 los parámetros , que son números alimentados a la ecuación 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.
El uso de clave pública es evidencia de que está haciendo algo "fuera de lo común". Fuera de lo común es exactamente lo que nunca desea estar con criptografía; más allá de los algoritmos, los diseños de crypto son auditados y probados por años antes de considerarse seguros.
Para nuestros clientes que quieren usar la criptografía en sus aplicaciones, que hacen dos recomendaciones:
Por "datos en reposo", utilice 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", utilice 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.
Here's a decent writeup [matasano.com] mí y Nate Lawson, un criptógrafo profesional, redactó hace unos años. Cubre estos puntos con más detalle.
Parece que su enlace de la descripción ya no funciona. – skiwi