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

Gregory Maxwell gmaxwell at gmail.com
Mon May 25 16:34:56 EDT 2015


On Fri, May 22, 2015 at 2:55 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> A larger shared prime that is standardized is the safe option of the
> three - it is hard to know if you've got bad entropy, it is also hard
> to know if you've chosen badly.

There is an additional argument I think you may find more persuasive
which I've made about this in the past:

If you use arbitrary groups they must be signaled. This doubles the
required communication. At most this creates a linear cost increase
for the attacker (proportional to the number of users).

Using the same communications resources you can instead double the
size of the static group being used, which is (presumed) to be
exponentially harder for the attacker.

The same argument can even apply to signaling from a fixed set of
static groups, a bit of increased group size is still presumed more
impact on the attacker than having twice the number of groups... and
if we're anywhere near a factor of a few tens of thousands of being
crackable thats a very bad state to be in.

Flexible group selection can, depending on the protocol, mean the
attacker need only successfully attack one--- then just DOS attack
every connection that hasn't picked it. Getting this right in the
protocol design is much harder than picking a somewhat larger secure
group.

> Nevertheless, I've harbored the strong opinion for many months now that OTR should soon move to Curve25519 for key agreement,

The same static group pre-computation arguments apply to using a
static particular curve-- so saying Curve25519 isn't an answer to that
particular class of concern. And-- not that I think group agility is a
virtue-- its much more costly (and risky) to be group agile with EC--
as picking suitable  groups is much harder (and techniques that
cheaply yield groups with known high order are not currently in
fashion) and there are tremendous performance improvements from
specializing the software for a single group.

OTR should be using ECC for bandwidth reasons, considering the narrow
challenges OTR is using, not any other reason.


More information about the OTR-dev mailing list