¿Taxonomía de cifrados / MAC / Kex disponible en SSH?

9

SSH ofrece una gran variedad de algoritmos para las opciones de configuración de Ciphers, MAC y KexAlgorithms. A veces necesito rápido y liviano (mi propia red interna), y otras veces quiero todas las protecciones que puedo obtener (VPN en casa desde DEFCON).

¿Existe una taxonomía de lo que es más lento / más rápido y más / menos seguro (dados los ataques conocidos contra la reducción de la complejidad o el aumento de la probabilidad de colisiones, etc.)  conjunto de algoritmos para cada una de las categorías antes mencionadas?

He leído ¿Cuáles son los cifrados realistas y más seguros para cifrados de código de autenticación de mensajes simétricos, asimétricos, hash, , pero me gustaría ver más información sobre las diferentes recomendaciones por aplicación (servidor robusto a servidor vs dispositivo móvil con vida de batería corta y CPU débil), así como otros efectos secundarios de diferentes modos de operación (CBC vs CTR vs ECB) para el uso interactivo, vs transferencia de archivos.

Adición: Acabo de encontrar este resumen de las velocidades de transferencia efectivas de diferentes cifrado de algos / modos.

    
pregunta Marcin 20.03.2012 - 13:47
fuente

2 respuestas

3

Una respuesta alternativa a lo anterior es que si está preocupado por la seguridad, entonces centrarse en los algoritmos es en gran medida irrelevante, ya que lo que se obtendrá es a través de un error de implementación en su servidor SSH, no a través de alguien que ataque al criptográfico. En particular, si estás haciendo algo como VPN en casa desde DEFCON, entonces debes defenderte de las metasploit, no de un DES-cracker. Podría usar el algoritmo más débil que SSH normalmente admite, un solo DES, y estar perfectamente seguro, porque lo que obtendrá es un 0day en OpenSSH o, si no está ejecutando la última versión, simplemente eso. Entonces realmente estás haciendo la pregunta incorrecta, casi cualquier algoritmo te mantendrá seguro, son los errores de implementación donde te atrapan.

    
respondido por el Dave 21.03.2012 - 07:20
fuente
0

Es poco probable que su elección de cifrado haga una diferencia en el rendimiento de SSH. En la mayoría de los casos, su CPU puede cifrar / descifrar más rápido de lo que su red puede mantener. En la mayoría de las situaciones, el ancho de banda de la red parece ser el factor limitante.

Por lo tanto, sugiero que simplemente deje SSH en sus valores predeterminados. Están bien. Los valores predeterminados son razonablemente seguros y no es probable que la modificación de los valores predeterminados proporcione un rendimiento notablemente mejor.

Si realmente quieres jugar con los parámetros, puedes verificar el uso de compresión de SSH. De forma predeterminada, todos los datos se comprimirán antes de enviarlos a través del canal cifrado. Puede ajustar el nivel de compresión con ssh -o 'CompressionLevel 6' (reemplace 6 con cualquier número del 1 al 9, 1 es el más rápido, 9 es el más lento). Sin embargo, personalmente, no he encontrado ganancias significativas al cambiar el nivel de compresión. Además, si está transfiriendo un archivo que ya está comprimido con scp, puede desactivar la compresión con scp -o 'Compression no' ... . En algunos casos (donde tiene una red muy rápida y una CPU lenta), esto puede ser de ayuda, aunque en mi experiencia no he encontrado que haya una diferencia lo suficientemente grande como para que valga la pena preocuparse.

Edit 3/20: @Marcin menciona que Blowfish obtuvo un mejor desempeño en sus pruebas. De los sistemas de cifrado admitidos en mi cliente OpenSSH, todos los siguientes deberían proporcionar una seguridad sólida:

            aes128-ctr,aes192-ctr,aes256-ctr
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc

Lo más probable es que arcfour128 , arcfour256 y arcfour también brinden una seguridad sólida, aunque no son una opción tan conservadora como las otras. No debe usar des , ya que proporciona una seguridad más débil ( 3des está bien). De los algoritmos de código de autenticación de mensajes (MAC) admitidos en mi cliente OpenSSH, todos los siguientes deberían proporcionar una seguridad sólida:

               hmac-md5,hmac-sha1,umac-64@openssh.com,
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96

De los HostKeyAlgorithms admitidos en mi cliente OpenSSH, todas las opciones compatibles ( ssh-rsa , ssh-dss ) están bien y deberían proporcionar una seguridad sólida, siempre y cuando elijas una clave de suficiente longitud. No estoy familiarizado con la opción KexAlgorithms.

En resumen, básicamente todas las opciones criptográficas proporcionadas deberían ser lo suficientemente seguras, excepto que no use des (y si es conservador, puede evitar los cifrados basados en arcfour , aunque esto probablemente sea solo paranoia) .

    
respondido por el D.W. 21.03.2012 - 01:35
fuente

Lea otras preguntas en las etiquetas