On Tue, Oct 8, 2013 at 4:49 PM, Mike Perry <mikeperry@torproject.org> wrote:
Jurre van Bergen:
>
> *OTR*
> OTR support comes from the Go crypto package:
> https://code.google.com/p/go.crypto/
> This library only has support for OTRv2 and not the latest OTRv3
> specification. If we want to be resistant to several attacks[1]  on the
> OTR protocol, we need to reimplement the OTR protocol and update it to
> the latest version or, we use Cgo, which binds into libotr. (Open
> questions: OTR by default?, )
>
> [1]
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.165.7945&rep=rep1&type=pdf

According to agl:
"The DH and DSA code uses Go's math/big library, which isn't constant
time."

He said these non-constant time Go primitives are used by OTR, and will
be used by TLS if they are specified by the negotiated cipher suite.
The easy fix is to make go.crypto constant time, for at least what we need.

If we are okay with bad performance this doesn't require much trickery for DH: saturated limb arithmetic modulo
a constant with a precomputed Barrett reduction tables is constant time.

DSA is harder because the modulus is provided as part of the key. I don't know how to do that in constant time.

So xmpp-client's OTR and TLS support would definitely need to be
rewritten to call out to a native code implementation or rewritten to
use new constant time Go primitives, independent of OTRv2 vs OTRv3.


--
Mike Perry

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev




--
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin