Ir con RSA.
El DSA es más rápido para la generación de firmas pero más lento para la validación, más lento cuando se encripta, pero más rápido cuando el descifrado y la seguridad pueden considerarse equivalentes en comparación con una clave RSA de igual longitud de clave. Esa es la línea de golpe, ahora una cierta justificación.
La seguridad del algoritmo RSA se basa en el hecho de que factorización de enteros grandes se sabe que es "difícil" , mientras que la seguridad de DSA se basa en el problema logaritmo discreto . Hoy en día, el algoritmo más rápido conocido para factorizar enteros grandes es el Tamiz de campo de número general , también el algoritmo más rápido para resolver el problema del logaritmo discreto en campos finitos, módulo a p grande como se especifica para DSA.
Ahora, si la seguridad se puede considerar igual, favoreceríamos el algoritmo que sea más rápido. Pero una vez más, no hay un ganador claro.
Puede consultar este estudio o, si tiene OpenSSL instalado en su máquina, ejecute openssl speed . Verá que DSA se realiza más rápido en la generación de una firma pero mucho más lento al verificar una firma de la misma longitud de clave. La verificación es generalmente lo que quieres que sea más rápido si tratas, por ejemplo. con un documento firmado. La firma se genera una vez, por lo que está bien si esto toma un poco más de tiempo, pero los usuarios finales pueden verificar la firma del documento con mucha más frecuencia.
Ambos admiten algún tipo de método de encriptación, RSA listo para usar y DSA usando un El Gamal . DSA es generalmente más rápido en descifrado pero más lento para el cifrado, con RSA es al revés. Una vez más, desea que el descifrado sea más rápido aquí porque un documento cifrado puede descifrarse muchas veces.
En términos comerciales, RSA es claramente el ganador, los certificados RSA comerciales se implementan mucho más ampliamente que los certificados DSA.
Pero guardé el argumento asesino para el final: man ssh-keygen dice que una clave DSA debe tener exactamente 1024 bits de largo para ser compatible con el FIPS 186-2 . Entonces, aunque en teoría las claves DSA más largas son posibles (FIPS 186-3 también las permite explícitamente), usted todavía está restringido a 1024 bits. Y si toma las consideraciones de este [artículo], ya no estamos seguros con 1024 bits para RSA o DSA.
Así que hoy en día, eres mejor con una clave RSA de 2048 bits.
En este momento, la pregunta es un poco más amplia: RSA frente a DSA frente a ECDSA frente a Ed25519 . Entonces:
Una presentación en BlackHat 2013 sugiere que se han logrado avances significativos en la solución de los problemas de complejidad. Se basa la fuerza de DSA y algunos otros algoritmos, por lo que pueden matemáticamente romperse muy pronto. Además, el ataque puede ser posible (pero más difícil) para extenderse también a RSA.
La presentación sugiere usar criptografía de curva elíptica en su lugar. Los algoritmos ECC compatibles con OpenSSH son ECDSA y, desde OpenSSH 6.5, Ed25519.
OpenSSH solo admite curvas NIST para ECDSA y de acuerdo con este estudio esas curvas parecen realmente sospechosas para < fuerte> puertas traseras de la NSA. Y si la NSA ya puede romperla, entonces no será tan difícil de descifrar para otra persona como lo sería una curva adecuada. Ed25519 es lo mismo pero con una curva mejor, por lo que es la apuesta más segura contra el rompimiento del algoritmo subyacente matemáticamente .
Además, DSA y ECDSA tienen una propiedad desagradable: requieren un parámetro generalmente llamado k para ser completamente aleatorio, secreto y único. En la práctica, eso significa que si se conecta a su servidor desde una máquina con un generador de números aleatorios deficiente y, por ejemplo, Si se utiliza el mismo k dos veces, un observador del tráfico puede averiguar su clave privada. (fuente: Wikipedia en DSA y ECDSA , también this ).
La conclusión es:
En SSH, en el lado del cliente, la elección entre RSA y DSA no importa mucho, porque ambos ofrecen una seguridad similar para el mismo tamaño de clave (use 2048 bits y estará contento).
Históricamente, la versión 1 del protocolo SSH solo admitía claves RSA. Cuando se definió la versión 2, RSA todavía estaba patentada, por lo que se agregó el soporte de DSA, para que se pudiera realizar una implementación libre de patentes de código abierto. La patente RSA expiró hace más de 10 años, por lo que no hay que preocuparse ahora.
Teóricamente, en algunas situaciones muy específicas, puede tener un problema de rendimiento con uno u otro: si el servidor es una máquina muy pequeña (por ejemplo, un i486), preferirá clientes con claves RSA, porque verificará un RSA la firma es menos costosa computacionalmente que la verificación de una firma DSA. A la inversa, una firma DSA es más corta (por lo general, 64 bytes frente a 256), por lo que si tiene poco ancho de banda, preferirá DSA. De todos modos, tendrá dificultades para detectar esos efectos, y mucho menos para encontrarlos importantes.
En el servidor , se prefiere una clave DSA, porque entonces el intercambio de claves usará una clave Diffie-Hellman transitoria, que abre el camino hacia el "Secreto Directo Perfecto" (es decir, si un tipo malo roba la clave privada del servidor, todavía no puede descifrar las conexiones pasadas que habría registrado).
Otra ventaja importante de RSA sobre DSA y ECDSA es que nunca necesitas un generador de números aleatorios seguro para crear firmas.
Para generar una firma, (EC) DSA necesita un valor que debe ser aleatorio, secreto / impredecible y nunca se puede usar nuevamente . Si se viola una de esas propiedades, es posible recuperar de forma trivial la clave privada de una o dos firmas .
Esto sucedió antes (una vez con un parche roto de OpenSSL PRNG en Debian, y una vez con un error en la implementación SecureRandom de Android), y es bastante difícil de prevenir por completo.
Con RSA, en esas situaciones solo su clave de sesión efímera se habría visto comprometida, si los pares de claves de autenticación reales se hubieran creado utilizando un PRNG correctamente sembrado anteriormente.
Teóricamente, hay una manera de hacer que las firmas DSA (EC) dependan del mensaje y la clave privada, que pueden evite el error total en caso de un RNG dañado, pero hasta que esto se integre en su cliente SSH (no hay una versión de lanzamiento de OpenSSL que incluya el parche en este momento), definitivamente iría con las claves RSA.
No sabiendo mucho sobre criptografía, como usuario de OpenSSH me atendría a un hecho simple: en enlace , que dice que SHA1 ahora está deshabilitado de forma predeterminada porque se considera débil:
OpenSSH 7.0 y superior deshabilita de forma similar el algoritmo de clave pública ssh-dss (DSA) . También es débil y recomendamos su uso.
RSA y DSA son dos algoritmos completamente diferentes. Las claves RSA pueden alcanzar hasta 4096 bits, donde DSA tiene que ser exactamente de 1024 bits (aunque OpenSSL permite más). Según Bruce Schneier, "tanto DSA como RSA con las mismas claves de longitud son casi idénticas en dificultad de descifrar".
El problema con ECDSA no es tanto puertas traseras. Bernstein / Lange mencionan específicamente que el criptoanálisis de curvas no ataca curvas específicas, sino clases de curvas (vea diapositiva 6 ).
El problema con ECDSA es que las curvas NIST son difíciles de implementar correctamente (es decir, tiempo constante y con toda la verificación adecuada) en comparación con Curve25519. OpenSSL tiene una implementación constante de P256 , por lo que OpenSSH es seguro en ese respecto
Si todavía estás preocupado por las curvas NIST, OpenSSH recientemente agregó soporte para el esquema Ed25519
Las matemáticas pueden no importar. Este hilo parece pre-Snowden. Aquí hay un artículo de Reuters del 20 de diciembre de 2013 :
(Reuters) - Como parte clave de una campaña para integrar software de cifrado que podría romperse en productos informáticos ampliamente utilizados, los EE. UU. La Agencia de Seguridad Nacional organizó un contrato secreto de $ 10 millones con RSA, una de las firmas más influyentes en la seguridad informática. industria, ha sabido Reuters.
Los documentos filtrados por el ex contratista de la NSA Edward Snowden muestran que la La NSA creó y promulgó una fórmula defectuosa para generar al azar números para crear una "puerta trasera" en los productos de encriptación, el New York Tiempos reportados en septiembre. Reuters informó más tarde que RSA se convirtió El distribuidor más importante de esa fórmula al convertirlo en un herramienta de software llamada Bsafe que se utiliza para mejorar la seguridad en Computadoras personales y muchos otros productos.
No revelado hasta ahora fue que RSA recibió $ 10 millones en un acuerdo que establece la fórmula NSA como el método preferido, o predeterminado, para el número Generación en el software BSafe, según dos fuentes familiares. con el contrato. Aunque esa suma pudiera parecer mísera, representaba más de un tercio de los ingresos que tenía la división correspondiente en RSA tomadas durante todo el año anterior, muestran las presentaciones de valores.
Durante este podcast de Science Friday, Ira pregunta a Matt Green , Martin Hellman (inventor de Public Key Cryptography) y Phil Zimmerman (creador de PGP) lo que creen que la NSA ha descifrado:
(alrededor de las 17:26)
Ira : ¿Cuáles son algunas de las cosas que sabemos en las que la NSA ha incursionado?
Matt : Así que hemos escuchado una serie de cosas que probablemente podemos acreditar como reales. ... generadores de números aleatorios ... lo sabemos que la NSA a través del NIST ... es muy probable que haya puertas traseras en algunos de esos algoritmos estándar que les permiten esencialmente romper esos sistemas en su totalidad.
Ira : ¿Quieres decir que la NSA creó esas puertas traseras?
Matt : Eso es exactamente correcto. Entonces, NIST trabaja con la NSA, y están obligados por ley. Pensamos que NSA estaba ayudando a NIST desarrollando más estándares seguros para que los estadounidenses utilicen. Ahora sospechamos --- y tenemos pruebas sólidas para creer --- que la situación era exactamente la opuesto; que NIST estaba siendo utilizado para poner estándares que la NSA podría romperse.
Teniendo en cuenta estas recientes revelaciones, la fuerza de los algoritmos parece en gran medida irrelevante. RSA parece haber sido una empresa privada comprada de algún modo por la NSA, y la DSA fue creada por el NIST, que, según estos expertos, es en gran medida un frente para la investigación de criptografía de la NSA.
En otras palabras, realmente no importa si está utilizando los generadores de números aleatorios que vienen con casi cualquier computadora moderna, como hacen OpenSSH y otros.
Elige el que sea más rápido para lo que quieres. En mi caso, reutilizo la misma clave para muchas cosas, por lo que la velocidad de generación más rápida de DSA es menos deseable. Además, tal vez exista una gran posibilidad de que RSA fuera en realidad una entidad independiente de NIST y NSA, mientras que sabemos que DSA fue creada por NIST.
Personalmente, solo uso claves de 1028 bits porque, como hemos visto, realmente no importa a menos que alguien te esté imponiendo algún requisito que aún crea que las claves más grandes te protegerán. Todo esto es, en gran medida, solo una molestia para cualquiera que busque entrar.
Lea otras preguntas en las etiquetas authentication key-management cryptography encryption ssh