----- Forwarded message from Maxim Kammerer
TextSecure’s upcoming iOS client (and Android data channel client) uses a simple trick to provide asynchronous messaging while simultaneously providing forward secrecy.
Not sure if I understand all iOS-related issues described, but this seems like overcoming engineering problems with a synchronous protocol like OTR on iOS at the expense of exposing the clients to a DOS attack of exhausting the prekeys. However, an asynchronous protocol does not mean that all information must be delivered in one push. In cables communication [1], I chose simple asynchronous messages because I don't trust complex SSL handshakes or the cumbersome OTR protocol, and because I believe that reliable delivery receipts and resilience to DOS attacks are as important as the message itself. The exchange goes similar to the following (each line describes what is sent by sender (s) / receiver (r)) [2]: (s) peer request (r) certificate, signed peer key (s) certificate, signed peer key, encrypted message+MAC (r) receipt+MAC (s) acknowledgement+MAC and is similar to a state machine where each state is retried in sender / receiver until a new state is reached. The exchange above is somewhat implementation-specific for short requests followed by long fetches (implementation is HTTP-based and targeted for .onions), and for generic messages it can be reformulated as: (s) certificate, signed peer key (r) certificate, signed peer key (s) encrypted message+MAC (r) receipt+MAC (s) acknowledgement+MAC (In cables, username is certificate's fingerprint, so MITM'ing the certificate is not an issue.) So, with a centralized DB / prekeys I guess it's possible to shave off the first two messages, but does it really matter if the protocol is asynchronous to begin with? [1] http://dee.su/cables [2] https://github.com/mkdesu/cables/blob/master/doc/cable.txt -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys@stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5