Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2

[Peter Gutmann <[e-mail]>]

Mark D. Baushke <[e-mail]> writes:

>Another possibility would be pre-generate a number of provable primes that
>are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter,
>Qgen_counter, g, Q, P} from the server to the client to prove to the client
>that P and Q are primes and then commence the key exchange.

That would require both a change in the SSH protocol and for everyone to
implement the full FIPS 186 / Shawe-Taylor algorithms, which seems unlikely.
The point of NUMS values is that anyone can verify them, not that everyone
should have to implement the code to verify them.  

You do however need to get one or more people to actually verify them.  Until
I asked about this a few years ago and Henrick Hellström (who probably doesn't
work for the NSA or CIA :-) kindly obliged by running the tests, I don't know
if anyone else had ever independently verified the values in RFC 2409 and 3526
(someone may have, but if they did they didn't publish the fact).

I would go for the most generic form, safe prime, g = 2, and generation from
some NUMS seed in a manner that doesn't require implementing an exotic
algorithm for verification.

(And we can debate whether "2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64
 - 1 + kitchen_sink - pink_flamingo + speed_of_light_in_a_glass_of_milk"
 qualifies as NUMS or not).

>Would a Draft RFC dealing with the creation of such provable primes be
>something that is useful to the Curdle WG?

This came up a while back and but fizzled out based on an inability to agree
on how NUMS the generation method should be.  So I'd say there's interest, but
we'd need to sort out how to do the NUMS in a manner that everyone would find
comfortable.

Also, I'm not sure whether you're proposing publishing a HOWTO or the values
themselves, but what's needed isn't so much a discussion of how to do it, it's
for someone to actually do it in a NUMS manner and publish the results.

>Is it likely that something like this would be adopted by more than just SSH?

Uhh, that's kinda missing the point, you want values that *won't* be adopted
by everything else out there.  Unless you compartmentalised and said "these
values are for SSH, these are for SSL, these are for IKE, these are for
everything else".  I certainly don't want my SSH keyex to become collateral
damage in some government agency that really just set out to break IKE, or
VoIP, or SSL.

Peter.