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

Peter Gutmann <[email protected]> writes:

> denis bider <[email protected]> writes:

> I don't know if you need to specify the exact generation method, only
> the verification checks to perform, which are given in FIPS 186. 

Actually, it depends on the evaluation lab somewhat, but they typically
want evaluations to use generation and verification based on FIPS 186-4
appendix A.1 and show the code that is doing the generation if it is
inside of the crypto module.

Validation of existing DH FCC domain parameters is expected to use the
methods in section A.1.

Section A.1.1.2 outlines the method of generation of probable primes.
However, it limits the values of the number of bits of p and q based on
L and N values taken from section 4.2. Where the max is L=3072 and N=256
apparnetly resuing the same table as for DSA parameters.

I would hope generating a lot of 2048-bit and 3072-bit DH primes would
be sufficient for now.

A possible method to generate larger DH parameters is to generate primes
in any way you can and then validate them using one of the primality
proving algorithms in http://cr.yp.to/primetests.html ... of course as
it is not FIPS-approved, that would need to be done outside of the
crypto boundary. :-(

There seems to be little use of DH primes being much bigger than 4096
bits right now in any case. It becomes easier to move to ECDH for
performance.

> The intent is to create verifiable DH parameters, so the important
> thing is the verification mechanism, not the generation one (both safe
> primes and Lim-Lee primes, for example, will produce verifiable
> values). It would certainly make sense, if you're using { p, q, g }
> primes, to require that they be verified as per the FIPS 186 checks,
> since that's the point to using them.

Yes. That said, I do not find any FIPS or NIST documents talking about
Lim-Lee primes for use in FIPS certified systems.

> The annoying thing about this change is that it's going to take me
> about 20x as long to do the spec describing it as it will to make the
> code changes, sigh.

That always seems to be the way of things.

> One other thing that'd be good to have, based on the Logjam paper, is
> to specify some means of distinguishing g from q, since Logjam
> mentions that there are implementations that confuse the two. Does
> anyone have problems with requiring that g = <small integer>? This
> both makes the DH op much more efficient, and makes it easy to quickly
> distinguish g from q without requiring complex bignum ops.

Well, if you look at group25, you see that g is larger than q.

I know that at one time, a few of our govenmental customers were
twisting arms over implemnting group25 everywhere and were not happy
that it was not possible for SSH at that time.

I would therefore really like to see it possible to express all of the
MODP groups via this new extension if possible.

	Just my $0.02,
	-- Mark