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

[Sergio Lerner]

On 22/02/2013 03:17 p.m., Ileana wrote:
> On Fri, 22 Feb 2013 14:36:25 -0300
> Sergio Lerner <sergiolerner at certimix.com> wrote:
>
>> I was thinking again about my proposal and found that it has a
>> drawback. Suppose an attacker breaks in a computer that is
>> communicating with OTR, he can try to guess a plaintext and use it to
>> check if the encryption is correct.
> Am I missing something?  If the attacker has compromised the computer,
> do they not have direct access to system memory containing the
> temporary keys, including the plaintext via keyboard hooks?
>
I'm not talking about a persistent attack. I'm talking about the FBI or
KGB braking into your apartment pointing at you with a gun and telling
you get out of the keyboard now. Imagine you don't even have time to
switch the computer off. Now the computer has all the evidence they need.

The same situation can arose remotely. The attacker detects that you're
saying something very important to someone and THEN tries to break into
your computer to get this (past) messages. In the current OTR protocol,
after each message is sent, encryption keys are securely erased (at last
this is wait is said in the docs).

Still Cryptocat has a message log, which I consider to be not helpful in
this situation. The message log height could be user configurable, so a
paranoid would use a very be short log (say the last two messages), and
the software could erase from memory any trace of previous sent or
received messages (if the user wants to).

My protocol could also  be used for mpOTR ot avoid continuously redoing
the D-H protocol, which is expensive if many parties are involved. But I
haven't read the mpOTR spec yet.

I put all this ideas on my blog, so I can update with your comments:
http://bitslog.wordpress.com/2013/02/22/block-ciphers-modes-with-forward-secrecy-for-cryptocatotr/

Best regards, Sergio.