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

Hi denis,

denis bider <[email protected]> writes:

> 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.

If you are going to go there, you will want to write another RFC and
probably use FIPS 186-4 Section 4 "The Digital Signature Algorithm
(DSA)" as the normative reference.

> - 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
> ("[email protected]") 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.

You have already been through co-authoring RFC 6668, so writing another
RFC for dsa-sha2-256 should not be that hard of a thing for you to do.

Information on test vectors for DSA may be found here:

  http://csrc.nist.gov/groups/STM/cavp/documents/dss2/dsa2vs.pdf

The test vectors for DSA2 are here

  http://csrc.nist.gov/groups/STM/cavp/documents/dss/186-3dsatestvectors.zip

(Yes, they are still the same as FIPS 186-3.)

	-- Mark