Re: DH group exchange (Re: SSH key algorithm updates)

[denis bider <ietf-ssh3%denisbider.com@localhost>]

If this new draft could specify group generation such that:

- Windows built-in crypto (CNG) running under FIPS mode

- and possibly, but not as critically, the Crypto++ 5.3.0 FIPS-certified module

could reliably use parameters sent by servers that implement the new spec - that would be quite awesome.

I have not yet implemented DH using Windows CNG, so I can't verify if it has the same issues as Crypto++ has. However, I should get there in the next few weeks.

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> , 11/8/2015 8:16 AM:

mdb%juniper.net@localhost <mdb%juniper.net@localhost> writes:

>To me, the term '(p-1)/2' implies that we are calculating a value for 'q' ...
>in other words, I thought that q was a Sophie Germain prime and an p was the
>safe prime.

Ah, yeah, it works if you're using safe primes and can assume that form.  I
use Lim-Lee primes (p = 2q * ( prime[1] * ... prime[n] ) + 1 rather than p =
2q + 1), for which an attempt to back-derive q from p will lead to funny
results.

>If you want to allow for things like group25 (RFC 5114), then having all of
>the group parameters g,p,q would make it possible. I would have no problems
>with that addition.

That would be a considerable help, particularly given the recent attacks on
PKCS #3 DH values in TLS (SSH uses the same form, but so far hasn't been found
vulnerable).

If no-one else has any objections, I'll work on a quick draft, all it'll do is
update '4419 to define a SSH_MSG_KEX_DH_GEX2_GROUP and a new identifier,
"diffie-hellman-group-exchange2-sha256" (I assume there's no demand for a
sha-1 version any more...).  The impact on an implemention should be no more
than a few lines of code changed, a new entry in an algorithm table for the ID
string and a call to read the extra q value.

Peter.