Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh #40337

FiloSottile opened this issue Jul 21, 2020 · 10 comments

crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh #40337

FiloSottile opened this issue Jul 21, 2020 · 10 comments


Copy link

@FiloSottile FiloSottile commented Jul 21, 2020

DSA is an obsolete, fragile, insecure, and mostly unused signature scheme. I'm proposing that we deprecate (but not remove) the crypto/dsa package, recommending a modern alternative such as crypto/ed25519, and drop support for DSA keys in the crypto/x509 and packages.

The problem with DSA

First, DSA suffers of what we now know is a design mistake: it requires each key to bring along its own parameters, instead of setting globally accepted ones. Parameters are slow to generate, large to encode, and most importantly very hard to validate. This caused a remote DoS in Go 1.13 (CVE-2019-17596, #34960) exploitable through both TLS and SSH.

Second, DSA was initially standardized with a max key size of 1024 bits, which is now universally acknowledged as insecure against real-world attackers. While larger key sizes were standardized years later, by then it made no sense to use DSA in new systems anymore, so the systems that kept using DSA did it for backwards compatibility and didn't adopt larger keys. It's also been almost 20 years.

I wrote more about this in a newsletter issue.

DSA and X.509

The Mozilla Root Store policy rejects DSA keys in X.509 certificates, so they are completely absent from the WebPKI, which is what crypto/x509 targets. Anecdotally, they are also not in use in any private PKI I am aware of. (This is obviously a hard assertion to substantiate.)

crypto/x509 is exposed to the world for most Go applications through crypto/tls, and supporting DSA is a liability in terms of attack surface, as proved by CVE-2019-17596.

Also note that crypto/tls doesn't itself support DSA certificates, so they already can't be used as website certificates, only as intermediate or root CAs.


OpenSSH's ssh-keygen only ever supported insecure 1024-bit keys. 94% of the DSA keys on GitHub are 1024-bit. The package only supports 1024-bit keys. DSA as used in SSH is insecure.

There is reason to think removing DSA support will actually help compatibility, by preferring other key types and avoiding connection failures for key sizes other than 1024-bit (#23751). OpenSSH 7.0 disabled DSA support in 2015. Dropping DSA support will also help align the host keys observed by x/crypto/ssh with the ones in an OpenSSH known_hosts file.

Edited to add: NIST is deprecating DSA

DSA is specified in FIPS 186 by NIST. The draft of the next version of the specification, FIPS 186-5, removes all text about DSA except for a paragraph stating that DSA may only be used to verify existing legacy signatures. We risk being behind the FIPS standards!


Copy link

@alex alex commented Jul 22, 2020

👋 from a fellow cryptography library maintainer who'd like to kill DSA.

Big ❤️ for go killing this! One less bad crypto system for users to accidentally use!

One idea which may or may not be of interest to you, is to deprecate key generation and signing on a different timeline than signature verification. This potentially allows supporting backwards compatibility use cases without making the situation any worse.

Copy link

@reaperhulk reaperhulk commented Jul 22, 2020

As another cryptographic library maintainer, I agree that deprecation is a good path. There exist a small set of people sshing with 512-bit DSA keys to managed switches, but there are various reasonable ways for those users to solve their problems without having modern cryptography libraries carry the maintenance burden and security risk.

@rsc rsc added this to Incoming in Proposals Jul 28, 2020
@rsc rsc moved this from Incoming to Active in Proposals Jul 28, 2020
Copy link

@rsc rsc commented Jul 29, 2020

Adding to minutes for first time this week, but seems like a likely accept next week.

Copy link

@rsc rsc commented Aug 5, 2020

The reactions above and discussion are clear.
This seems like a likely accept.

Copy link

@rsc rsc commented Aug 12, 2020

No change in consensus, so accepted.

@rsc rsc moved this from Likely Accept to Accepted in Proposals Aug 12, 2020
@rsc rsc modified the milestones: Proposal, Backlog Aug 14, 2020
@rsc rsc changed the title proposal: crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh Aug 14, 2020
Copy link

@gopherbot gopherbot commented Sep 28, 2020

Change mentions this issue: crypto/dsa,crypto/x509: deprecate DSA and remove crypto/x509 support

gopherbot pushed a commit that referenced this issue Oct 2, 2020
Updates #40337

Change-Id: I5c1218df3ae7e13144a1d9f7d4a4b456e4475c0a
Trust: Filippo Valsorda <>
Trust: Roland Shoemaker <>
Reviewed-by: Roland Shoemaker <>
Reviewed-by: Katie Hockman <>
Copy link
Member Author

@FiloSottile FiloSottile commented Oct 5, 2020

The crypto/dsa and crypto/x509 parts are landed, only x/crypto/ssh left.

@FiloSottile FiloSottile self-assigned this Oct 5, 2020
@FiloSottile FiloSottile added the NeedsFix label Oct 5, 2020
@FiloSottile FiloSottile modified the milestones: Backlog, Unreleased Oct 5, 2020
Copy link

@gopherbot gopherbot commented Dec 2, 2020

Change mentions this issue: ssh: remove DSA support

Copy link

@jech jech commented Dec 13, 2020

Is it possible to disable DSA in 1.15.5, so we can check in advance if anything breaks?

Copy link
Member Author

@FiloSottile FiloSottile commented Dec 13, 2020

@jech there is no way other than checking the public key type of all X.509 certificates in verified chains you are using (as the only behavioral change is in crypto/x509). As with most changes, the way to check for breakage would be to run the Go 1.16 beta or release candidate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants