[cryptography] Potential funding for crypto-related projects

Tom Ritter tom at ritter.vg
Sat Jun 29 19:24:27 EDT 2013

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130629/c283ba51/attachment.html>

More information about the cryptography mailing list