[liberationtech] Introduction --- Haystack

[Bram Cohen]

> Expansion is horrible. In some early code, it's a factor of 5 or so.
> That's one reason we want to keep performance very good in other areas
> and another reason we're looking at HTTP optimization research. (I keep
> wanting to say "ciphertext expansion", but this isn't ciphertext per se.
> Can you think of a better term?).

Stegotext.

The vast majority of web traffic is compressed already, so I doubt you'll get 
much in the way of bandwidth optimization.

I think you're taking CPU load way too seriously (as in the case of sha1 vs. 
sha2) way too seriously, and bandwidth costs (as in blowing up client traffic by 
5x and adding end nodes) nowhere near seriously enough. Bandwidth costs real 
money at scale, and blowup to the end user also causes extremely noticeable 
performance problems to end users, which can cause them to not use the tool at 
all.

There are a lot of problems with making stegoed http not trivially detectable. 
For starters, you have to put something down for the Host: line, and that has to 
vaguely reasonably correspond to DNS entries. The alternate approach of using 
SSL/TLS on port 443 is both simpler and clearly brings considerable obfuscation 
benefit. You could even be ahead of everybody else and use Firefox's client SSL 
negotiation code and Apache's server SSL negotiation code, which would be 
maximally hard to distinguish from the real thing, because it would be the real 
thing, and also save a bunch of work.

> > How do you plan to block a malicious web site from grabbing info about the 
> > client's IP address? For example, a flash applet can look up the local 
>machine 
>
> > IP and communicate that back.
>
> This falls under "user education and software mitigation". All software
> of this type has that problem. There's really very little we can do.

There are a fair number of things which torbutton does to block such leaks. You 
can't just pass this one off as a user education problem, because malicious web 
sites can get IPs in ways which no end user could be expected to expect, or has 
any way of doing anything about short of installing torbutton.

> Something we've considered is distributing bootable media containing a
> pre-secured web browsing environment that would solve this problem and
> some other ones besides.

That's a good idea, but doesn't solve the leaking IPs problem.

> > Why do you have client authentication? 
>
> It seemed like a good idea to verify that the client has a valid
> signature created by us. I couldn't think of any downsides.

The downsides of having to generate and track those keys, and make custom 
installs, are not to be taken lightly. You don't even have a minimal userbase 
right now, adding in unnecessary features isn't such a hot idea.

> True. We made a decision long ago that it's better to limit the
> information an attacker could learn about the network than to make the
> software more convenient to use in some sense. We're certainly willing
> to revise the trade-off given the right argument.

That's unfortunate. The demo I saw had usability as a major strong suit.

> You can arrange things such that you can't extract a meaningful
> message without some kind of key (as in chaffing and winnowing) but
> hiding the existence of the message, especially in a stream that's not
> supposed to be statistically random to start with, is a lot harder.

Depending on how random the cover traffic is and how lousy a bitrate you're 
willing to accept, it's possible to do that quite well. In practice the bitrate 
issue is a really big one though. If you search for 'wet paper codes 
steganography' you'll find some stuff giving the basic info.

> Regardless, seeding with /dev/random at least gives you actual, real,
> and true randomness as far as the system can muster. A CSPRNG with a
> large period seeded with true randomness might as well be truly random.
> /dev/urandom just returns a best guess when it runs out of entropy, and
> we don't control that guessing.

/dev/urandom has a CSPRNG built in. If you don't trust it, it's fine to roll 
your own, and I can tell you how to do one based on AES. You shouldn't use 
mersenne twister though - that one has good statistical properties but isn't 
cryptographically secure.