Weak DH primes and openssh

[Daniel Kahn Gillmor]

On Thu 2015-05-28 10:54:21 -0400, Hubert Kario wrote:
> that being said, how using NUMS seeds to generate safe prime would hurt?

I don't see how it would hurt, but i'm just pointing out that i don't
think it provides any additional defense against small subgroup attacks
once you've settled on requiring safe primes.

Of course, if you use some sort of NUMS process then you have to verify
that the NUMS process was followed as well, which adds an additional
chunk of work for anyone who is trying to do corroboration.

> also, doesn't that require us to provide primality certificates for q rather 
> than p?

Yes, if we expect to use safe primes, i think we need primality proofs
for both p and q.  For the new TLS FFDHE groups, i've posted those here:

  https://dkg.fifthhorseman.net/ffdhe-primality-proofs/

(i'm not recommending using the same groups for TLS and SSH, fwiw.
splitting the potential attack surface by application type seems like a
good thing; it adds no additional fingerprinting/metadata, because the
protocols themselves are already fingerprintable)

I guess i'd summarize the situation as:

 * NUMS requires extra work for both people who choose the moduli, and
   for corroborators (moduli.c's gen_candidates starts from BN_rand on
   line 328, so we're not even claiming to use NUMS in the current
   method)

 * primality proofs require a significant amount of extra work for
   people who choose the moduli, and some extra work for corroborators
   (verification at least)

 * even basic random M-R checks (which wouldn't defend against an
   attacker who knows how to generate strong pseudoprimes) require work
   from corroborators

 * we haven't had much public corroboration of the moduli shipped by
   default in the past (or if we have, i've missed it)

 * it's not fair to Darren and Damien that they should be single points
   of failure here.

Any thoughts on things that we might be able to improve?

    --dkg