En OpenSSH proponen poner dar fin al soporte de claves DSA

Hace poco se dio a conocer, mediante las listas de correo del proyecto OpenSSH, la propuesta de un plan para finalizar el soporte de claves basadas en el algoritmo DSA.

Se menciona que el principal motivo de dejar de soportar este algoritmo, es debido a que en la actualidad las claves DSA no ofrecen un nivel adecuado de seguridad, dado que su límite de 160 bits para la clave privada y el uso de SHA1, que, en términos de seguridad, equivale aproximadamente a una clave simétrica de 80 bits.

Hay que recordar que en OpenSSH el uso predeterminado de claves DSA fue suspendido en 2015, se mantuvo como opción, ya que este algoritmo era necesario para la implementación en el protocolo SSHv2. Esta necesidad surgía porque, en el momento en que se creó y aprobó el protocolo SSHv2, todos los algoritmos alternativos estaban sujetos a patentes. Sin embargo, con el tiempo, la situación ha cambiado: las patentes relacionadas con RSA han expirado, y se han introducido algoritmos como ECDSA y EdDSA, que superan significativamente a DSA en rendimiento y seguridad.

DSA, como se especifica en el protocolo SSHv2, es inherentemente débil:
limitado a una clave privada de 160 bits y al uso del resumen SHA1. Es
El nivel de seguridad estimado es <= equivalente simétrico de 80 bits.

OpenSSH ha desactivado las claves DSA de forma predeterminada desde 2015, pero las ha conservado como soporte opcional para ellos. DSA es el único algoritmo de implementación obligatoria en los RFC SSHv2, principalmente porque los algoritmos alternativos estaban gravados por patentes cuando se diseñó y se especifico.

Desde entonces, el mundo ha seguido adelante. RSA no tiene cargas y admite
porque es omnipresente. ECDSA ofrece un rendimiento significativo y beneficios de seguridad sobre modp DSA y EdDSA supera el rendimiento adicional y mejoras de seguridad sobre ambos nuevamente.

Después de evaluar la situación actual, los desarrolladores de OpenSSH han concluido que los costos asociados con el mantenimiento del algoritmo inseguro DSA ya no son justificables. La eliminación de DSA se percibe como un estímulo para que otras implementaciones SSH y bibliotecas criptográficas también dejen de respaldar DSA.

Además de ello, ya se ha publicado el plan para la eliminación gradual de DSA del código de OpenSSH, pues de manera inicial, como ya se mencionó al inicio, el soporte paso de pretederminado a opcional y con la desviación tomada la versión de abril de OpenSSH planea conservar la compilación DSA, pero ofrecerá la capacidad de desactivar DSA durante la compilación.

Posteriormente, para la versión de junio, DSA se desactivará de forma predeterminada durante la compilación, y se eliminará del código base a principios de 2025.

¿Esto no hace que OpenSSH no sea compatible con RFC4253?

Prácticamente no más de lo que hemos estado desde 2015, cuando dejamos de ofrecer el soporte de DSA de forma predeterminada.

* ¿Por qué hacer este cambio ahora? ¿Por qué no antes/después?

Creemos que ha pasado suficiente tiempo desde que DSA se desactivó de forma predeterminada, lo que probablemente haya llevado a la abstinencia del uso del algoritmo por parte de la abrumadora mayoría de los usuarios. También es probable que pronto comencemos a explorar un algoritmo de firma post-cuántico y seamos conscientes del tamaño y la complejidad general del código de clave/firma.

Por último, se menciona que para aquellos usuarios que aún necesiten soporte DSA del lado del cliente, tendrán la opción de utilizar compilaciones alternativas de versiones anteriores de OpenSSH, como el paquete suministrado por Debian «openssh-client-ssh1».Este paquete, basado en OpenSSH 7.5, está diseñado para conectarse a servidores SSH utilizando el protocolo SSHv1, que fue descontinuado en OpenSSH 7.6 hace seis años.

Finalmente si estás interesado en poder conocer más al respecto, pues consultar los detalles en el siguiente enlace.