Hey everyone,
so, over the past several years, it looks like everyone has proverbially screwed the pooch with regard to plain old DSA key sizes larger than 1024 bits.
OpenSSH is now going so far as to have dropped ssh-dss in its default configuration, which is reasonable, given that this algorithm is now only useful for 1024-bit DSA.
Everyone is migrating now to ECDSA over NIST curves or Ed25559, which is all nice and well - these appear to be strong algorithms, according to information available at this time.
Still, I think it's a pity for larger DSA keys to never have had a chance; but more than sentimentalism, I think we're losing out on heterogeneity and backup options in case something, anything, turns out to be wrong in Elliptic Curve territory.
Now, if we want to agree on some way to implement large DSA keys, the "ssh-dss" algorithm name is tainted for use with larger key sizes, because there are implementations out there that implement them in incompatible ways:
- There were older versions of OpenSSL and OpenSSH that implemented 2048-bit modulus, but kept 160-bit subgroup. This did not effectively increase the security of the scheme, compared to 1024-bit modulus.
- Our (Bitvise) implementation predates FIPS 186-3 by a year. It supports a larger modulus, and appropriately larger subgroups, BUT continues to use SHA-1 as the hash function. After FIPS 186-3, other implementations of larger DSA keys, such as Windows CNG, support the larger DSA keys in conjunction with SHA-2.
- A majority of other "ssh-dss" implementations support only 1024-bit key sizes, and can't verify signatures with larger DSA keys under that scheme.
Larger DSA keys need a new scheme name for compatibility reasons.
I therefore suggest a new SSH key algorithm, dsa-sha2-256, which cherry-picks from FIPS 186-3 the following two options:
L = 2048, N = 256
L = 3072, N = 256
In other words:
- modulus size is either 2048 or 3072
- subgroup size is 256 bits
- hash function is SHA2-256
I choose the name "dsa-sha2-256", rather than a suffixed name ("...@bitvise.com") for the following reasons:
- Suffixed names are overly long and clumsy. If I were to choose a suffixed name instead, I would go with just "...@bv".
- Suffixed names complicate standardization. If a suffixed algorithm is commonly implemented, there's pressure to have a version with a non-suffixed name, and now we have multiple names for the same thing.
- I don't see many ways for "dsa-sha2-256" to be implemented incorrectly or incompatibly by a reasonable implementor. There's really only one DSA, the one specified in FIPS 186. This has four variants. The suffix -sha2-256 explicitly specifies which hash function to use, and strongly suggests use of the 256-bit subgroup sizes.
Unless someone has a strong and reasonable objection, I intend to implement this for Bitvise SSH Client and Server 7.xx as described above.
Comments welcome.