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

[Sergio Lerner]

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.

Attacker knows: EK, BUFFER[i], the last sent ciphertext block C
Attacker guess: last block is G.

C = AES(EK, BUFFER[i-1]) XOR G

So he can compute X = Decrypt(EK,G XOR C), and then check if
Hash(X)=BUFFER[i].

To solve this problem I can think of two solutions:

1. Instead of using AES-CTR, re-key AES in each block with BUFFER[i] as
key and the plaintext as all zeros. The encryption becomes
  C = AES(BUFFER[i],0) XOR Plantext

Obviously this is not the best way to use a cipher, since key-schedule
takes much more time than encryption (more than 2 times in AES).
Also because possible related key attacks.

2. Use two hash-counters (keystreams) simultaneously:

Let SS be the initial shared secret.

IVK1 = Hash(SS | intialization-vector1)
IVK2 = Hash(SS | intialization-vector2)
EK=Hash(SS | encryption)
MK=Hash(SS | authentication)

And SS is destroyed.

Then we define the sequence:

BUFFER1[0]=IVK1
BUFFER1[i] =Hash(BUFFER1[i-1])

BUFFER2[0]=IVK2
BUFFER2[i] =Hash(BUFFER2[i-1])

Encryption: C = AES(EK,BUFFER1[i]) XOR AES(EK,BUFFER2[i]) XOR P

Now if the attacker knows C, G (guess), BUFFER1[i], BUFFER2[i] and EK, he cannot test if G is the correct previous plaintext.

This is almost 25% as fast as the normal AES-CTR mode, but... who cares?

My previous post did not generate any comment from  otr-dev members.
Either this is all wrong or it is too good. :-)

Best regards,
 Sergio.