[OTR-dev] Forward secrecy/deniability for long messages with low overhead

[Sergio Lerner]

On 26/02/2013 06:32 p.m., Paul Wouters wrote:
> On Tue, 26 Feb 2013, Sergio Lerner wrote:
>
>>> Read the spec. there is a separate method for negotiating a symmetric
>>> key using OTR. You then use that key for the bulk transport encryption.
>>> I don't know from the top of my head if Alice and Bob have a way of
>>> acknowledging the key for destruction, but I would expect so.
>>>
>> Yes but you don't get forward secrecy for the file during transmission
>> of a 1 Gb file.
>
> If you can't keep a session key secret for the duration of the transfer,
> you are toast. cycling a AES key because you don't trust it for more
> then 5 minutes instead of one hour buys you a factor 12, which is
> basically nothing in order of magnitudes crypto normally works at.
>
Perhaps it doesn't make sense in OTR for messages.
But If you're streaming audio with ZRTP
(http://zfone.com/docs/ietf/rfc6189bis.html), then the mode makes
perfect sense.

Also one of the marking features Ian Goldberg advertises in his lectures
is that OTR can work on devices with very low CPU capabilities.
So doing a single D-H exchange and multiple counter re-hashings (every
end of a message) is much better than doing D-H all over for each message.

ALSO, the attacker can try to break in your computer BECAUSE you've just
made a call to someone that is under surveillance, so you should be
prepared to be hacked just after you send your first message (and not
before).

See my last posts: 
http://bitslog.wordpress.com/2013/02/22/block-ciphers-modes-with-forward-secrecy-for-cryptocatotr/
http://bitslog.wordpress.com/2013/02/25/an-imaginative-use-case-for-the-hc-encryption-modes/
http://bitslog.wordpress.com/2013/02/26/comparison-between-forward-secrecy-of-hc-modes/

Best regards, Sergio.