[messaging] Multiple devices and key synchronization: some thoughts

[carlo von lynX]

Since secushare attempts to be a distributed social network
rather than a messaging-only system, these architectural
questions are solved in an apparently much easier way.

Think I should tell you. Maybe you also come to the conclusion
that it is wrong to build a factory for screwdrivers when later
you will find out you need screws and materials to make holes
in as well. It's better to plan for the entire architecture in
a single go and have an organic platform.

So here we go.

On Sat, Dec 27, 2014 at 10:23:47PM -0500, David Leon Gil wrote:
> # Multiple devices and key synchronization
> ## Introduction: The multi-device problem

Any popular application should be syncable, it's not
specific to messaging.

> A *user* is a human. An *account* is, well, an account
> with a service provider. An *identity* is some mapping
> between a set of accounts and a user or users. A *device* is

This definition is limiting. An identity should rather be
a key pair and the dependence on an "account" is an
architectural weakness. It should rather be able to use
a diverse network of relays in an unpredictable way for
observers such that no single "account authority" can
monitor or censor communications, or become a target
for hostile activity. There are solutions for this, so I
don't understand why you are still planning for an
outdated surveillance-friendly architecture.

> *Providers* operate "account authorities", which sign
> statements that attest to a device's control of an
> account. (E.g., by ordinary user login authentication.)
> 
> There is a trustworthy *keyserver* which any account may
> query to obtain the current set of keys associated
> with another account. (More on this in another mail.)

That sounds like not so good ideas to me. The proper way to
do IMHO is to have a most secure generate a master identity
and several subordinate identities so each device is
given one of those subordinate identities. Communication
counterparts can determine that a certain device belongs
to a certain person as they see the subordinate public
key is signed by the master public key. Yet the master
can produce a revocation of a former subordinate identity
and replace it with a new one as the user sees fit.

There is no need for external authorities at all. The only
trust you need to delegate is to the cryptography.

>   - Each account has, associated with it, a "recovery"
>   signing key, whose private component is stored offline.

Each person should have just one master key that can
ultimately prove the identity to other people. That key
signs all the necessary subordinate ones. Seems to me that
your architecture ends up having the same needs and
complexity of a provider-less system without achieving all 
the possible advantages.

> Keys may be rotated by cross-signing a new key, which
> is uploaded to the keyserver.

Why a keyserver? People should be in communication with
each other. If all the people have subscribed "friendship"
any key renovations will be pushed to them. secushare
makes anonymous pubsub channels on top of GNUnet so any
changes can be rolled out to all involved recipients
without letting any authority know that the communications
even exist. If you think keyservers are necessary for
bootstrap, then social graph adoption is for you. secushare
is intended as a distributed social network, so for the
average user it knows which people your friends know, that
you haven't subscribed yet. You will frequently be able to
adopt them by a simple "add" click, since it's unlikely
that your friends conspire to hand you a false public key
of the new friend. For people outside your social graph
you can resort to printed public keys in QR codes, or
bluetooth handshakes. No need to risk TOFU. But even if
you must, you don't need to centralize a keyserver - it
can be a distributed data structure in something like GNS.
Centralized keyservers are honeypots.

> ### Security goals
> 
> Security goals are standard for a messaging system that
> doesn't promise cryptographic deniability.[^traceability]

That is semantically unclear.

> The adversary is the global active adversary; it knows all
> internet packet's routes, can drop or replace them at will,
> and will conduct any computationally feasible attack that
> cannot be attributed to them. In addition, it has access
> to the (possibly encrypted) contents of every server.

Excellent definition.

> A *user-auditable local channel* is a local channel where it
> is blindingly obvious to the user if there is a MitM attack
> taking place. (E.g., it's obvious if someone sticks a piece
> of paper with a QR code on it in front of your phone, which
> is also displaying a QR code.)

Wonderful.

> ## Solutions to the multi-device problem

In secushare devices share each other's private pubsub channels
so they can update each other on any events happening, unless
they receive those events redundantly anyway. So synchronization
is not an extra problem, it's just a special use case for the
distributed pubsub architecture and cannot be distinguished by
observers from interactions with other users or anonymous
streams (like podcasts or a Twitter-gateway).

I'll add another variant strategy to the ones you listed:

### Ratchet-encrypted pubsub channels for everything

> To send a mail to an account, the sender encrypts to all
> encryption keys (with valid signature chains) returned
> by the keyserver.

In secushare senders subscribed certain of the recipient's
pubsubs as both considered appropriate. Therefore the
sender has public keys for several purposes. Yet, there are
no unicast messages or mails in secushare. Everything is
always a one-to-many channel - even if the multicast is happening
only between two entities.

So when a sender wants to send a message to a recipient,
it already has a communication channel set-up to that person
and doesn't need to know which or how many devices are currently 
receiving on that channel. Each channel has its own ratchet
so it doesn't need to use specific public keys. Each one-on-one
conversation can be extended to a group conversation by inviting
further recipients, up to the scale of a Twitter-like multicast.

I take specific care in designing the protocol for scalability,
since that is my background. Messaging technologies usually bump
into the scalability problem only when they try to show user
presence in the face of hundreds of friendships per person -
and then they are thrown back at cloud technology as the only
scalable remedy when the protocol itself has failed to scale.
Another moment when scalability of messaging systems falls apart
is when it attempts to do decentralized social networking.
Each social message is a one-to-many operation, possibly to
thousands of recipients. So ignoring scalability at the time of
design of a messaging system usually cripples it in the long-term.

But let's get back to the 1:1 special case. The owner of the 
channel remains in control of where messages go to, ensuring the
respect of device trustworthiness criteria for example.

If you're a whistleblower, and I don't trust my smartphone, the
smartphone will never know about the channel you are submitting 
messages to me. Neither will you know I have a smartphone at all.

#### The good parts

Fulfils all discussed requirements, plus also long-term ones
like scaling to realistic human social graphs and functioning
as a Facebook-like social network platform without anyone
providing for it.

#### The bad parts

Suggest some. I don't know any.

> *Targeted malicious messages.* The flip side of all devices
> being able to decrypt all messages, as above.

That I consider beyond scope of our work. Targeted attacks against
specific persons from inside their social graph is equivalent to
regular human treason. We don't protect against that on a social
level either. As long as systematic attacks against all users are
impossible, mass surveillance/compromise is impeded. That is the
goal of secushare.


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet