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

[Gregory Maxwell]

On Mon, Jun 1, 2015 at 11:13 PM, Taylor R Campbell
<campbell+otr at mumble.net> wrote:
> [3] SafeCurves addresses this in <http://safecurves.cr.yp.to/twist.html>:
>
>   `A curve designer can protect against [small-subgroup attacks] by
>    choosing curves with [cofactor 1].  A protocol designer can protect
>    against [small-subgroup attacks] for any curve by [multiplying
>    secrets by the cofactor].  Even without any defences, the impact is
>    limited to sqrt(cofactor).'
>
> SafeCurves doesn't fail to constrain the curve cofactor.  It doesn't
> directly constrain the cofactor to be 1: instead it constrains the
> practical security consequences of cofactor and twist cofactor against
> known small-subgroup and invalid-curve attacks.

Indeed it does; but it states several requirements just on the basis
of "these result in less implementation hazard", where I am not aware
of any implementations that get those aspect wrong (and where it
offers no real-world examples); and yet I am aware of cases where
consideration of the cofactor c as you describe was left out; which
(at least) resulted in a certificational weakness (e.g. loss of
information theoretic security). I agree that the cofactor is easy to
address and small co-factor typically has adequate security, but from
a "safe implementations are simple" perspective a cofactor of 1 is
somewhat superior for some applications.  OTR wouldn't be one of them.

Again, I think the family of curves like 25519 are reasonable and well
justified but safecurves criteria appear, to me, to be clearly
tailored to meet those curves-- offering with seeming equal importance
to critical criteria like rho security some rather fringe arguments
that favor a particular family while leaving out other fringe
arguments which would favor other choices.  (some of the criteria are
also partially overlapping, for example the argument for supporting
single coordinate ladders as a mitigation against glitch attacks is
mooted by the separate requirement for twist security).

If one understands safecurves to primarily be a throughout promotional
platform for a particular set of high quality curves-- which names and
explains a number of useful qualities to evaluate curves against--
this is all fine, but I think to understand it as a neutral set of
criteria for all curves then I think it falls a bit short.

(In particular, I've personally been frustrated by laypeople arguing
some other curves were "not safe" because of application inapplicable
fringe criteria named there, while at the same time the curves in
question had greater rho security than the curves named on the page)

Though if we are nitpicking curve choices for OTR; As far as OTR goes,
I am not sure why instead the recently multiply-invented 2^521-1 field
curve wouldn't be used as we know from the use of 1500bit DH there is
adequate channel capacity is available; and OTR does not involve
handling hundreds of messages per second, but it may protect secrets
which need to stay private for decades.