On Sun, Dec 28, 2014 at 09:35:30PM -0500, David Leon Gil wrote: > 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.
Actually it's the attempts to remain compatible with the existing infrastructure, albeit it is by design exposing social metadata, that makes the problem difficult. Starting from distributed tech is likely easier, if you manage to wrap your head around it. Just take Pond and RetroShare as examples. Imperfect as they may be, they both solve identity management safer and more naturally than PGP. How? First of all by not separating cryptography from address routing. Next, since they have no obligation to be backward compatible with decades of technology that doesn't do the job, they can come up with creative alternatives to risky discovery methods like keyservers - exposing the social graph to everyone. Retroshare can adopt friends from friends. Pond has an anonymous cryptographic shared secret bootstrap method. More tools of this kind are being made, because the problem is less difficult than trying to fix e-mail. > 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. Waaait a second. Just because I simplify something so it doesn't fill three more pages of mail it doesn't mean that's the end of the story. There's a description of how identity recovery should work for us at http://secushare.org/threats - and if somebody truly trashed her identity for good, then she will have to start again from zero. Of course she is still a 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... Scalability is my background and the most important lesson I have to tell on the topic is that scalability can be planned for, there is a logic and a science behind it. Just because so many apps have just started out with something that worked, and later either randomly solved or not solved the scalability challenge, doesn't mean you only achieve scalability once you can measure it. http://secushare.org/pubsub tells a story about scalability and the way the architecture is laid out there is no reason to expect it not to be able to handle any number of users if the network as a whole grows appropriately. By the way, Tribler already exists and operates by very similar principles. > > 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. So let the user decide about that? Why are individual devices even in the focus? We are here to address mass surveillance! Let's not spend time trying to achieve 100% safety as long as we can impede mass surveillance. > > 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 Let me cite a few lines from the Threat Model: User must authenticate with the Identity Provider. Why on Earth would I still want something antiquated, complicated and privacy-reducing as an "Identity Provider" and even need to register and authenticate with it? If you start with a clean slate app there is NO NEED for something like this! First, the User needs to ensure it sent the authentication credentials to the right Identity Provider. Malware, weak authentication credentials, phishing, weak transport-layer security, etc.. are known to be problems in this situations. Second, the Identity Provider must authenticate the user. Most security vulnerabilities like XSS, CSRF, Auth bypass and so on, could potentially compromise this step of the flow. And then there are even more reasons not to even try that stuff right there as described by their own Threat Model description. I don't understand why you cite that as an "indeed" if rather looks like the perfect opposite of what I was suggesting? > > 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? Doesn't matter if your master key is on a piece of paper in your safe. You need to have a safe computer at least those few times that you generate subordinate keys for your devices, but you can trash your Microsoft Windows all the times you like in the moments between. Again, no ultimate 100% perfection possible. Printing out the master key sounds like the most reasonable compromise. > > 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. They are not public. You only get access to as much of the graph as your friends let you see. > 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.) Ok. > > 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. It is a further evolution of the last scenario you presented, obsoleting some aspects of it I believe. > > 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. The pubsub is already there and you can write to it so it gets to your friend. You don't need to know which of your friend's devices may be tuned in to listen, or picking the message up a week later. > > 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? No, it is per-pubsub. Therefore it is immensely more flexible and can be used to implement a distributed social network with any of Facebook- Snapchat- Whatsapp- LinkedIn- or Twitter-like usage styles. > I think it's generally better to -- if the underlying messaging protocol > uses ratcheting -- maintain separate per-device ratchets. The pubsubs maintain history, so if a device has been missing some messages it can recover from where it left off and fix its copy of the ratchet as it moves forward. > (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.) Synchronizing state is one of the core features of the pubsub architecture. It is fundamental for doing distributed social networking, but it happens to also be useful for messaging... as you just elaborated. > >> *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.) To me, Snowden has made it clear which threat model we have to take care of - the one that puts democracy at risk: bulk surveillance. I refuse to be paranoid about targeted operations as long as they don't scale to millions of targets. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
