4 ms·

I think it's cool that you're making usable security software. I do worry that "usable" has gotten more thought than "security", and providing a system that do

I think it's cool that you're making usable security software. I do worry that "usable" has gotten more thought than "security", and providing a system that doesn't deliver the security it promises could be worse than not having the software at all. It may end up conveniently serving up those at most risk to their adversaries. As others have noted, anonymity is hard to get right, and the approach here has some serious flaws: 1. It seems that the pseudonymous author of posts can easily be determined by connecting a bunch of Sybils (i.e. multiple clients) to as many other peers as possible and observing who is the first to send new posts by the target pseudonym. And you really can't have a forum without pseudonyms. Users will create them on their own (by including a nickname in their posts) even if you don't build it in. 2. There is an easy so-called "intersection attack" in which the sets of users that are connected at any given time a pseudonymous entity posts are intersected. The actual author will always be present, and the other participants won't be static, and so eventually only the author will remain in the intersection. 3. There is no apparent protocol obfuscation. Despite the use of TLS, the protocol traffic patterns of this new protocol are likely to be highly identifying. They can then be easily confirmed by an active attacker directly connecting to the suspected participant. In addition, it doesn't seem that the list of participants is protected, and so an adversary can just connect to the network to discover who to block or punish. Tor will not solve the problem here if users have to be able to receive incoming connections. And if you're using Tor, then you are relying on an external system that has censorship issues of its own (e.g. access from China is currently extremely limited) and does rely on servers. 4. The bootstrap IPs can obviously be easily blocked. 5. The votes are not anonymous, which is unlikely to be clear to users and which are nearly as sensitive as authorship itself. 6. Denial-of-service here is as simple as flooding the network with "forwarded" posts and votes. Here are some suggestions for designing a system that is secure and that people can trust as being secure: 1. Write a white paper describing the design! This is not a detailed protocol spec - it's a description of how the protocol works at a higher level along with arguments establishing its security properties. This allows others to understand and critique the design. 2. Check out some of the related system designs [0-6]. They have had to deal with the same issues, and you can learn from them. You can get all these papers and more at <http://freehaven.net/anonbib/> http://freehaven.net/anonbib/>. As you can see at that site, people have been thinking about these issues for a while and have figured out a lot! 3. Submit your white paper to a computer security conference. Even if it doesn't get in, you will get feedback from experts. As it is currently, I wouldn't trust my communication to this system. You really need a large and diverse user base to provide anonymity, and so you will have to work at convincing people that this is something they can trust. Good luck! [0] "Membership-concealing overlay networks" by Vasserman et al. CCS09 [1] "Crowds: anonymity for Web transactions" by Reiter and Rubin. TISSEC 1998. [2] "Freenet: A Distributed Anonymous Information Storage and Retrieval System" by Clarke et al. PET 2000. [3] "Trafﬁc Analysis: Protocols, Attacks, Design Issues and Open Problems" by Jean-François Raymond. PET 2000. [4] "ScrambleSuit: A Polymorphic Network Protocol to Circumvent Censorship" by Winter et al. WPES 2013. [5] "Drac: An Architecture for Anonymous Low-Volume Communications" by Danezis et al. PETS 2010. [6] "Tor: The Second-Generation Onion Router" by Dingledine et al. USENIX Security 2004.

