Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

[Stephen Farrell <stephen.farrell%cs.tcd.ie@localhost>]

If proceeding with this, it'd be good to pass it by the
CFRG [1] list for comment.

For example, in discussion of signature schemes based on
new curves, CFRG recently preferred deterministic signatures,
I'm not sure whether this proposal is the same i that respect
or not.

Cheers,
S.

[1] https://irtf.org/cfrg

On 27/10/15 22:50, denis bider wrote:
> 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.
> 
>