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

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

> 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's the thing with writing every spec. :)

I find, though, that the extra effort in writing a spec contributes in important ways to thinking of and addressing corner cases, which an intuitive implementation process might otherwise gloss over. It's 80% more work for what seems like 20% more correctness, but those 20% more correctness tend to make or break the thing, in many cases.

If we had infinite time, we should be writing all the specs.

It might even save us time in the long run... :)


----- Original Message -----
From: Peter Gutmann 
Sent: Sunday, November 8, 2015 03:42
To: denis bider ; Mark D. Baushke 
Cc: Jeffrey Hutzelman ; Niels Möller ; ietf-ssh%NetBSD.org@localhost ; stephen.farrell%cs.tcd.ie@localhost ; jon%siliconcircus.com@localhost 
Subject: RE: DH group exchange (Re: SSH key algorithm updates)

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

>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 don't know if you need to specify the exact generation method, only the
verification checks to perform, which are given in FIPS 186.  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.

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.

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.

Peter.