Evaluación comparativa de cifrados SSH: Cómo elegir el cifrado más rápido para tu red

La evaluación comparativa de cifrados SSH es útil cuando las transferencias cifradas son más lentas de lo que la red debería permitir. El cifrado no siempre es el cuello de botella, pero en enlaces rápidos o CPUs pequeñas puede decidir si scp, sftp o rsync -e ssh saturan la conexión.

La respuesta correcta depende de tu cliente, servidor, características de la CPU, compilación de OpenSSH y ruta de red. Prueba en tu propio entorno antes de cambiar los valores predeterminados en toda la flota.

Comprendiendo los cifrados SSH y su función

Un cifrado SSH es un algoritmo utilizado para cifrar y descifrar los datos intercambiados entre un cliente y un servidor SSH. Su objetivo principal es garantizar la confidencialidad, integridad y autenticidad de la comunicación. Cuando inicias una conexión SSH, el cliente y el servidor negocian un conjunto de algoritmos (cifrados, MACs, métodos de intercambio de claves) que ambos soportan, acordando finalmente las opciones más fuertes y preferidas. Este proceso de negociación es crítico para establecer un canal seguro.

Diferentes cifrados emplean operaciones matemáticas distintas, lo que lleva a demandas computacionales variables. Algunos cifrados están optimizados para aceleración por hardware, aprovechando instrucciones especializadas de la CPU, mientras que otros están diseñados para funcionar eficientemente en software en una gama más amplia de procesadores. La elección del cifrado, por lo tanto, impacta directamente en la utilización de la CPU y las velocidades de transferencia de datos resultantes.

Cifrados SSH modernos clave para el rendimiento

En entornos SSH modernos, dos familias de cifrados de autenticación destacan por su excelente equilibrio entre seguridad y rendimiento: AES-GCM y ChaCha20-Poly1305. Ambos proporcionan cifrado autenticado con datos asociados (AEAD), lo que significa que cifran los datos y proporcionan verificación de integridad en una sola pasada, lo cual es más eficiente y seguro que los enfoques antiguos de cifrar-luego-MAC.

AES-GCM (Estándar de Cifrado Avanzado - Modo Galois/Contador)

AES-GCM es un cifrado por bloques altamente popular y ampliamente adoptado que opera en modo Galois/Contador. Ofrece una seguridad sólida y es particularmente rápido en sistemas con soporte de hardware para AES. La mayoría de las CPUs modernas (Intel, AMD y cada vez más procesadores ARM) incluyen conjuntos de instrucciones dedicados (como AES-NI en arquitecturas x86/x64) que aceleran drásticamente las operaciones AES, haciendo que AES-GCM sea extremadamente eficiente.

Ventajas: Excelente rendimiento en CPUs con aceleración por hardware, seguridad sólida, ampliamente soportado.
Desventajas: Puede ser más lento en implementaciones solo software (por ejemplo, en CPUs antiguas o especializadas sin AES-NI).

ChaCha20-Poly1305

ChaCha20-Poly1305 es un cifrado de flujo desarrollado por Daniel J. Bernstein. Es conocido por su diseño amigable con el software, funcionando muy bien incluso en CPUs sin aceleración criptográfica de hardware específica. Esto lo convierte en una excelente opción para una gama diversa de hardware, incluyendo sistemas embebidos, procesadores antiguos o entornos donde la aceleración por hardware no está disponible de manera consistente u optimizada para otros algoritmos.

Ventajas: Excelente rendimiento en software, seguridad sólida, resistente a ataques de canal lateral por temporización.
Desventajas: Generalmente no es tan rápido como AES-GCM con aceleración por hardware en CPUs modernas de escritorio/servidor.

Factores que afectan el rendimiento del cifrado

El cifrado "más rápido" no es universalmente fijo; depende de varios factores clave:

