[messaging] Multiple devices and key synchronization: some thoughts

[Trevor Perrin]

On Sun, Jan 4, 2015 at 2:11 AM, Michael Rogers <michael at briarproject.org> wrote:
>
> On 03/01/15 20:13, Trevor Perrin wrote:
>>
>> In asynchronous scenarios (like email or text messaging), this
>> seems a disadvantage of your approach compared to the (1)-(4)
>> proposals.  What do you see as the advantages?
>
> In brief: forward secrecy and peer-to-peer.
>
> If we want forward secrecy then the information Bob publishes (on his
> business card or wherever) can't be a long-term encryption key.
> Assuming Bob doesn't have a way of remotely updating old business
> cards, it can't be a short-term encryption key either. It has to be an
> authentication key for authenticating a key exchange or a short-term
> encryption key.
>
> So how do we perform that key exchange or obtain that short-term
> encryption key in an asynchronous setting?
>
> In TextSecure (if I understand right) the answer is to use a server to
> hold prekeys.

Yes, but short-lived prekeys/subkeys for forward-secrecy could be
delivered from a server, or directly from one of the recipient's
devices.  So this approach is flexible to interactive or
third-party-assisted (asynchronous) cases.

I was thinking a multidevice approach should have the same
flexibility, and should allow fingerprint authentication.  This is
possible provided you use signatures from a master key over device
keys, or synchronize the master private key to devices.

If you require interaction with one device to learn about others, you
lose "asynchronousness", and I'm not sure what you gain.  If you're
using different device keys not signed by a single key, you lose
fingerprint-ability.

> If we want to do things peer-to-peer, we can either (a) require the
> key exchange (though not the subsequent messaging) to be synchronous,
> or (b) do an asynchronous key exchange via someone with whom Alice and
> Bob have already set up asynchronous messaging channels.

If you can lookup signed devices keys and short-lived forward-secrecy
keys from any party (including Bob himself), and authenticate them
with a fingerprint, I think that would also be sufficient?

To me, it seems like such an approach is flexible to the cases you
want to support, and others, so I'm unsure of the value of doing more
limited things (like a).


Trevor