[liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying"

[Eugen Leitl]

----- Forwarded message from Maxim Kammerer <mk at dee.su> -----

Date: Fri, 23 Aug 2013 00:43:11 +0300
From: Maxim Kammerer <mk at dee.su>
To: liberationtech <liberationtech at lists.stanford.edu>
Subject: Re: [liberationtech] Open Whisper Systems' neat asynch FPS "pre-keying"
Reply-To: liberationtech <liberationtech at lists.stanford.edu>

On Thu, Aug 22, 2013 at 9:03 PM, Joseph Lorenzo Hall <joe at 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 companys at 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