Estamos mirando para hacer algo pesadas requisitos de seguridad en nuestro proyecto, y tenemos que hacer un montón de cifrado que es altamente eficiente.

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

OriginalEl autor stevemac | 2008-09-23

6 Comentarios

  1. 25

    Sí, puramente de cifrado asimétrico es mucho más lento que cifradores simétricos (como DES o AES), que es la razón por la real en el uso de aplicaciones la criptografía híbrida: la cara de clave pública, las operaciones se realizan sólo para cifrar (y cambio) una clave de cifrado para el algoritmo simétrico que va a ser utilizada para cifrar el mensaje real.

    El problema de que la criptografía de clave pública resuelve es que no hay ningún secreto compartido. Con un cifrado simétrico, usted tiene que confiar en todas las partes involucradas a mantener la clave en secreto. Este problema debe ser una preocupación más grande que el rendimiento (que puede ser mitigado con un enfoque híbrido)

    OriginalEl autor Thilo

  2. 21

    En un Macbook con OS X 10.5.5 y una acumulación de existencias de OpenSSL, «openssl velocidad» relojes AES-128-CBC en 46,000 1024 bloques de bits por segundo. Ese mismo cuadro de relojes RSA de 1024 bits en 169 firmas por segundo. AES-128-CBC es el «libro de texto» bloque algoritmo de cifrado, y RSA de 1024 es el «libro de texto» algoritmo de clave pública. Es de manzanas con naranjas, pero la respuesta es: RSA es mucho, mucho más lento.

    Que no es la razón por la que usted no debe utilizar el cifrado de clave pública, sin embargo. He aquí las razones reales:

    1. Clave pública operaciones de cifrado no están pensados para los datos en bruto de cifrado. Algoritmos como el de Diffie-Hellman y RSA fueron concebidos como una forma de intercambio de claves para el bloque de criptografía algoritmos. Así, por ejemplo, tendría que utilizar un seguro generador de números aleatorios para generar un 128 bits de clave aleatoria para AES, y cifrar los 16 bytes con RSA.

    2. Algoritmos como RSA son mucho menos «amigable» de AES. Con una clave aleatoria, un texto bloque de alimentación para AES va a salir al azar a cualquier persona sin la clave. Que no es realmente el caso con RSA, que es — más de lo AES — sólo una ecuación matemática. Por eso, además de almacenar y administrar las teclas correctamente, tienes que ser extremadamente cuidadoso con la manera de dar formato a tu texto cifrado RSA bloques, o puedes acabar con vulnerabilidades.

    3. Clave pública no funciona sin una infraestructura de gestión de claves. Si usted no tiene un plan para verificar las claves públicas, los atacantes pueden sustituir a sus propios pares de claves de los reales para el lanzamiento de «hombre en el medio» de los ataques. Esta es la razón por SSL obliga a ir a través de la rigamarole de los certificados. Bloque de criptografía algoritmos como AES hacer sufren de este problema, pero sin una PKI, AES no es menos seguro que el RSA.

    4. Operaciones de cifrado de clave pública son susceptibles a más vulnerabilidades de implementación de AES. Por ejemplo, ambos lados de un RSA transacción tiene que estar de acuerdo en parámetros, que son números de la fed a la RSA ecuación. No están mal los valores de los atacantes pueden sustituir en silencio para desactivar el cifrado. Lo mismo va para Diffie Hellman y más aún de Curva Elíptica. Otro ejemplo es el RSA Firma de Falsificación de vulnerabilidad que ocurrió hace 2 años en varias de gama alta de las implementaciones de SSL.

    5. Mediante clave pública es evidencia de que usted está haciendo algo «fuera de lo común». Fuera de lo común, es exactamente lo que nunca quiero estar con criptografía; más allá de los algoritmos de criptografía diseños son revisados y probados durante años antes de que se considera seguro.

    A nuestros clientes que desean utilizar la criptografía en sus aplicaciones, podemos hacer dos recomendaciones:

    • De datos «en reposo», el uso de PGP. De verdad! PGP ha sido una paliza de más de una década y es considerada segura de tonto implementación de errores. No son de código abierto y comercial de variantes de la misma.

    • De datos «en vuelo», el uso de TLS/SSL. Ningún protocolo de seguridad en el mundo, se entiende mejor y la mejor prueba de TLS; instituciones financieras en todas partes lo aceptan como un método seguro para mover los datos más sensibles.

    He aquí una valoración crítica decente [matasano.com] me Nate y Lawson, un profesional criptógrafo, escribió un par de años atrás. Cubre estos puntos con más detalle.

    Parece que el enlace de la valoración crítica que ya no funciona.

    OriginalEl autor tqbf

  3. 6

    Uso de OpenSSL velocidad comando de punto de referencia para los algoritmos y ver por ti 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
    

    OriginalEl autor Cristian Ciupitu

  4. 4

    Prácticos basados en PKI de cifrado de uso de los sistemas de cifrado asimétrico para cifrar una clave simétrica y, a continuación, simétrico de cifrado con la clave para cifrar los datos (habiendo dicho eso, alguien va a señalar un contra-ejemplo).

    Por lo que la sobrecarga adicional impuesta por la asimetría de los algoritmos de criptografía más que de simétrica es fijo que no depende del tamaño de los datos, sólo en los tamaños de clave.

    Última vez que he probado, la validación de una cadena de 3 o así X. 509 certificados [editar para agregar: y los datos que estaban firmando] estaba tomando una fracción de segundo en un BRAZO corriendo a 100MHz o así (promediado a través de muchas repeticiones, obviamente). No recuerdo cómo de pequeña no despreciable, pero mucho menos de un segundo.

    Lo siento, no recuerdo los detalles exactos, pero el resumen es que a menos que usted está en un muy restringido del sistema o haciendo un montón de cifrado (por ejemplo, si se quiere aceptar como muchos como sea posible las conexiones SSL de un segundo), aprobado por NIST cifrado asimétrico métodos son rápidos.

    OriginalEl autor Steve Jessop

  5. 0

    Tal vez usted puede agregar algunos detalles acerca de su proyecto y así obtener una mejor calidad de las respuestas. ¿Qué está tratando de proteger? De quien? Si pudiera explicar los requisitos de su seguridad, usted obtendrá una mejor respuesta. El rendimiento no significa mucho si el mecanismo de cifrado que no es la protección de lo que usted piensa que es.

    Por ejemplo, certificados X509 son un estándar de la industria forma de asegurar cliente/servidor de los extremos. PGP blindaje puede ser usado para asegurar los archivos de licencia. Para la simplicidad, el encadenamiento de bloques de Cifrado con Blowfish (y un anfitrión de otros sistemas de cifrado) es fácil de usar en Perl o Java, si el control de ambos puntos finales.

    Gracias.

    OriginalEl autor jjohn

Dejar respuesta

Please enter your comment!
Please enter your name here