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

[Ileana]

> >
> 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.

This still seems a very fringe case which seems to be a system issue,
not an OTR problem...in the sense that the user could create a udev
rule or script to execute on removing a usb stick, or pressing a key
combination, which immediately kexecs a new kernel and begins wiping
memory.
(see https://wiki.archlinux.org/index.php/Execute_on_USB_insert)

For OTR's part, I would think it would be sufficent to clear memory
used for temporary keys as soon as they are no longer used.

memory also retains after image when powered down for up to 5 minutes,
although the attacker could immediately pull the battery and throw the
laptop into liquid nitrogen or something like that, and recover the
memory contents at his leisure.

> 
> 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).

Any chat client might log messages before they go to the otr plugin.


> 
> 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.

>From your article:
>If an attacker managers to break in the computer at a certain time j,
>then it’s impossible for the attacker to recover the previous i<j
>counters (since SS was destroyed and BUFFER[j] cannot be used to
>recover BUFFER[i]).

Can you prove this mathmatically?
http://www.theregister.co.uk/2005/02/17/sha1_hashing_broken/print.html
http://article.gmane.org/gmane.comp.encryption.general/5154

I don't see how rehashing previous cipher blocks preserves the entropy
of your IV/SS. Rehashing blocks of the same size results in a poorer
hash security.  A pattern is estimated in 2^(n/2) iterations...which
granted is a big loop but that is 2^80 compared to what you want with
aes which is 2^128 and with recent research, but down to 2^51 and in
even 2^38 with some preimages you describe...in some cases...possible
with a super computer now-a-days.

Although I believe this will weaken the resulting encryption by not
having true random input data, I don't have reference to a specific
attack...although it seems it would limit the domain of the function,
as you have limited the range and effect random bits.

At the least, you could no longer say its AES-128 (or whatever) as this
doesn't seem recommended.


> 
> 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.
> 
>