My Tor Project/OpenITP Hackathon Live Blog Day 2: Circumvention Boogaloo

1st report back: Come up with set of recommendations for future projects, and possibly follow-up steps

1. Get user input from design phase
2. Lots of orgs out there do training (gipi.kg, for example), can have some extra functionality where they let devs know what they need to fix/enhance, and should include in funding requests et. al
3. Idea that peer-to-peer training is how software will get used, users teaching users, and similar for bugs.  The tool should give you an opportunity to send in bug reports, which may be over the tubes or send to someone else via ex. email or conversation.  Needs to originate in the tool.

------------------

GAME THEORY OF CENSORSHIP

"The mathematics of conflict.  Typically fails when you do the math wrong, and often people have bad models, so they say that it's bad people don't conform to models.

Player 1: Govt trying to control access to information
Player 2: Narod/People

Listed possible moves, Mada (sp?) model that tries to predict govt reaction to various moves, can also help with investment decisions, list what might not lead to crackdowns.
There is an academic who has two or three papers on this (name of academic will be on the public wrapup).

----------------------------

ANONYMOUS PUBLISHING

We talked anout probs of publishing services, talked about how to get users to learn about what (Iranian address?) is.

TOR Anonymous Packet Execution Framework - Framework that makes hidden servies more useable (GOOGLE THIS)

---------------------

BROKEN CERT AUTH PROBLEM

Listed a bunch of technologies that are trying to resolve existing problems. Rough concensus was that we will need several of these to tackle probs with existing models.  Each solution seemed to add some problems that were mitigated by others.

One main question was how to put user in control without overwhelming them (convergence.io has been a prob like this I (Peter) think).  Trouble with Dane is it concentrates power in the DNS hierarchy, which is where a lot of Internet abuse has occured.  But Convergence and a bunch of other tools could help.  Another thing is you now need a persistent client, which can be HUGE problem if somebody seizes it.

In addition to Convergence there's a similar plugin built by somebody at UNLV

Programming, muthafucka!

ONE TIME PAD HACK SESSION (READ: Developer presents what he has and folks poke at it to look for problems)


google one time pad open source
(version 2.0 won't be backwards compatible with earlier)

Not trying to fix key management.

Somebody suggested encrypting twice, e.g. encrypt with AES and then do one-time-pad, then if somebody flips bits or does plaintext attack, you could catch it.
Could add headers not visible until after decryption.
Ex:
Content type(?)
Mime-type
Filename
Bzip headers
Original file name

(First bit of feedback is that it's pointless)

eh, might not be perfectly random.  Any time you can have expected plaintext results, it can help you with figuring out the key.

Why punt on the most difficult part, key mgmt?  Because some people have volunteered to handle this themselves.  But is the extra complexity worth it?  I for one think it's pointless.
Dayum, somebody did some tests and found that 1st 20 bytes of bzip are predictable.

Entropy is hard to come by, and can be easily drained.
If you bring in random data from /dev/rand, and you drain the entropy, and you know where in the stream they are, then what? (well, I need to read up on random data in Linux!)

Idea here is:
BASE64ENCODE( OTP( AES( BZIP( X ))))
                  ^
  And what is the key here?  Can be a problem if rand. num. generator is broken.
s/AES/"Something Dan Bernstein wrote"

AES there to make things looks random even if you get through the pad
One thing that's really important here, is some update systems download a file with a hash attached, so you have to parse whatever you downloaded before you can verify integrity. DERP!!!

(btw, /dev/urand is garbage, guy in front and Applebaum disagree about whether it and /dev/rand are garbage or not.)
 ^---Prob is very little data generated from other devices on embedded sys., no mouse/keyboard.

Linux will often add something to the pool by hashing without crediting it.

This could be an argument for encrypt then MAC, Mosh uses this

Seems almost disingenuous to offer this and punt on where to get random data.

Given that some people think they can or can't get random data, should we supply a tool for that, too?

OTHER PROBLEMS

Whole bunch of stupid quirks here

Another fundamental problem, in the header there's a pad ID, it's a checksum of the first ~512 bytes of the pad.  That's sitting out there in the open, which is ok if you can't reverse it.  There is a risk (didn't quite get this) that you can give away the AES key.

(we went over a possible bookkeeping nightmare, if something gets mixed up, how do we know which pad to use?  Can cycle through, but can be a usability prob without some shell scripts)

PROGRAMMING, MOTHERFUCKER!!!
(this is a good talk, but I do have code to write)

SUMMARY

Is a goal to have a very small amount of code that you can audit and say "oh it's just XORing"?  Ok, then maybe we don't need all these func. calls.
And boy has this gotten complex, so we're telling users not to roll their own crypto while we roll our own crypto.  BUT it's very easy to scrutinize the way this has been structured.

What's the point of compression?  If you boil everybody's data down to bzip, becomes not-so-random.

AND WE'RE DONE WITH THAT PANEL

--------------------------------------------------

WHAT GOOGLE CAN DO TO LOOK AT LEAST MEH

Promoting HTTPS (its slogan: "Hey, we're better than Telnet!")
Let's just stop supporting HTTP (still not a bad idea)

--------------------------------------------

AFTER LUNCH

Check out Torbirdy.  It's Tor for Thunderbird!

TELEX: ANTICENSORSHIP IN THE NETWORK INFRASTRUCTURE

Operates in the network infrastructure - place a proxy in the core, not on some end host.  We use an end-to-middle proxy with a "pretend connection" at some ISP.  Doesn't provide anonymity, but more circumvents detection
Works on a form of DPI, no secrets involved (+5 points for you on that).

Threat model:
assumes
1. Threat censor controls all network infrastructure INSIDE (sound familiar?)
2. Blocks according to a block list
3. Allows HTTPS connections to unblocked websites
This is awesome
|
A---|--------proxy connection at friendly ISP*---------------notblocked.com
| ^
| |
      BLOCKLIST  

*invisible tag placed, but only visible to A, who has a private key.  At ISP
shared secret gets shared between client and proxy
request for blocked.com gets shoved into the connection.
This looks like an innocuous connection to notblocked.com.  In order to block such a proxy, the censor would have to block all possible notblocked.coms.  But we could install this on, say, the Trans-Eurasian Fiberoptic cable, which was built in part by Soros Foundation.

TEST DEPLOYMENT

CURRENT STATUS
Scaling to ISP line speeds (up to 10 gbps)
Looking to deploy to small-scale ISP

SOCIAL MIRRORING
How do you connect mirrors and folks with censored content?
Mash it up with Reddit, and have community of hosters decide what gets hosted.
Can also do this by crawling file sharing sites.  There is a proof of concept out there.  See mirrorparty.org