On Sun, Dec 28, 2014 at 6:48 AM, carlo von lynX <[email protected]> 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.) _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
