[OTR-users] OTR-encryption not safe - DSA 1024bit is too short

[Ian Goldberg]

On Wed, Dec 12, 2012 at 08:39:35PM +0100, . wrote:
> >> DH-1536 is RSA-1536 I guess (for exchanging the AES key, and use AES
> >> then for speed reasons).
> > No, RSA is not used at all in OTR.
> DH is Diffie--Hellman, right?

That's right.

> I thought it uses RSA to exchange the symmetric keys.

No, OTR does not use RSA.

> Just read:
> 
>     Therefore, both DH and RSA recommended key sizes are the same.

Yes, that's correct.

> 1536bit is really not too much, even twitter uses 2048bit, facebook & co
> will update to 2048 soon too.

You're talking about TLS certificate keysizes, which is different from
per-message session keys.  The adversary's reward for breaking an RSA
certificate is much, much higher than for breaking a single OTR message,
so the TLS cert sizes have to be larger.

> You know encryption should last a lifetime.
> Can I change the 1536 to higher values in the source code (looking at
> the char* names I guess no)?
> libotr-4.0.0$ grep -r "1536" .
> dh.c:static const int DH1536_MOD_LEN_BITS = 1536;

You could of course change the source code to anything you like.  But
you wouldn't be able to talk to anyone else.

> > Why it's not possible to choose the crypto to use: that would cause
> > incompatibilities.  If everyone could choose their own crypto, then some
> > people wouldn't be able to talk to other people, and there would
> > possibly even be rollback attacks where an adversary could trick you
> > into using a weaker cipher than you expect, by claiming not to support
> > strong ones.
> Claiming that one can only use 2048bit instead of 4096bit should not be
> possible by the program :)
> Using 4096bit should at least be possible by doing ./configure --dh4096
> and it should be fixed and not claimable.

Then your version of OTR won't be able to talk to anyone else's.  That
doesn't seem useful?

> I'd -- and others I guess -- even be happy (for the next 5years (in
> reality 2048bit would last longer but it's about not be able to decrypt
> something for a lifetime)) with 2048 ~AES-112, not AES-128, and it's
> still fast to create a key.
> Please switch to 2048

It's space in addition to time.  The DH keys are carried in every IM.
Whenever we do get around to changing the wire protocol again, we're
more likely to switch to something ECC based over DH->=2048.  But not
for a while.

   - Ian