[OTR-users] What type of encryption?

Ian Goldberg ian at cypherpunks.ca
Wed Mar 22 22:26:29 EST 2006


On Wed, Mar 22, 2006 at 10:14:58PM -0500, Gregory Maxwell wrote:
> On 3/22/06, Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > You can find all the details on http://otr.cypherpunks.ca/, but at a
> > high level, 1536-bit DH for key agreement, 128-bit AES-CTR for message
> > encryption, and 160-bit SHA1-HMAC for integrity protection.
> 
> I should read the source, but it's easier just to ask...  Is OTR just
> using a single DH group? Does the protocol have support for multiple
> groups?  Group sharing/agreement?

Yes, a single DH group in v2.  We can add more groups easily enough,
though, if we need to in the future.

> Thoughts on perhaps a later version of the protocol supporting the use
> of a shared secret hashed and XORed with the DH derived key (probably
> after a couple of seconds of key strengthening)? It would make a dandy
> form of MITM protection for people who can easily exchange a weak
> human compatible secret... As more sound form of authentication
> (exchanging fingerprints) is too much of a nuisance for most people
> other than crypto-dorks.    The side effect of mixing it with the DH
> derived key is that were DH (or perhaps just the group we're using) be
> found to be profoundly weaker than expected, users who authenticated
> with a shared secret would have an additional level of protection.

We've talked about this before, and in fact there's a much cooler way to
do this, which I totally have plans to implement.  It's called the
"socialist millionaire's protocol", and it lets two people determine if
they both know the same secret, while revealing no information about
each other's secret if they're not the same.  The way that it works is
that both sides end up computing r^(sA-sB), where sA and sB are Alice
and Bob's secrets (which don't have to have high entropy), and r is a
random number neither side learns.  So if the secrets are the same, the
value of this expression is 1, and if they're different, it's a random
number.

This was hard to do in OTRv1, when fingerprint verification was done
before any data could be exchanged.  But this would be another (easier)
way to go from "unverfied" to "private" in OTRv2.

   - Ian



More information about the OTR-users mailing list