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

From: denis bider <[email-masked]>
Date: Sat, 7 Nov 2015 05:03:30 +0000

Half the time - or even more often - the parameters sent by the server fail a pairwise consistency test that Crypto++ performs in FIPS mode.

I believe these tests are required by FIPS to use the crypto parameters.

I believe this has been recognized as a shortcoming of these dynamically generated groups, and has been deemed an acceptable level of risk because they are short-lived.

The issue is that FIPS (probably correctly, given its intent to prevent suspicious-looking crypto use) does not make this accommodation.

----- Original Message -----
From: Jeffrey Hutzelman 
Sent: Friday, November 6, 2015 21:50
To: denis bider 
Cc: [email-masked] ; NielsMöller ; Mark D. Baushke ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: DH group exchange (Re: SSH key algorithm updates)

On Sat, 2015-11-07 at 03:33 +0000, denis bider wrote:

> It is a fairly substantial problem that most dynamically generated
> groups aren't usable with our FIPS module.

What's broken about the groups that don't work?

---

From: denis bider <[email-masked]>
Date: Sun, 8 Nov 2015 10:29:57 +0000

> 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 ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: RE: DH group exchange (Re: SSH key algorithm updates)

denis bider <[email-masked]> 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.