[guardian-dev] [Cryptography] traffic analysis

[grarpamp]

On Tue, Jan 27, 2015 at 3:23 PM, Ben Laurie <benl at google.com> wrote:
> Yeah, but ... who can realistically afford that bandwidth?

One can afford what they wish to give to and thus expect to get from
the network in return, no more, no less, as always. (Be it literally
from the physical  NIC network, or the logical networks created by
their applications riding over and within the physical.)

> To every possible recipient? Clearly you have to make a tradeoff.

Full meshing of chaff addressed to all participants seems unnecessary.

> grarpamp wrote:
> Is there so much (possibly far less than correct) thought out there
> that fill bandwidth is evil, untolerable, unmanageable, and blocking
> of usability such that these networks are moot to even try coding
> for general deployment?

On Tue, Jan 27, 2015 at 1:35 PM, Jerry Leichter <leichter at lrw.com> wrote:
> Google Fiber offers 1Gb/second - but how many customers running all
> out will overload any possible backbone behind the single link from the
> house to the concentrator?
>
> If everyone starts sending constant cover traffic, links will be quickly
> overloaded all over the place. At which point the providers will start
> charging [...] nobody will be happy

That's the simple man's kneejerk response when initially contemplating
chaffed networks.

> There's room to do much better.  For one thing, you don't need to saturate your link with cover traffic - you need to send enough cover traffic so that a listener can't tell the difference between cover and real traffic.

This depends on if you're network is a low latency one, or if it
uses a store and forward model. Even that is tricky due to
needs to hide the size of data each endpoint exchanges from
passive adversaries. It begins to approach constant higher
rate the more you data wish to pass securely.

> If your cover traffic rate equals your average rate over some period of time,
> you're not adding more traffic - you're simply replacing some of your cover
> messages with real messages.  But ... what happens when you have a
> peak demand way above your average?

Then you must wait until you can pass your wheat. Or plan your
needs according to the give and get model.

> As Stealthmonger has commented concerning anonymity, if you want
> security against traffic analysis, you have to accept delays:  Set your
> cover traffic rate somewhat higher than your average rate, and you'll
> *eventually* catch up with peaks (though as with any queueing system,
> the delays can grow without bound - requiring unbounded memory
> *somewhere*).

Delays (trading latency) are not the only way to achieve security.
You may also elect to trade available throughput bandwidth in a
wheat/chaff system.

> I'm not aware of any open research on these kinds of questions - though
> it may well be out there.  What's the optimum cover traffic rate under
> various assumptions about the real traffic rate and distribution?  When
> is it safe to use the traffic other users present as cover for your own?
> Clearly if there's only one other user sending traffic, you can't use him
> for cover as *he* can tell which of the packets are yours.  But is there a
> way to mix traffic from multiple users in a way that requires large numbers
> of them to conspire to reveal anything?  The mixmaster stuff looks at this
> specifically from the point of view of a store-and-forward node - is there
> some suitable useful analogue on a single link?  Can we somehow get
> the same guarantees without storage inside the network?

There were some research references posted in the threads below.

> we're now going to have to change our attitudes toward traffic analysis.

Yes, a lot of oppurtunity exists to create new working networks
in this area that utilize fill traffic and/or delay.


You may want to review the recent guardian-dev and tor-dev side
threads below on this exact subject of link padding, latency and
analysis. Relavent papers and talk have been posted.

https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004040.html
https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004069.html
https://lists.torproject.org/pipermail/tor-dev/2014-November/007741.html
https://lists.torproject.org/pipermail/tor-dev/2014-December/007934.html
https://lists.torproject.org/pipermail/tor-dev/2015-January/008039.html
http://www.metzdowd.com/pipermail/cryptography/2015-January/024479.html
https://lists.torproject.org/pipermail/tor-dev/2015-January/008099.html

[Copied a few places simply to include these ongoing links as
reference for anyone interested.]