[messaging] Multiple devices and key synchronization: some thoughts

[str4d]

-----BEGIN PGP SIGNED MESSAGE-----
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].

str4d

[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.
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUpyo6AAoJEIA97kkaNHPnGKcP/jj8JhdPfl0AWR/vjBX7Q2mk
frOUBWWIr0MsixjCsXoxHU6kXSxyWHNKGplWkB4HG0sloHZ0orJ9eXN3jr+olcqH
NBNST97cewIgJejlbJIRLf66MCGfgGUFMzYDB0SI+kFxbXuzQ0t0izvonD39PweC
BG4mg2zjR+ZimTfWqnRiYYzBU+TOusORYTZ9MTP0vOO+jQ7sx2a5nAB9noQUB8kL
V84Z5905gFwyyPbcQG1yqRgPP9Ga+bHxtj7OwWup93DgB5FlqaLtoPHExQ2pkj/5
RPr5pR8rOWpmqVc0jyrKSKMEZ1FuwMKNSRVox1xu9IE68twFp4cdpqrehqaB1rVR
dPHvStHZBzf1SeRFFaorpwpDqNaUpQDgpWt04VBL/uAk+s7J3msw1HZMYrJ1wxmD
IhwmDh3LFYGwT7zCeTbuP64d1g340+1pJtDO7YEpPNaigtIsfWf88BegHa+rPv51
LFVdtbl/GiXZACZAxE6JysenQE9c/z7pHZZ4EU5qELvC9VA3QfCeMa7MfqP7YQeY
aA2faOpXjRppJ6O9aSu63Dnpj//2aoYS66AyhgtueGK0yd+sSdR8R5FFYv727qiZ
526kS+T3pMFo3yi2ebfQdHZAJaGhg8LW8Cz3ZsdgqI0gJlOO9d+/RrmoNfrh66n9
BWv2NNy/BxcfMlCkMuwT
=xXvH
-----END PGP SIGNATURE-----