Arquitectura de la CPU y aceleración por hardware: Este es el factor más significativo. Si tu CPU tiene AES-NI o instrucciones similares, AES-GCM casi con certeza superará a ChaCha20-Poly1305. Sin ello, ChaCha20-Poly1305 podría tomar la delantera.
Implementaciones del cliente y servidor SSH: La eficiencia del software SSH (por ejemplo, OpenSSH) y las bibliotecas criptográficas que utiliza (por ejemplo, OpenSSL) pueden impactar el rendimiento en el mundo real. Las versiones más nuevas a menudo incluyen optimizaciones.
Condiciones de red: Aunque no está directamente relacionado con la velocidad del cifrado, la latencia de red y el ancho de banda disponible pueden enmascarar o amplificar la diferencia percibida en el rendimiento del cifrado. En una red muy lenta, el costo de CPU del cifrado podría ser insignificante en comparación con las limitaciones de la red. En una red muy rápida (por ejemplo, 10 Gbps o más), el cifrado limitado por la CPU puede convertirse en el cuello de botella.
Volumen y tipo de datos: La evaluación comparativa con diferentes tamaños de datos (archivos pequeños vs. archivos grandes) y tipos (compresibles vs. incompresibles) puede revelar diferentes características de rendimiento. Por ejemplo, las transferencias muy pequeñas podrían estar dominadas por la sobrecarga de establecimiento de conexión en lugar de la velocidad del cifrado.

Cómo evaluar el rendimiento del cifrado SSH

La evaluación comparativa implica decirle explícitamente a SSH que use un cifrado específico y luego medir el tiempo necesario para transferir una cantidad conocida de datos. Esto permite una comparación directa.

1. Identificar cifrados soportados

Antes de comenzar, verifica qué cifrados soporta tu cliente SSH:

ssh -Q cipher

Luego usa la salida detallada de SSH para ver qué negocia una conexión real:

ssh -vvv usuario@tu_servidor

Busca líneas similares a debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none. La política del servidor se controla mediante Ciphers en sshd_config, pero el soporte efectivo depende tanto del cliente como del servidor.

2. Especificar cifrados con `ssh -c`

El cliente ssh te permite especificar el cifrado deseado usando la bandera -c. Puedes proporcionar una lista separada por comas, y el cliente intentará usar el primer cifrado soportado de la lista.

Cifrados comunes para probar:

3. Elegir un método de transferencia y fuente de datos

Para una evaluación comparativa consistente, necesitarás una forma de transferir una cantidad conocida de datos.

scp (Copia Segura): Ideal para transferir archivos. Usa un archivo grande y no compresible para asegurar que el cifrado sea el cuello de botella, no la compresión o la E/S de disco.
sftp (Protocolo de Transferencia de Archivos SSH): Similar a scp, útil si prefieres ese protocolo.
dd (Duplicador de Datos): Puede generar un flujo de datos para canalizar a través de SSH, útil para pruebas de rendimiento puro sin sobrecarga del sistema de archivos en el lado del cliente.

Pasos prácticos de evaluación comparativa

Supongamos que deseas evaluar transferencias desde un cliente a un servidor. Necesitarás un archivo de prueba en el cliente (o servidor) que sea lo suficientemente grande (por ejemplo, 1 GB) para permitir una medición significativa, pero no tan grande que las pruebas tomen demasiado tiempo. Una buena manera de crear un archivo de prueba no compresible es usando /dev/urandom. Usa /dev/zero solo cuando la compresión SSH esté deshabilitada, porque los datos de solo ceros son altamente compresibles.

En el cliente (para crear un archivo ficticio de 1 GB):

pwd=$(pwd)
dd if=/dev/urandom of=$pwd/dummy_1GB.bin bs=1M count=1024 iflag=fullblock

Evaluación comparativa con scp:

Probar AES256-GCM:

echo "Probando AES256-GCM..."
time scp -c [email protected] dummy_1GB.bin usuario@tu_servidor:/tmp/test_gcm.bin

Probar ChaCha20-Poly1305:

echo "Probando ChaCha20-Poly1305..."
time scp -c [email protected] dummy_1GB.bin usuario@tu_servidor:/tmp/test_chacha.bin

Probar AES128-GCM (a menudo el más rápido):

echo "Probando AES128-GCM..."
time scp -c [email protected] dummy_1GB.bin usuario@tu_servidor:/tmp/test_aes128_gcm.bin

Evaluación comparativa con dd y pv (para rendimiento en tiempo real):

Este método canaliza datos a través de SSH y puede mostrar velocidades en tiempo real, reduciendo la E/S de disco como cuello de botella. pv (Pipe Viewer) te proporciona información de progreso y rendimiento.

Para instalar pv (si aún no está instalado):

