[messaging] Multiple devices and key synchronization: some thoughts

[David Leon Gil]

On Sun, Dec 28, 2014 at 6:48 AM, carlo von lynX
<lynX at i.know.you.are.psyced.org> wrote:
> . . . It's better to plan for the entire architecture in
> a single go and have an organic platform.

In general, I agree. I would not like, however, to give up on the
idea that people's emails or instant messages can be private
because the problem is difficult.

> On Sat, Dec 27, 2014 at 10:23:47PM -0500, David Leon Gil wrote:
>> 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

Identity == permanent key-pair is crypto-nerd imagination
at its worst. You may think that you are your keypair. I can
assure you that you aren't: if someone hacks into your
computer and gets your private keys, you are still the same
person.

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

Agreed.

> There are solutions for this, so I
> don't understand why you are still planning for an
> outdated surveillance-friendly architecture.

I'm not aware of any proposals thus far that scale in the range of
2^27 to 2^33 users...

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

Yes, if we knew in advance which device would not be
compromised. But we don't; device compromise is
probabilistic.

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

Indeed, this is part of the "key transparency" idea that the
folks at Google have partially sketched out here:

https://github.com/google/end-to-end/wiki/Key-Log-Server

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

Again, this is not realistic: What's the last device you owned
that there were not zero-days for?

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

This is fine w.r.t. friends. (In fact, I think that nearest-neighbor
gossip is an essential part of any key distribution scheme.)

But making people's social networks public is not really privacy-
preserving.

W.r.t. keyservers, perhaps the description in my post was
misleading; I do not see that anything like a traditional
keyserver will work. (That is for a future mail.)

> I'll add another variant strategy to the ones you listed:
>
> ### Ratchet-encrypted pubsub channels for everything

I think that what you describe w.r.t. ratcheting is not incompatible
with anything I described.

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

I am not sure what this means, exactly.

> Each channel has its own ratchet
> so it doesn't need to use specific public keys.

This is essentially a system with a shared per-pair encryption key, no?
I think it's generally better to -- if the underlying messaging protocol
uses ratcheting -- maintain separate per-device ratchets.

(This is mainly because of the practical problem of synchronizing
a ratchet state while dropping missed message keys as soon as
a realtime bound is met.)

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

Yes, it probably is something outside of my threat model as well.
But it is a possible threat-vector; and I would like some opinions
as to whether it is a serious one. (From people more on the attack
side of things.)