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

[Sergio Lerner]

> On Tue, 26 Feb 2013, Sergio Lerner wrote:
>
>>> 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.
>
> No. If they can brute force your first ZRTP packet, then they can also
> brute force the next 10000 packets. Rotating keys that fast isn't
> buying yoy anything. Don't start out with such weak keys.
>
Who can brute force an AES key? Can you?
We are talking about D-H vs key-hashing/HCCK. We assume nobody can break 
neither D-H nor AES.

If you think that rotating keys is so harmful, then why Silent Circle's 
SCIMP protocol (which is state of the art) does just that? (using a KDF from 
the previous key.)

SCIMP rotates the keys for each message, and that's aproximately 3 blocks 
(48 chars avg message).
Not very different from my proposals.

Sergio.