[liberationtech] eternity USENET (Re: Internet blackout)

[Adam Back]

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.

http://cypherspace.org/adam/eternity/

There's an old Phrack article describing it in more detail and a howto, and
the software.

Adam

On Fri, Jun 14, 2013 at 08:12:15PM +0100, Michael Rogers wrote:
>-----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-----
>--
>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