Search Mailing List Archives
[liberationtech] eternity USENET (Re: Internet blackout)
adam at cypherspace.org
Fri Jun 14 12:22:38 PDT 2013
Kind of old now (1997) but take a look at USENET eternity for a distributed
censor resistant web publishing system based on USENET, PGP and
hashes/committments. The documents could either by public, semi-private
(secret URLs) or secured. Content updateble only by the author using PGP,
and yet browseable from a web browser with the plugin. The whole thing was
a perl script, but you may find the approaches interesting.
There's an old Phrack article describing it in more detail and a howto, and
On Fri, Jun 14, 2013 at 08:12:15PM +0100, Michael Rogers wrote:
>-----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-----
>Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
More information about the liberationtech