Search Mailing List Archives
[liberationtech] Internet blackout
michael at briarproject.org
Fri Jun 14 12:12:15 PDT 2013
-----BEGIN PGP SIGNED MESSAGE-----
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
...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. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the liberationtech