sudo apt-get install pv # Debian/Ubuntu
sudo yum install pv     # RHEL/CentOS
sudo brew install pv    # macOS

Probar AES256-GCM con dd y pv:

echo "Probando AES256-GCM con dd..."
dd if=/dev/zero bs=1M count=1024 | pv | ssh -o Compression=no -c [email protected] usuario@tu_servidor "cat > /dev/null"

Probar ChaCha20-Poly1305 con dd y pv:

echo "Probando ChaCha20-Poly1305 con dd..."
dd if=/dev/zero bs=1M count=1024 | pv | ssh -o Compression=no -c [email protected] usuario@tu_servidor "cat > /dev/null"

Consejo: Ejecuta cada prueba varias veces (por ejemplo, 3-5 veces) y toma el promedio para tener en cuenta las fluctuaciones de red o la carga del sistema.

Interpretación de resultados y recomendaciones

Después de ejecutar tus evaluaciones comparativas, compara el tiempo real de las salidas del comando time o el rendimiento promedio reportado por pv. Probablemente observarás patrones distintos:

CPUs modernas con AES-NI: Casi con certeza encontrarás que [email protected] y [email protected] ofrecen el mayor rendimiento. AES-128 a menudo es marginalmente más rápido que AES-256 debido a menos rondas, pero la diferencia podría ser insignificante en sistemas con aceleración por hardware.
CPUs antiguas, ARM (sin extensiones criptográficas específicas) o Máquinas Virtuales: ChaCha20-Poly1305 puede funcionar de manera comparable o incluso superar a AES-GCM, ya que su diseño optimizado para software brilla en estos escenarios.

Recomendaciones:

Para servidores de alto rendimiento con CPUs modernas Intel/AMD (y AES-NI): Prioriza AES-GCM (especialmente [email protected]). Aprovecha la aceleración por hardware para una velocidad y seguridad superiores.
Para entornos diversos, hardware antiguo, sistemas basados en ARM o situaciones que favorecen el rendimiento del software: ChaCha20-Poly1305 es una excelente opción, proporcionando una seguridad sólida con un rendimiento consistente y alto en diversas arquitecturas sin depender de características específicas del hardware.
Seguridad primero: Siempre elige cifrados que proporcionen cifrado autenticado (AEAD). Tanto AES-GCM como ChaCha20-Poly1305 son cifrados AEAD y se consideran sólidos. Evita cifrados antiguos no AEAD como aes*-cbc si es posible.

Otras consideraciones de rendimiento SSH

Si bien la selección del cifrado es crucial, recuerda que es parte de un panorama de rendimiento más amplio:

Compresión: SSH puede comprimir datos antes del cifrado (-o Compression=yes o Compression yes en ~/.ssh/config). Para datos altamente compresibles en enlaces lentos, esto puede mejorar drásticamente la velocidad percibida, incluso si agrega una ligera sobrecarga de CPU. Para datos ya comprimidos o enlaces muy rápidos, podría reducir el rendimiento.
Multiplexación de conexiones: Funciones como ControlMaster en OpenSSH permiten que múltiples sesiones SSH reutilicen una única conexión TCP subyacente, reduciendo la sobrecarga de negociación para conexiones posteriores.
MTU (Unidad Máxima de Transmisión): Asegúrate de que el MTU de tu red esté optimizado para prevenir la fragmentación, lo que puede degradar el rendimiento.
Versión del cliente/servidor SSH: Mantén actualizado tu software cliente y servidor SSH. Las versiones más nuevas a menudo incluyen mejoras de rendimiento y soporte para cifrados más nuevos y rápidos.

Elige a partir de tus mediciones

Optimizar la selección del cifrado SSH puede mejorar el rendimiento de las transferencias seguras, pero solo cuando el cifrado es el factor limitante. Realiza varias pruebas, mantén la compresión y el tamaño del archivo consistentes, y compara el uso de CPU así como el tiempo de transferencia.

Para muchos servidores modernos, AES-GCM funciona bien debido a la aceleración por hardware. En sistemas antiguos, hardware embebido y algunos entornos virtualizados, ChaCha20-Poly1305 puede ser la mejor opción. Mantén los cifrados CBC antiguos fuera del uso normal a menos que tengas un requisito de compatibilidad que puedas aislar y documentar.