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

[Peter Gutmann <[e-mail]>]

Tero Kivinen <[e-mail]> writes:

>I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I 
>generated the RFC3526. I do not know if anybody else has verified the 
>RFC3526 primes.

Wow.  So the 2409 values took five years to be independently verified and
nineteen years before this became known, the 3526 values took twelve years
to be independently verified.  If we do publish new groups, we need to 
address this problem with some urgency.  I'm not saying I don't trust you :-)
but the point of publishing the details is to gain confidence in everything
being correct once multiple people have verified things.

In terms of what to publish, I don't know if there's much need to publish a 
HOWTO for generic DLP parameter generation since presumably every 
implementation already has code to do DH/DSA/whatever generation.  
Where something is needed is situations where widely-shared parameters need 
to be generated, and there all you'd need to do is document how it's done 
and publish the parameters, preferably as a C-style byte array or something.  
Few if any of the parameter-set documents acknowledge that implementers just 
want something they can incorporate into their code with minimal effort.  
Give them a cut&paste code block that takes under five minutes to integrate 
into existing code and it's far more likely to see quick uptake.

And while I'm at it, include a hash of the parameters as a byte string so
you can check that you've got an exact copy of the data.

(The above culled from off-list discussions, in case someone's wondering if
they've seen it before :-)

>Actually breaking SSH is much more useful than breaking IKE or TLS. The 
>first time the adminstrator types sudo and his root password inside his 
>ssh connection, the stored SSH stream comes very valuable for the 
>attacker... 

Only if they want to compromise someone's Linux box or something.  If you
target IKE you get to vaccuum up a ton of VPN traffic, and with SSL you
get not only all web browsing but a ton of other stuff that uses it as the
universal secure transport mechanism for network traffic.  For example if
you're targetting VoIP then you'd want it for the tiny fraction of SIP
that isn't just sent in the clear.  It'd also give you ToR traffic, and 
endless other material.  The pretty clear lesson here is, don't use the same 
DH parameters as SSL/TLS.

So in terms of target groups if I was a government-level attacker, I'd go
for SSL, then IKE, and then I'd think about what to do next, given that it
could take years to break each parameter set.

Peter.