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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Fri, 2015-10-30 at 03:03 +0000, denis bider wrote:
> Hey Jeffrey,
> 
> thank you for your comments. :-)
> 
> I have updated the draft based on this feedback. Same URL - new version:
> 
> http://www.denisbider.com/draft-dsa-sha2-256.txt

Those updates all look good.

> > If you don't include it, then either implementors will
> > support it anyway, or users will be confused when their
> > keys don't work.
> 
> I've done some testing, and found that Windows CNG cannot import an
> L=2048, N=224 private key generated with Crypto++.
> 
> In the interest of interoperability, I think it's better to prohibit
> this option. I have added language to this effect.

> > I assume that with N=224, you'd want to actually use SHA-224.
> 
> It may be interesting to note that Windows built-in crypto - a major,
> FIPS-certified platform - does not support SHA-224 at all. With DSA, or
> standalone.

> > For that matter, what about _larger_ key sizes?
> > What's to say that NIST won't publish FIPS-186-5
> > with an (L=4096, N=512) option.  
> 
> Allowing for such keys to be used with the same algorithm name would
> break interoperability with applications unaware of such a new
> standard.

I don't understand.  The issue with ssh-dss was that we _didn't_ allow
for larger key sizes.  Well, that and the fact that we specified SHA1,
which doesn't provide sufficient security to keep up with larger key
sizes(*).

So why would it be bad to support larger key sizes with an existing hash
that is already big enough?


(*) In fact, now that I think about it, we probably should have defined
an rsa-sha256 public key algorithm.