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. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
