12

The gist of openssh deprecates dss-keys appears to be:

"In light of recently discovered vulnerabilities openssh deprecates DSA keys."

Does this mean I should generally consider DSA keys deprecated? The "upsteam announcement" linked to gives little more information, and I can't seem to find anything else about "recently discovered vulnerabilities".

10

OpenSSH's decision appears to be motivated by some sort of confusion that originates from their own code base; see this answer for an analysis.

In SSH, DSA keys are deprecated because the people who get to decide what is supported and what is not (the OpenSSH developers) said so.

On a more general basis, there is no newly discovered vulnerability on DSA. There are issues related to key sizes, which were known and keep being known; basically, a DSA Key in a 1024-bit modulus is not substantially stronger than a RSA key with a 1024-bit modulus, so if the latter is to be avoided, so is the former. The current versions of the DSA standard allows the modulus to have size 1024, 2048 or 3072 bits. If you use DSA then you will want to make the modulus size 2048 bits (or 3072 bits if you want to spend more CPU). See this site for lots of data on estimating strength based on key length.

However, one may note that there is little reason to prefer DSA over its elliptic-curve version ECDSA: ECDSA public keys are shorter (this saves on network bandwidth) and the ECDSA version is less computationally intensive (this saves on CPU). While this does not mean that "DSA is deprecated", this still implies that ECDSA is preferable, unless it cannot be used due to interoperability issues with legacy systems. Note that the same kind of interoperability issues may prevent you from using a 2048-bit DSA modulus.

| improve this answer | |
3

It is a matter of implementation of DSA as Thomas Pornin stated 2 years ago in Disabling authentication via DSA keys in OpenSSH?:

There has been badly made implementations of DSA or ECDSA; however, there has also been badly made implementations of RSA, and in some case it resulted in RSA key leakage (e.g. Bleichenbacher's attack).

It is a matter of implementation in Debian's openssl package that indirectly affects OpenSSH.

From CVE-2008-0166:

OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys.

Further reading:

DSA-1571-1 openssl -- predictable random number generator

| improve this answer | |
  • Minor correction to Thomas: Bleichenbacher's attack doesn't actually leak keys. It does allow attackers to recover plaintexts, which is why we want keys in the first place, but it doesn't actually leak the key values. – poncho Jun 28 '18 at 13:28
  • Hi @poncho I am a bit rusty in the PKCS domain, but I believe Bleichenbacher mentions in the paper (link.springer.com/content/pdf/10.1007%2FBFb0055716.pdf) that keys may be leaked if "the attack is performed in a client-server environment, where both parties use the message ... to generate session keys, we might be able to find this message by exhaustive search" – qneill Jun 14 '19 at 21:55
  • 1
    @qneill: I have no idea what I was thinking when I made the comment; Bleichenbacher has two well-known attacks with his name on it; obviously, the context was his attack on DSA (with biased random number generation) - for some reason, I had thought of his attack on RSA with PKCS #1 encryption padding... – poncho Jun 14 '19 at 23:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.