On Sunday 21 Jul 2013 22:32:51 Robert Hailey wrote:
> 
> On 2013/07/21 (Jul), at 1:55 PM, Matthew Toseland wrote:
> 
> > Would you pay to join opennet? Bear in mind that a paid system could have 
> > an interesting level of security - not quite up to that of a real darknet, 
> > but most attacks would be *far* more expensive.
> 
> What an intriguing question!
> 
> <rambling type="incoherent-yet-related thoughts">
> 
> My first thought is to the theory itself... surly the primary interest is to 
> dissuade an attack, as it seems a bit shady for a 3rd party to charge for 
> communication between two persons; I suppose you're buying a token 
> certificate: "<ID> has paid" signed freenet-central.

Right. In the short run we need the money to finish Freenet. In the medium 
term, I'd expect most of it to go to e.g. the EFF (or a charity chosen from a 
short carefully vetted list). In the long run, I'd hope that we don't need 
this, because we'll have darknet. 

The objective is simply to make creating an identity more costly. This makes a 
lot of attacks harder: Sybil, connect to every node, but also announcing to a 
target location.
> 
> My second thought is the actual cost/benefit... if an attacker is going to 
> drop a lot of cash on servers/bandwidth/hosting to monitor freenet, what is 
> another $1k for a bunch of identities, or $10k? Can we make them so expensive 
> that one cannot effectively perform a sybil attack, and yet so cheap that an 
> average user would not really hesitate to buy one?

This is the problem with paranoia: People just have no idea what the relative 
cost of different attacks is!

Bear in mind that we average less than 3KB/sec/connection. Bandwidth is very 
cheap in bulk. Servers are cheap too, and for a big network you can hire geeks 
to optimise things further. Sybil is cheap. And it gets cheaper per user as the 
network gets bigger.

We can improve on this by requiring that nodes maintain a certain bandwidth 
level, but there's no point if creating a new identity is free.
> 
> For that matter, a longterm eavesdropper might even have a budget ($1k/month 
> for freenet identities), which if they don't expire would mean they might 
> have little effect (without additional checks, such as IP address range, 
> "bulk" purchases, etc).
> 
> I wonder if the "bottleneck" can really be money, as a powerful attacker is 
> presumed to have plenty of money=power... is their money really more scarce 
> than their ip addresses [that they can dedicate to freenet]? 

IP addresses are cheap, even with the current scarcity. On IPv6, IP addresses 
are *VERY* cheap.

If you assume that your attacker is all-powerful, then of course they're going 
to win. However, it may be possible to deter attackers with a budget under some 
limited value.

> .... what do they not have much of? human time? "friends"? "people you have 
> met"? I guess that's getting back to darknet :-/

Exactly. And there's some doubt about how practical that is with a small 
network, even with much more user friendly means of setting up connections, and 
even building one sub-community at a time. Mostly because of the "I didn't know 
you were a paedophile" effect: People will be reluctant to invite their friends 
until Freenet is much bigger.
> 
> ...and I guess if the registrar tracked ip addresses (even to locate sybil 
> networks) the same database could be a liability (list of freenet users).

Of course we need to track IP addresses. But it's not enough IMHO.
> 
> Can we get the same effect by adding webcall that fetches a free opennet 
> certificate? "You have no darknet peers, if you would like to connect to the 
> opennet click here to make a non-anonymous web request." The bottleneck might 
> then be the issuing server, but it's still a scarce resource: i.e. getting 
> 1000's of opennet certs, maybe with a hash-cash-CRAM :-).

Hashcash and CAPTCHAs are not usable solutions either. They are both very cheap 
in bulk: GPUs and bulk CAPTCHA solving services. But they're a major deterrent 
for a significant fraction of users.
> 
> When trying to imagine myself as a new Freenet user, I would expect that the 
> purchase be [reasonably] anonymous [like in bitcoins].

Again, this is misdirected paranoia, which is one of the major enemies of 
Freenet! :) Downloading Freenet is not anonymous. Announcing through the 
seednodes is not anonymous. On opennet, the fact that you are running Freenet 
can be assumed to be public knowledge. You *can* be anonymous and invisible on 
darknet, within reason.
> 
> The purchase mechanism is probably expected to be automated & low-latency, 
> but is there something to be gained if we place a human in this 
> opennet-cert-purchasing workflow? Mail a SASE & $1 to <physical address>, and 
> and we'll send you back an opennet cert (on paper? a usb drive?).

Of course we'd support bitcoin etc. Although how anonymous bitcoin is is a 
debatable point. Using a human increases costs, so you'd have to charge more 
for cash-by-mail stuff. Also bear in mind that cash-by-mail is problematic: It 
tends to go missing, and it can be unclear whose fault that is. There are 
handling precautions that can reduce that though.
> 
> But we need anonymous onboarding, right? Different level of opennet certs?

Transient vs core. I mentioned this in my long term roadmap proposal.

If you don't want to pay, or can't meet the minimum bandwidth requirements, you 
can run a transient node. This has less anonymity and is slower, and it doesn't 
route traffic. On the upside it's ideal for e.g. mobile access, and it's still 
able to use tunneling (but with less confidence in the keys).
> 
> How does this relate to seednodes? Can we encourage running a seednode by 
> making it gather bitcoin micro-payments? I guess an attacker would first, 
> then, start running a seed node :-(

The top layer is the bootstrap nodes. These are the central point of failure, 
like seednodes are today (we'll have more seednodes by automatic harvesting). 
They act collaboratively. There are 2 operations: creating a certificate 
(requires payment) and renewing a certificate for a new IP address. Creating a 
certificate involves all the bootstrap nodes in a collaborative random number 
generation algorithm, so we get a random location. Tying it to an IP address 
involves more than one bootstrap node to validate the IP address. Either way 
your cert includes a sufficient set of signatures from the current bootstrap 
nodes: One sig from the node that handles payment, and enough sigs from the 
current set of others.

Conceivably more than one bootstrap node could require payment, but that's a 
longer term issue.
> 
> So does it have to be "centralized"? It would certainly be easier... If not 
> seed nodes, what if all nodes that can reach <anchorNodeX> by a darknet-only 
> request can generate opennet certs.

No, it has to be centralised AFAICS. Just like opennet is already centralised. 
And there can't be a market in introduction services either: Anywhere where a 
paid anonymising service is provided on a competitive market, and where an 
attacker can trace stuff as long as they own a large enough proportion of the 
nodes, and where it's not easy to identify who's running the service, the 
attacker can always win cheaply by taking a tiny loss. The market rewards this 
because it's what it optimises for - privacy is unfortunately not a visible 
commodity here. This is a problem for e.g. mixnet services; it's why e.g. 
bitcoin mixers need to use blind coins.
> 
> </rambling>
> 
> To answer your question... I have no idea, we really need a solid theoretical 
> basis first (what are we trying to solve & how). :-(
> 
> Well I take that back... I *DO* have an idea, but it involves 
> free-space-optics hardware and georouting; and I doubt that "making opennet 
> secure" translates to "buy custom hardware", so I'll squelch that part of the 
> ramblings. :)

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to