[messaging] Multiple devices and key synchronization: some thoughts

Michael Rogers michael at briarproject.org
Mon Jan 5 06:39:51 PST 2015

Hash: SHA256

On 04/01/15 18:40, Trevor Perrin wrote:
> On Sun, Jan 4, 2015 at 2:11 AM, Michael Rogers
> <michael at briarproject.org> wrote:
>> 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.

That's a really good point! I hadn't thought of using prekeys in a p2p
way. So I was wrong about p2p being an advantage of option 5.

Restating option 5 with this in mind, the QR code on Bob's business
card or wherever would contain contact details for a "contact point"
(which could be a server, a DHT, or one of Bob's own devices), and a
long-term public key for authenticating a single-use or short-term
public key retrieved from the contact point.

Authentication could be based on signatures (the long-term key signs
the single-use or short-term key) or triple DH.

> 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.

What do you see as the benefits of fingerprint authentication? I see
fingerprints as artifacts of our current crappy key distribution
methods. If we can do without fingerprints then so much the better.

If Alice and Bob have established a shared secret (by whatever method)
and they now have an authenticated channel (e.g. face to face) over
which they'd like to confirm that they've arrived at the same secret,
they can derive some values from the secret and compare them. They
don't need long-term master keys, as far as I can tell.

> 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.

The process by which a device introduces a contact to its owner's
other devices is asynchronous.

>> 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?

Yup, I agree that would also work.

> 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).

Taking into account that prekeys can be used in a p2p way, I agree
that there are no strict advantages to the approach I suggested. But I
don't see any strict disadvantages either - as far as I can see it's
just a different way of achieving the same goals.

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the Messaging mailing list