[liberationtech] Internet blackout

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/06/13 12:49, Rich Kulawiec wrote:
> I think a *possible* fix for it -- or perhaps "fix" is too strong a
> term, let me call it an "approach" -- is to remove the Path: header
> (among others) and use the article body's checksum as a unique
> identifier.  Thus node A, instead of telling node B "I have article
> 123456, do you want it?", would say instead, "I have an article
> with checksum 0x83FDE1, do you want it?" -- slightly complicating
> propagation, but not unduly so. I think this can be used to strip
> out all origination information: when A presents B with articles, B
> will not be able to discern which originated on A and which are
> merely being passed on by A.

This was exactly my jumping-off point for Briar: take Usenet, remove
the path header, remove cancellation messages, require message IDs to
be cryptographic hashes of the content, and require link encryption. :-)

> Encrypting everything should stop article spoofing.  (Although it 
> doesn't stop article flooding, and an adversary could try to
> overwhelm the network by injecting large amounts of traffic.
> Deprecating the Path: header actually makes this easier for an
> attacker.)

...and this is the point where I decided Usenet wasn't the best place
to start from. Spam pretty much killed conversation on Usenet - and
the spammers weren't even trying to kill it.

I have some ideas about how to limit spam/flooding in a decentralised
way, if we can assume the network's built on real-world social
relationships and some fraction of the users are willing to take part
in moderation - but so far they're untested.

> What all this does *not* give a real-time communications medium. 
> But I'm not at all sure that's desirable.  Over the past few
> years, I've slowly formed the hypothesis that the closer to
> real-time network communications are, the more susceptible they are
> to (adversarial) analysis.  I can't rigorously defend that -- like
> I said, it's just a hypothesis -- but if it's correct, then it
> would be a good idea, when and where possible, to make
> communications NON-real-time.

I agree - if you design the system to tolerate latency, there's scope
for using mix network-like techniques against traffic analysis. Many
attacks against mix networks are based on correlating messages
entering the network with messages leaving it; if the network's
peer-to-peer then messages don't enter or leave - the endpoints are
inside the network. And if the network uses store-and-forward, senders
and recipients don't have to be online at the same time, further
frustrating intersection attacks. But best of all, store-and-forward
networks can include nodes and edges that don't show up in the
adversary's traffic logs at all, because they only communicate over
sneakernet or short-range links like Bluetooth and wifi.

> I'm not saying this is "the" answer.  I'm not even sure it's "an" 
> answer.  But I think it might be the foundation for one.  Now if I
> could just find the funding to work on it for 6-12 months I'd be
> all set. ;-)

Come and work on Briar. We might even be able to find some funding. :-)

Cheers,
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRu2sPAAoJEBEET9GfxSfMWR8H/AtxcA41sgvmY1HW3EwDN0/w
z8LFbrYvimL/CI34eWvytzKU8on/GyS4nBhJ0PRW7KbBpDm9SKEpi83jXoBDNvrN
Ix4hM5dMdNp1dTZB8rI7NEWWOcpR/ChMfEHkV/EDtAZiQX3fzeC1rX3kx0PaqOne
a0SRjIxXF/wrfqNN405vvTT6POjI6AEKwHomNdb6mZLsW8X16F7ejn8vpFwkOHQ6
Q4manS2FzVMVb4VmbmjFmrAJqhAaSTxziYbxosJqXqGiy9bugAlcJ14KmE97k4rG
rqwM2wjSwiSJ9vdytbPE6Dmav3hpwKyyyytYxzIDvZcN2z4kJ01h42Izah0qsxo=
=jCtk
-----END PGP SIGNATURE-----