In OpenSSH they propose ending support for DSA keys

openssh

OpenSSH is a set of applications that allow encrypted communications over a network, using the SSH protocol.

It was recently announced, through the OpenSSH project mailing lists, the proposed a plan to end support for keys based on the DSA algorithm.

It is mentioned that the main reason to stop supporting this algorithm, it is because currently DSA keys do not offer an adequate level of security, given its 160-bit limit for the private key and use of SHA1, which, in terms of security, is roughly equivalent to an 80-bit symmetric key.

DSA stands for Digital Signature Algorithm. It is used for digital signature and verification. It is based on the mathematical concept of modular exponentiation and discrete logarithm. It was developed by the National Institute of Standards and Technology (NIST) in 1991.

It includes four operations:

1. Key Generation

2. Key Distribution

3. Firm

4. Signature Verification

We must remember that in OpenSSH Default use of DSA keys was discontinued in 2015, was kept as an option, since this algorithm was necessary for implementation in the SSHv2 protocol. This need arose because, at the time the SSHv2 protocol was created and approved, all alternative algorithms were subject to patents. However, over time, the situation has changed: RSA-related patents have expired, and algorithms such as ECDSA and EdDSA have been introduced, which significantly surpass DSA in performance and security.

DSA, as specified in the SSHv2 protocol, is inherently weak:
limited to a 160-bit private key and the use of SHA1 digest. Is
The estimated security level is <= 80-bit symmetric equivalent.

OpenSSH has disabled DSA keys by default since 2015, but has retained them as optional support for them. DSA is the only algorithm mandated to be implemented in the SSHv2 RFCs, primarily because alternative algorithms were patent-encumbered when it was designed and specified.

Since then, the world has moved on. RSA is unencumbered and supports
because it is omnipresent. ECDSA offers significant performance and security benefits over modp DSA and EdDSA outperforms the additional performance and security improvements over both again.

After evaluating the current situation, OpenSSH developers have concluded that the costs associated with maintaining the insecure DSA algorithm are no longer justifiable. The removal of DSA is perceived as an encouragement for other SSH implementations and cryptographic libraries to also stop supporting DSA.

In addition to that, the plan for phasing out DSA from the code has already been published of OpenSSH, since initially, as already mentioned at the beginning, support went from default to optional and with the deviation taken the April version of OpenSSH plans to retain the DSA compilation, but will offer the ability to disable DSA during the compilation.

Subsequently, for the June release, DSA will be disabled by default during build, and will be removed from the codebase in early 2025.

Doesn't this make OpenSSH incompatible with RFC4253?

Pretty much no more than we have been since 2015, when we stopped offering DSA support by default.

* Why make this change now? Why not before/after?

We believe that enough time has passed since DSA was disabled by default, which has likely led to abstinence from use of the algorithm by the overwhelming majority of users. It is also likely that we will soon begin to explore a post-quantum signature algorithm and become aware of the overall size and complexity of the key/signature code.

Lastly, it is mentioned that for those users who still need DSA support on the client side, will have the option to use alternative builds of older versions of OpenSSH, such as the Debian-supplied package "openssh-client-ssh1". This package, based on OpenSSH 7.5, is designed to connect to SSH servers using the SSHv1 protocol, which was discontinued in OpenSSH 7.6 six years ago.

finally if you are interested in knowing more about it, So consult the details in the siguiente link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.