[messaging] Multiple devices and key synchronization: some thoughts

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/01/15 00:18, Trevor Perrin wrote:
> On Mon, Jan 5, 2015 at 6:39 AM, Michael Rogers
> <michael at briarproject.org> wrote:
>> What do you see as the benefits of fingerprint authentication? I
>> see fingerprints as artifacts of our current crappy key
>> distribution methods.
> 
> I think fingerprints are simple and versatile enough that they'll 
> always be useful.  I also think better fingerprint formats would 
> increase their appeal (e.g. using your sentence generator [1]).

Perhaps this comes down to a difference of disposition. You see a
technique like that as making fingerprints more appealing, I see it as
making fingerprints less awful. :-)

> But fingerprints (like business cards) were an example.  I think
> we're really discussing the value of long-term identity keys:

Well, what I think we're really discussing is how to start a
conversation with someone using key material from an imperfectly
trusted source, and later check that the key material was valid.
Long-term identity keys and fingerprints are just means to an end.

>> 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.
> 
> I agree if Alice and Bob have some authenticated channel then 
> authentication is already taken care of.  So a long-term "identity"
> or "master" public key isn't needed.

I was saying slightly more than that - if Alice and Bob *now* have an
authenticated channel, but they didn't at the time they started
communicating, then they can still check that the key material they've
been using was valid, without needing long-term identity keys.

> But for an email or text-messaging case such a channel might not 
> exist.  So I've been making different assumptions: (a) Alice wants
> to send Bob a message (b) Alice and Bob might have never
> communicated before (c) Bob (and all his devices) might be offline 
> (d) Alice might be able to get some "identity info" about Bob's 
> public keys from a trusted third party (a mutual friend, a social 
> network, a PKI, a transparency log, Bob's business card, etc.) (e)
> Changing this "identity info" may be costly for Bob (telling all 
> his correspondents his info changed, changing a bunch of 
> registrations, getting new certificates, printing new business
> cards, etc). (f) Alice can lookup Bob's shorter-lived and/or
> one-time "prekeys" from some service (either centralized, or hosted
> by Bob's provider) which is not trusted for confidentiality or
> authentication.
> 
> Under these assumptions I like having the "identity info" in (d) be
> an "identity" or "master" public key (or fingerprint of same) that 
> doesn't change when you add new devices, so as to minimize the
> costs in (e).

Let's take the costs you've outlined in (e) one at a time.

Correspondents: Bob's correspondents are automatically introduced to
the new device by his existing devices. No effort for Bob.

Registrations: We've left open the question of where Bob's info might
be registered (servers, DHT, etc), but again, any of Bob's registered
devices can automatically authenticate the registration of the new
device. No effort for Bob.

Certificates: I'm not sure what you have in mind here. If you're
imagining that this will tie into some existing hierarchical PKI then
I guess it does make sense to continue the hierarchy and have a master
key that certifies device keys.

Business cards: You know what I think about this use case. :-)

> The most practical approaches are probably either synchronizing
> the identity key between devices, or using it to sign device keys.
> Either way, adding a new device might increase communication in
> (f), since Alice might have to retrieve additional device-specific
> prekeys, and/or signed device keys.  But adding a device would not
> incur the costs in (e), which is more important.

Why is it more important? Presumably (f) happens more often than (e).

>>> 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.
> 
> That's not asynchronous enough for email / text-messaging though
> (b, c).

Sorry, I don't understand what you mean by "not asynchronous enough".
It could literally operate over carrier pigeons.

>> 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.
> 
> I probably depends on your assumptions / use cases.  If you only 
> establish connections face-to-face that can be authenticated via 
> device pairing (QR codes, SAS, etc), then you may be right that
> having a single identity public key doesn't get you much.

I'm not assuming that all connections will be face to face. Face to
face connections are only required (a) to add a contact and
immediately know you're using valid key material for them, or (b) to
validate key material you've been using for a contact who wasn't added
face to face.

If we assume there's no totally trustworthy third party, and no
self-authenticating channel other than face to face, then these
operations need to be face to face for any of the options we've
considered, don't they?

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUq9A+AAoJEBEET9GfxSfMcF4H/3rGJJsYYXBA5fJOyyop7UjA
DanM5ibYv4Eh6+0AU+UTvKDzDId3FEFPjmr84eT9QE+wgLVhiVmNqYBZGsnBnMTP
bg7wlyVYhoAjyFpcwfucZ3AA9R8HPnGaPPPXqBphe7ows5zuQ/Ndq0d2g022Zqt5
4YFO79ILpFBFBhahOBJFNist54OHELRAfSUCFyHNiqsAz+d/fleQlIYGiXIobKkV
nkAMgMI1ooXZO9AKQ3rlVry6UDp0Se/ImjXUCoHW9fg267T2Q0DIKaT4VgFCFBMy
3MbtltkN0wcl5SzqsZZyqIF6YHPqx9HnKPd0dOIaLyc6UL/ycUpFjDxOX9hZIxs=
=EbI1
-----END PGP SIGNATURE-----