Hello! This is my first message to the list, so forgive me in advance if I break any per-established rule. Also forgive me if the subject I will talk about has already been discussed in the past or if I misunderstood the protocol in a way that makes this message meaningless.
One of the most interesting thinks I've found in OTR is the ability to provide forward secrecy. Nevertheless, as I've read in the section 4.2 of the paper http://www.cypherpunks.ca/otr/otr-wpes.pdf, some times keys are kept in memory for long times if the remote used does not reply. I can think of two scenarios where this is a drawback: 1. Alice sends many messages in a row, but Bob does not reply. 2. Alice want to send a big file to Bob while (say 10 Mbytes) using OTR with forward secrecy. Examples 2.a) Alice is sending audio/video chunks recorded with his microphone/camera over OTR. 2.b) Alice is downloading a file and at the same time she is sending it to Bob. In both three cases she wants that at any time, if her computer is compromised, then the data already sent is protected unconditionally. Also in these last two cases, going though D-H for every block transmitted may imply a very high overhead, and a reduction in throughput because of the RTT latency needed to exchange D-H messages. My proposal it that AES-CTR uses a one-way function instead of an incremental counter. Also the IV is derived from the shared secret. Let CTR[i] be the plaintext used for the counter in AES-CTR. Let SS be the shared secret. Normally the protocols does: EK=Hash(SS) MK=Hash(EK) We change this sequence to: IVK = Hash(SS | intialization-vector) EK=Hash(SS | encryption) MK=Hash(SS | authentication) And SS is destroyed. Then we define the sequence: BUFFER[0]=IVK (the buffer is 256 or 512 bits wide) BUFFER[i] =Hash(Buffer[i-1]) (in the implementation, BUFFER[i] overrides the memory positions of BUFFER[i-1]) CTR[i] = BUFFER[i] (truncated to 128 bits) So CTR[0]=IVK (truncated) After each block i of AES-CTR is generated, the BUFFER is recycled and the previous counter is lost forever. 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]). I think the overhead of a Hash evaluation per block is unimportant for a protocol of this kind, and is much less than a full D-H key exchange per block sent. If one wants to go one step further, then we also provide deniability during long message transmission: Define MK[i] = Key-derivation-function( MK , i ), like HMAC( MK | i ) Then Alice send each block i authenticating with the key MK[i] and Bob acknowledges the correct reception (by MAC verification), then MK[i] is published. Now, if we apply this algorithm to ANY message (being short or long), D-H would be required only once at the beginning of the session, which gives a much faster protocol with the same security/privacy guarantees. Am I missing something? What do you think? Best regards, Sergio Demian Lerner. www.certimix.com _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
