[OTR-dev] Fwd: Some DH groups found weak; is OTR vulnerable?

[Paul Wouters]

On Fri, 22 May 2015, Jurre van Bergen wrote:

>>> On Freitag, 22. Mai 2015, Ian Goldberg wrote:
>>>> No, there is no reason to believe that the 1536-bit DH group used by OTR
>>>> is vulnerable.

And people should remember 1536 is not 1.5 times 1024 :P

>> Yes, I believe that is correct - we're all using the same DH group as
>> defined in dh.c:
>>
>> static const char* DH1536_MODULUS_S = "0x"
>>     "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD1"
>>     "29024E088A67CC74020BBEA63B139B22514A08798E3404DD"
>>     "EF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245"
>>     "E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7ED"
>>     "EE386BFB5A899FA5AE9F24117C4B1FE649286651ECE45B3D"
>>     "C2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F"
>>     "83655D23DCA3AD961C62F356208552BB9ED529077096966D"
>>     "670C354E4ABC9804F1746C08CA237327FFFFFFFFFFFFFFFF";

Which has seen quite some research, which is both good and bad.

>>> how about (optionally) creating a new, client specific one, on installation? and how about using eg. 4096 bits?

Wouldn't you need to transmit that value to the other party then? And
when you receive one, how do _you_ know the other party didn't send
a non-safe prime without doing all kinds of expensive tests? How do
you deal with rejecting the DH value? In IKE you use one DH value but
in the initial packet there is also a list of other DH values you
accept. So if both parties agree on the first used DH, there is no
extra round trip. The other can send a rejection of the DH value,
and include one of the DH numbers from the initially included set in
that first packet. And the initiator then starts from scratch with this
new DH value (provided it agrees to it)

>> Using a larger DH group is totally reasonable - namely a 2048bit group
>> or a larger one.

Is it? Compared to the AES key size we use? Which I think is still 128bit?

>> it is that whenever this topic comes up for discussion it ends with
>> "lets just switch to ECC and do away with this problem entirely."

Don't we have to pick points on a curve, and than we run into a similar
problem of which points are unsafe and how to do know? Isn't that why
the NIST (or brainpool or djb) curves tell us which points to use? I'm
also always quite amused how people jump to curve25519. While people ask
how NIST got their numbers, they just take djb's word on it for his
choice of numbers ("I won't talk about speed but they are the fastest").
For all we know he is getting a bag of money or a girlfriend to promote
these numbers by the NSA. Much cheaper. Just like I'm much more bribable
or blackmailable for libreswan that Cisco is if you want to pervert an
IPsec stack.....

>>> if I understand correctly, in a few years 1536 bits might not give
>>> sufficient protection anymore, if attacked liked this, and if there is a a full take of
>>> the otr communication then the "forward secrecy" is gone :/

That is not expected to happen "in a few years" though.

>> There is no doubt in my mind that the group chosen by OTR is indeed a
>> target as we've seen ample evidence of them being thwarted by OTR
>> (FISA intercepts, etc).

Are they thwarted? Or is that what they want us to believe? They do have
a rather big enigma problem :P Additionally, saying they cannot break us
gets them more money, so another incentive to lie.

>> The logjam attack explains *how* the NSA is likely decrypting SSH,
>> IPSec and SSL/TLS traffic at scale. And if they weren't doing it
>> before - they're certainly going to implement it now!

Of course they were already doing this, and something better. The point
of the opensource and open research commutiy is to make decisions based
on public research - we don't need a Crypto Babe :P

> The short term being, bump the keysize, I'd like to see 2048bit DH or
> higher being implemented. How the group is chosen I leave to the actual
> cryptographers, I bet Nadia has a well informed opinion about this.

I don't mind 2048 or 1536 (or 8192) as chatting isn't very latency
sensitive as say starting up a VPN. So I'm happy to defer to Ian.

For libreswan, in IKEv1 we allow 1024 and 1536 because we cannot get rid
of it due to the old cisco install base. In IKEv2 we allow 1536, mostly
to facilitate IKEv1 -> IKEv2 migration. For either, we allow modp2048 per
default and we support up to modp8192 and the RFC5114 alternative MODP
primes, but these are not part of the default proposal. (and because the
origin and reason of the RFC5114 primes comes down to "no one but BBN
wanted it, but no one objected", these will never be added to the default
propsal list).

> The long term is, investigate whether we should move to ECC when it

I haven't drunk the ECC coolaid yet....

>> My open question is: why do we trust any of the Oakley groups at all?

Because these are peer reviewed by an international community and are
the best we have?

>> Do we really trust NIST?

These MODP's do not come from NIST.

> Do we really trust FIPS?

You should trust that anything deprecated in FIPS should not be used.
You cannot trust them for things that were never allowed (eg twofish,
serpent) and you should only take what they do allow as a hint that it
might be good enough for now.

>> If they were
>> underhanded - would we even understand how they might be maliciously
>> chosen?

Picking different values would give you the exact same problem, so
switching doesn't solve it, apart from maybe wasting a few thousand
core years at the NSA, of which they have plenty more.

>> How far down the rabbit hole do we want to go here? Do we want to pick
>> a totally unique set of groups for DH, where we trust that say, Ian,
>> won't choose badly? Should we just pick one new group? Or should we
>> standardize OTR Groups - generate ~10000 groups and then randomly pick
>> one of the set?

Would that even increase the NSA workload by a factor 10k? Maybe it
would take more storage, but either way I don't think you're buying
anything more by picking a bunch of 2048 ones over one 8192 one.

Paul