[messaging] Multiple devices and key synchronization: some thoughts

str4d str4d at i2pmail.org
Fri Jan 2 15:31:22 PST 2015

Hash: SHA512

carlo von lynX wrote:
> 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.

At first glance (I haven't looked at your pubsub system in any depth),
it looks like this could easily run on I2P too. The way I2P tunnels
are set up allows this kind of pubsub data handling, and we already
have one example of it called Streamr for streaming audio and video
over I2P [0].


[0] https://geti2p.net/en/docs/api/i2ptunnel#client-mode-streamr

> 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.
> Exactly.


More information about the Messaging mailing list