[messaging] Multiple devices and key synchronization: some thoughts

[Michael Rogers]

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

On 04/01/15 00:27, David Gil wrote:
> On Friday, January 2, 2015 1:36 AM, Michael Rogers
> <michael at briarproject.org> wrote:
>> I'd like to add a 5th option to the list. Sorry for top-posting, 
>> I'm using a different device. ;-)
> 
> You are quite right; let's call this key-exchange over purely
> local channels.
> 
> Main issue: If done poorly, which is almost certainly always when 
> the local channel is one-way (i.e. a QR code), security against 
> local attackers is utterly compromised.

A one-way channel that's authenticated but not confidential is
sufficient to bootstrap a two-way channel that's confidential in both
directions and authenticated in one direction.

A two-way channel that's authenticated but not confidential is
sufficient to bootstrap a two-way channel that's confidential and
authenticated in both directions.

These are standard results that apply to local and network channels alike.

Scanning a QR code is a one-way channel that's authenticated but not
confidential (you know which device you're scanning, but you don't
know which device is scanning you, and everyone can see the QR code).
Mutually scanning QR codes is a two-way channel that's authenticated
but not confidential.

"If done poorly" is a red herring. Anything is insecure if done poorly.

> (And I think it's nearly important to protect against local 
> attackers as it is to protect against network attackers.)

I agree, and my suggestion was based on that assumption.

> To summarize the options:
> 
> 1. How to authenticate key material a. Purely local channel (local
> attackers get useful information under assumption some local
> channels are one-way)

The QR code can contain an ephemeral public key, so local attackers
don't learn anything useful.

> b. Purely network channel (server can try to MitM) c. Local and
> network channel (need a local attacker cooperating with network
> attacker to even attempt MitM)
> 
> 2. The asymmetric private key material to synchronize a. A single
> signing and encryption key b. A single encryption key and multiple
> signing keys c. Nothing
> 
> 3. The symmetric key material to synchronize: a. A messages-at-rest
> key b. Nothing
> 
> (You always need to synchronize enough public key material to 
> bootstrap trust with other devices and all the account's
> correspondents.)
> 
> I still think that 1(c), 2(c), and 3(a) are the best choices for an
> email-like service; 1(c), 2(c), and 3(b) are the best choices for a
> messaging-like service.

Cheers,
Michael

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

iQEcBAEBCAAGBQJUqQQEAAoJEBEET9GfxSfMACQIAKOWBt1sMCT+yp1ye3ok8049
2lBifBWdYSfJnjUsfY6eo2xTcuhrLLt0MYetddUPUOG8bvOBFFkd/maVXtibFNmN
ipMc/onnb29EPNr6wQeJB/eCEFE444NRvkpYujdyIPBkQBJu7EpkwyW6Ucz/typO
bYXeKFH3Fqk5bE+3rvXfwsZXU39GrAW4VlRJQY9hBkFA4hU7E27gmvATsoCaZmYo
H3VHFAXMqbMsny5xpuD/zTlbbZH2n4bKDMB4l0pgO112J2/iSikL+UDxpbVqx0gU
hnOB8xdgadsjDF1VGyd3Ndr1ImnYHfPW/fxUfUsQ3iQVrqs4MZYdvNZrWIwCnIc=
=+kfE
-----END PGP SIGNATURE-----