I would like to point out that the developers of the anonymizing network I2P are looking for more external review of the codebase (it's in Java, by the way). Everybody who knows how to do security reviews of source code and has time to spare should take a look at it.
FYI, I also think that I2P's supernode architecture is a whole lot better than Tor's directory servers. It's much more decentralized, to start with. A link on Hidden Services: http://donncha.is/2013/05/trawling-tor-hidden-services/ 2013/6/30 Tom Ritter <t...@ritter.vg> > I've been waiting to reply to this until I can give it an hour to get my > thoughts down. Hopefully it's not too late. This is a very important > question: where should we spend our time, and our effort? Because I know > you Moritz, I'm going to stray heavily into the Liberation Tech side of > things, as well as crypto. > > Of course my first thought it towards auditing, since it's my day job. > I've audited many open & closed source projects that were directly > cryptographic or built on top of cryptography, and found critical flaws. > This is a no-brainer. And it's valuable. But is it the *most valuable > thing*? For some apps, yes, for most apps, probably not. > > There are a host of hard problems we don't have good solutions to. > > For example, so many cryptographic projects are focused on content > confidentiality: PGP Email, OTR, IPSEC, SSL, so on and so forth. So _few_ > are focused on sender and receiver anonymity. The techniques to achieve > that: onion routing, mixing, anonymous(?) broadcasts, shared mailboxes, > PIR, are so under documented in accessible forms that they're never > considered in new censorship circumvention or anonymity tools. Research > into these areas, and bringing the content into more accessible forms, with > blog posts, graphics, architecture discussions and designs would be awesome. > > Similarly - so many encryption applications are widely distrusted because > they are centrally managed. Psiphon, Wickr, Silent Circle, Cryptocat, > RedPhone, so on and so forth. Research and explanations into how to deploy > a centrally managed but untrusted network would be invaluable. A great > example is Tor's Directory Server design. Frankly I'm only familiar enough > with it to know its strengths, not its weaknesses - but accessible > explanations into how it works, and how you can design similar things, > would be amazing. As a very practical example: Mixminion is in desperate > need of a directory service similar to Tor's. NickM said today "There > isnt' currently actually a design for the distributed directory thing you'd > want. I wrote a draft long ago, but I was even less good at this stuff back > then." Nick's being quite humble - the skeleton of one is there, and the > learning process of fleshing it out and developing it would be invaluable > for the community. > > Another pervasive problem is that virtually all of our tools are > detectable on the wire by a network admin, and classifiable. I've thought > about this, and broken censorship into a few buckets in my head: > - Source Censorship: You are censored. You're not allowed to go online. > (Well crap.) > - Destination Censorship: No one can talk to this IP, or resolve this > domain name > - Content Censorship: TCP reset packets that contain the words 'Falun > Gong' OR have a specific byte sequence (like the old Tor SSL handshake) > - Pattern Censorship: If someone has an SSH tunnel open, and they're > sending significantly more data than they're receiving, they must be > transferring an outgoing file, and kill that connection, but not other SSH > connections. (And similar ideas like "Well this SSL stream sure doesn't > *seem* like HTTP...") > Nearly all of our tools are, or can be, caught with Pattern Censorship. > And it's very important to recognise you can also detect without > censoring. "Who in my company is sending PGP emails from work?" "Who in > the US is using Tor?". It would be worthwhile to raise the bar for tools > (i.e. every tool expect Tor's obfsproxies) so that adversaries have to move > on to Pattern Censorship. It will be possible of course - it's an arms > race. But when we get to pattern censorship, we'll make it harder for them. > > > > There are other ideas. > > Of course there's that whole 'almost none of our tools are usable' problem. > > And the 'oh lawd, libpurple and ZRTPCPP are horrible' issue. > > You could fund someone to black box reverse engineer closed apps like > Wickr, Silent Circle, WhatsApp, GoAgent, iMessage, etc - and explain their > architecture. > > Or fund someone to document that which is not-too-documented. I recently > read "From a Trickle to a Flood" that is a fantastic summary of Mix Network > pooling algorithms. Something similar to that for undocumented things. > Something I've been struggling with for a bit is Type I remailer > instructions, and why they were chosen. > > I'm sure most people on this list have half completed drafts of serious > proposals that could really improve things - but need someone to finish the > draft, publish, and potentially write code. I believe in Academia the term > for such people is 'Grad Students'. Have people submit their half-written > proposals and fund grad students for them. I know I'd submit ;) > > > > In conclusion - I would recommend that besides funding individual > projects, you also consider some of the issues that we as a community are > lacking either solid architectures of; or accessible explanations of how to > integrate those architectures into projects. > > -tom > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
