From: Frank O'Dwyer (fod@brd.ie)
Date: Mon Feb 28 2000 - 06:12:42 PST
Hi,
I tried to kick off a similar project a while back, but unfortunately havent
had much time to pursue it since. See http://www.brd.ie/tcq/ - it sketches
some ideas for a decentralised anonymous chat network which could underpin
something like you are describing.
Cheers,
Frank O'Dwyer.
> -----Original Message-----
> From: owner-cryptography@c2.net [mailto:owner-cryptography@c2.net]On
> Behalf Of Eugene Leitl
> Sent: Monday, February 28, 2000 7:14 AM
> To: Carey Lening
> Cc: Jeff Bone; FoRK; cryptography@c2.net
> Subject: Re: Napster - the quiet revolution
>
>
>
> I haven't had the opportunity to try Napster yet (upgrade to glibc is
> way overdue). Everybody is raving about it, though, so it is probably
> very good.
>
> It seems however, that Napster suffers from a few design flaws:
> centralism (there is a central database, right?); it seems to produce
> cleartext traffic in certain patterns on a certain port (otherwise the
> protocol wouldn't have been reverse engineered so quickly and it would
> not be so easily detectable/blockable, as recently happening in
> certain university networks striving to conserve bandwidth). Is this
> correct?
>
> It would have been nice to to be able to run the global title index
> via a distributed database (no single point of failure, e.g. due to
> unfriendly legal action), which establishes connects through
> addresspace searches of nearby (in terms of number of hops and/or
> bandwidth) nodes, and sending something very much resembling a SSL
> connection as created by a vanilla secure browser session, both in in
> regards to used protocol and traffic pattern. Scanning for/blocking
> Napster traffic would so become much more difficult. An obvious
> problem is how to avoid collision with vanilla https (other than
> intercepting/redirecting https://aaa.bbb.ccc.ddd/napster/
> traffic. Perhaps just using https on a different port would be a
> smarter idea, though usage of a nonstandard port is bound to draw
> closer scrutiny).
>
> A moderate connectivity (say, ~10), with each node acting as a relay,
> would allow each node to reach any other node within just a few hops
> over the virtual network. Caching the index of titles stored directly
> on these nodes could probably reduce the traffic quite a bit. A
> top-100 list and related-list (users who downloaded this title also
> downloaded the following titles, ranked by total downloads) would seem
> to greatly increase program functionality.
>
> It would seem to be necessary to limit the scope of visibility to
> direct neighbours only, to prevent malicious users from obtaining
> extensive lists of other Napster users' addresses. To increase
> obfuscation, introducing some traffic mixing should be contemplated,
> injecting pseudorandom garbage traffic between direct neighbours to
> foil statistical traffic attacks.</paranoia>
>
> The program should be capable of serving arbitrary types of digital
> content.
>
> The rationale is to sneak code into a widely used utility which would
> create an infrastructure for secure anonymous peer to peer
> communication, content sharing and digital payments (let's call it
> CryptNet) on top of insecure, increasingly monitored/filtered public
> networks.
>
> Comments?
>
> -- Eugene
>
This archive was generated by hypermail 2b29 : Mon Feb 28 2000 - 06:15:46 PST