[messaging] Multiple devices and key synchronization: some thoughts

Michael Rogers michael at briarproject.org
Sun Jan 4 02:11:57 PST 2015

Hash: SHA256

On 03/01/15 20:13, Trevor Perrin wrote:
> On Sat, Jan 3, 2015 at 12:06 AM, Michael Rogers 
> <michael at briarproject.org> wrote:
>> Let me say first of all that I don't think we should get hung up
>> on business cards. Billions of people use mobile phones as their
>> main or sole messaging devices; very few people print their own
>> business cards. We should focus on the tech that people actually
>> use.
> OK, but that was just one example of the general case "Alice sends
> a message to Bob asynchronously (i.e. Bob is not online),
> authenticated by Bob's fingerprint".
> Alice might have found Bob's fingerprint on his business card, or 
> social media profile, or through some directory lookup, or by 
> corroborating the service-provided fingerprint with her friends.

Good point.

> This case is possible if Bob has a single master public key that 
> either signs device-specific public keys, or whose private key is 
> shared between devices.  It's not possible if Alice must interact
> with one of Bob's devices to learn about the others.
> 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.

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.

Briar uses (a) for adding contacts face to face, and will use (b) for
adding contacts via mutual contacts.

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the Messaging mailing list