[messaging] Multiple devices and key synchronization: some thoughts

carlo von lynX lynX at i.know.you.are.psyced.org
Fri Jan 2 10:54:54 PST 2015

On Fri, Jan 02, 2015 at 10:12:27AM -0800, Tony Arcieri wrote:
> How do you handle network partitions? As a more specific example, how do
> you handle two devices which aren't ever necessarily on at the same time?
> Do you synchronize this ephemeral key via an always-on server of some sort?

The pubsubs I am talking about (and linked to documentation and design
paper in previous mails) are meant to reside on a backbone of GNUnet
relay nodes, somewhat akin to the Tor network. Participating nodes
would have an incentive to maintain a certain amount of state and
history of its channels, therefore the devices can pick up messages
and state changes at their equivalents of Tor's EntryNodes. We are
exploring two different models for incentivation, but I will leave it
to the next mail to go into detail about this if you are interested.
The end result however is that it should become very hard for an outside 
observer to trace each device's choices in EntryNodes and try to figure
out how the pubsub networks are structured. You can think of our pubsubs
as Tor circuits that split to as many recipients as necessary, yet each
participating relay only knows its nearest neighbors - plus these circuits
can also host state which allows for many applications to be implemented
without dedicated servers.

I'm sorry that this solution comes with a pretty large prerequisite
to get started, but once this hurdle is taken I believe many of the
challenges turn out easier to solve.

> My larger question was about revocation though. If you've lost one of the
> devices containing your long-lived key, now what? Do you revoke it or not
> and if so, how do you synchronize the new key to all devices?

As I described before in our current plan the long-lived key is not
supposed to be in memory anywhere. You use it to generate each device's
keys, you print it out on a sheet of paper, then wipe computer memory.
Therefore, only a device's key can get lost. When that happens you
pull out your sheet of paper, generate a revocation - possibly with a
specific time so that your peers know up to which time it was yourself
using that subkey, then sign new keys and distribute them. Your
peers therefore need to know your long-lived public key even if they
can't (or aren't supposed to) send messages to it.

> Having a separate key per device makes revocation easier, as you can just
> revoke a device-specific key then go on your way.



More information about the Messaging mailing list