On Thu, Aug 22, 2013 at 9:03 PM, Joseph Lorenzo Hall <j...@cdt.org> wrote:
> 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
compa...@stanford.edu.