rolleiflex 13y ago
Now, this is the comment I came to HN for. Thanks for this, I have a few readings to do. For your points, While I don't have a full–scale refutation, here's a few addendums in order. All of this is wrapped in a giant 'If I understand you correctly'. > And you really can't have a forum without pseudonyms. Users will create them on their own (by including a nickname in their posts) even if you don't build it in. That's human self–incrimination. As long as this is safe for an one–time user that opens the app on an internet cafe, posts something and goes away, I have some basic semblance of security I can build upon. That does not mean it is secure, it just means it's secure for something—and that's a start. (It might not be actually secure for even that, let me know if you know it not to be so) > There is an easy so-called "intersection attack" in which the sets of users that are connected at any given time a pseudonymous entity posts are intersected. The actual author will always be present, and the other participants won't be static, and so eventually only the author will remain in the intersection. The actual author won't always be present. The posts start at a point, but they do not need the author to be present to continue distribution. When Alice posts something and Bob gets the post, from then on Alice can disappear forever. If a post is below a threshold of availability on nodes Bob is connected to, Bob will flag it as neutral post (to make that distribution not count as an upvote) and start distributing it on his own to prevent post extinction. That said, this doesn't prevent intersection attacks, it just makes them less viable. > Tor will not solve the problem here if users have to be able to receive incoming connections. The users do not need to accept incoming connections. There are some very restrictive routers that refuse to be UPNP port mapped, and Aether works fine on them. > and so an adversary can just connect to the network to discover who to block or punish. For this, the roadmap is to have a 'protected' node which refuses all connections from nodes except those who are explicitly marked as trusted. > The bootstrap IPs can obviously be easily blocked. It does not rely on the bootstrap IP. If you have installed the application, it asked you in the onboarding process IP and port of a friend that you know to be online. If you give it that, it'll use it. In fact, I'm planning to turn the bootstrap node off or just make it a redirect to some other random node in the future. > The votes are not anonymous, which is unlikely to be clear to users and which are nearly as sensitive as authorship itself. They point to node id's, which are not users, but machines. This is an inherent tradeoff, in that I have to have some data to gauge the popularity of a post. As far as I know, there is no way out of this without implicit trust in a third party. > Denial-of-service here is as simple as flooding the network with "forwarded" posts and votes. Well, those posts won't get upvoted, and will get stuck in spam filters and upvote thresholds of users. None of those are implemented yet, of course, but this doesn't seem to be a structural problem. > As it is currently, I wouldn't trust my communication to this system. Please, for the love of god, don't trust Aether (yet). This is barely alpha level code. For the rest, thank you. Much appreciated. I'll be reading.

rolleiflex 13y ago

Now, this is the comment I came to HN for. Thanks for this, I have a few readings to do. For your points, While I don't have a full–scale refutation, here's a few addendums in order. All of this is wrapped in a giant 'If I understand you correctly'. > And you really can't have a forum without pseudonyms. Users will create them on their own (by including a nickname in their posts) even if you don't build it in. That's human self–incrimination. As long as this is safe for an one–time user that opens the app on an internet cafe, posts something and goes away, I have some basic semblance of security I can build upon. That does not mean it is secure, it just means it's secure for something—and that's a start. (It might not be actually secure for even that, let me know if you know it not to be so) > There is an easy so-called "intersection attack" in which the sets of users that are connected at any given time a pseudonymous entity posts are intersected. The actual author will always be present, and the other participants won't be static, and so eventually only the author will remain in the intersection. The actual author won't always be present. The posts start at a point, but they do not need the author to be present to continue distribution. When Alice posts something and Bob gets the post, from then on Alice can disappear forever. If a post is below a threshold of availability on nodes Bob is connected to, Bob will flag it as neutral post (to make that distribution not count as an upvote) and start distributing it on his own to prevent post extinction. That said, this doesn't prevent intersection attacks, it just makes them less viable. > Tor will not solve the problem here if users have to be able to receive incoming connections. The users do not need to accept incoming connections. There are some very restrictive routers that refuse to be UPNP port mapped, and Aether works fine on them. > and so an adversary can just connect to the network to discover who to block or punish. For this, the roadmap is to have a 'protected' node which refuses all connections from nodes except those who are explicitly marked as trusted. > The bootstrap IPs can obviously be easily blocked. It does not rely on the bootstrap IP. If you have installed the application, it asked you in the onboarding process IP and port of a friend that you know to be online. If you give it that, it'll use it. In fact, I'm planning to turn the bootstrap node off or just make it a redirect to some other random node in the future. > The votes are not anonymous, which is unlikely to be clear to users and which are nearly as sensitive as authorship itself. They point to node id's, which are not users, but machines. This is an inherent tradeoff, in that I have to have some data to gauge the popularity of a post. As far as I know, there is no way out of this without implicit trust in a third party. > Denial-of-service here is as simple as flooding the network with "forwarded" posts and votes. Well, those posts won't get upvoted, and will get stuck in spam filters and upvote thresholds of users. None of those are implemented yet, of course, but this doesn't seem to be a structural problem. > As it is currently, I wouldn't trust my communication to this system. Please, for the love of god, don't trust Aether (yet). This is barely alpha level code. For the rest, thank you. Much appreciated. I'll be reading.