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

[.]

On 12/12/2012 09:08 PM, Ian Goldberg wrote:
> 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.
Yes, now I've read that DH is actually not RSA+AES but its own
encryption (still to exchange symmetric keys for speed reasons).
>
>> 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.
I understand that my message content is basically unimportant compared
to twitter if you could break the key (that goes without saying).
Wonder: In OTR: if one would be able to decrypt one message, for how
long can one read the traffic? How often are new keys created?
>
>> 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.
I mean of course I would then send the patched source to the other
person too, that goes without saying too :)
>
>>> 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.
For me only 4096bit seems to be ok and because creating the keys takes a
bit, ECC seems to be a good alternative.
Unfortunately the Mathematics here are harder to understand, how secure
ECC is, but that's another story.
>
>    - Ian
> _______________________________________________
> OTR-users mailing list
> OTR-users at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-users