[messaging] Multiple devices and key synchronization: some thoughts

[Michael Rogers]

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

On 06/01/15 16:33, Trevor Perrin wrote:
> I think you're saying that when Bob gets a new device and
> introduces its public key to one of his existing devices, the
> existing device could send a message to all of Bob's correspondents
> informing them of the new device?

Right. That message kicks off an asychronous key agreement protocol
between Bob's new device and each of the correspondents' devices.

The messages comprising each instance of the key agreement protocol
are synced among Bob's devices and the respective correspondent's
devices, just like other messages.

> That seems worse than the other options.
> 
> What if Bob's device doesn't remember every correspondent?  What
> if Bob has cleared history, or isn't aware of everyone who has
> cached his "identity info"?

Bob has a contact list that's synced between his devices.

> What if Bob has ten thousand people he's ever corresponded with?

Then ten thousand people will want to know about his new device,
regardless of which approach we take to key sync.

The introductions can be done eagerly (inform every contact as soon as
possible) or lazily (inform each contact next time you communicate
with them). Or eagerly for the most frequently used contacts and
lazily for the rest, etc.

> What if some of them have changed their address, or are temporarily
> unreachable, or the message gets lost for some other reason?

Buffering and retransmission are handled by the message sync protocol.

> My argument is that instead of updating everyone that might be 
> remembering your identity info, it's easier to leave that info 
> unchanged and just sign the new device's key, or synchronize the 
> existing private key to the new device.

That's fine if you don't want anyone to know about the new device. :-)
Otherwise you'll eventually want to tell people about it.

> We could work through every possible infrastructure you might use
> your public key with, but I think the general point stands: the
> less often you change your public-key / fingerprint and have to
> redistribute it, the better.

"Your" public key and fingerprint are artifacts of a particular way of
managing keys. In systems where each person has a master key, of
course it makes sense to change that key as rarely as possible. But
not all systems work like that.

> Tackling this another way: You're assuming Bob informs his
> existing device of the new device's public key.  At this point,
> it's easy for the existing device to sign the new device's key, or
> encrypt the master private key to the new device.

Yes, those are also reasonable approaches, I've never said otherwise.
I was just trying to point out that other approaches exist.

> Since there's little cost to these, why not do one of them?  Do
> you feel there's some problem with signing device keys, or
> synchronizing the master private key?

As I said before, I don't think the approach I described has any
obvious advantages over the master key approach. I just thought that
since we were enumerating possible approaches, I should mention an
approach that we're thinking of taking with Briar, because it's a bit
different from the other approaches that were described. I'm not
trying to persuade you it's the One True Approach - I'm just
describing it.

>> 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?
> 
> I don't agree with those assumptions.  Or at least, there's a huge 
> difference between: - a single third party that everyone trusts for
> everything - context-specific third parties that particular Alices
> trust to inform them about particular Bobs
> 
> I agree the former doesn't exist, but the latter ones do, and
> those are channels I want to send "identity info" like fingerprints
> through.

I definitely agree that personally trusted channels may exist - and if
a channel like that is used for an introduction, there's no need to
validate the key material face to face.

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

iQEcBAEBCAAGBQJUrB7nAAoJEBEET9GfxSfM4kgIALdAB5NQ8gBv+SnYiFw3VpiQ
9qhTDU21tQovQdf9aRQpXD2DkSF5rLxMwJeyznUu+JOCejlbWRMnwmnYZxvxdEn2
BVsHEx2HkQuDhx4lumhgypQhOH+jndqgCTefq41e7bCpgcBHMESgo0jwwtUaxymj
MbFk1OqNNAgd4Xt7AxhiZSnK7nmw+EUyM/HR9LGusMnIRTsFcOXhiQlvQEUzq8MW
kbjSd3hUXPPEJEceHqhpvhqXsT2hE+1AAYDGYvI6dv44vJMhNC+EE9HLOPjcvpln
mzatZsb2EZnwXtqeyH+Dachvtu64KiAfBCzhF7NzDbsk4FkuDadli+oFIpaHXGM=
=j0Q0
-----END PGP SIGNATURE-----