It might be possible to do a mostly-distributed revalidation protocol, i.e. avoid having to contact the bootstrap/seednodes regularly, but still limit nodes and connections per IP address to make Sybil more expensive...
Re: Would you pay to join opennet? From: toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI Date: Monday 22 Jul 2013 14:32:04 Groups: freenet Followup-To: freenet Message was signed by Matthew John Toseland (2010-2015 key) <[email protected]> (Key ID: 0x75941D88). The signature is valid, but the key's validity is unknown. Public@yfAQXNfkUI3g5ghjRoRTMm2s2J8DBM9WuKJYqtkfTXc wrote: > toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> sonny@L3O94oWz6k~8A0dVG0jpJc55ohubTtp4RHGIVdyGBqw wrote: >> >>> toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote : >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> 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. >>>> >>>> When I say pay, I mean pay once, to create a node. You can then stay on >>>> opennet for as long as you like. >>>> >>>> And there'd be a fallback: Transient mode. Less anonymity, but it could >>>> still use tunnels. Significantly less performance. What paying to join >>>> opennet gets you (along with having some specified amount of bandwidth >>>> per peer), is the ability to be part of the *backbone*, i.e. the >>>> storage network. Hopefully the network would be somewhat faster because >>>> of the bandwidth requirements. And it would have proper tunnels. >>>> >>>> Straw poll, but thoughts welcome. Some of the technical details spelled >>>> out on the 1.0 proposal (http://piratepad.net/TQYpA3SDu7). No idea re >>>> legal issues. >>>> >>>> Existing users would likely be grandfathered in, for a limited period >>>> and subject to the same bandwidth requirements (and IP address >>>> requirements). >>> >>> Nope! I can't afford it, second it kills my anonymity! >> >> How so? The fact that you are running Freenet (assuming it's opennet and >> you use the seednodes to bootstrap, or download it from the website), >> usually isn't anonymous. >> >> Also I didn't specify a price; if people are willing to pay $1 rather >> than $100 that would be useful information. >> - -- >> This FMS identity is not secure, it is run on my behalf by a friend. I >> will sign anything important. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iEYEAREIAAYFAlHsV6kACgkQYUNbc3WUHYjn2ACfUcxHdMrusjAyk/UgkMSSCzgC >> 6O4AoK09NyccAi0q+N/mwD7WkVPaz9vf >> =xxsP >> -----END PGP SIGNATURE----- >> > There could be lots of ways to pay. > > If the recent DefCon estimate that freenet has only about 32T storage > that's abysmal for a distributed storage network of 10000+ nodes. I have a > hard time believing it's that low but with the move to laptops, pad and > phones it could be. People running a node 24/7 with 500G+ storage and good > bandwidth or even low bandwidth these days might be a rarity. Maybe look > at storage, bandwidth and uptime to promote good transient to core. I > think that's more valuable that a couple of bucks. > > Right now take out the seed nodes and opennet dies slowly over days and > maybe weeks. With the proposal take out meganodes and all the seednodes > and core nodes have a 24 hour death sentence and opennet is no more, a > quicker collapse. It leaves things where you always wanted it darknet > only, or scattered disconnected darknets. DoS'ing the seednodes prevents nodes from joining opennet if they are not currently connected. Lets ignore the question of payment for now and talk about IP address scarcity: Currently: - Right now, the seednodes individually limit announcements per IP address per 24 hour period. Relatively easy: - Seednodes should connect to each other and broadcast who is announcing, and thus collectively limit announcements per IP address per day. - Seednodes should include the location as well, and limit the number of locations that can be used by an IP address in one day. (E.g. to 2, so we allow one reinstall). Harder: - To announce through seednodes, you need a certificate. This is created by the bootstrap nodes (seednodes), and includes a random location chosen by them. - The certificate also includes your IP address, so you need to revalidate it centrally every time it changes. When your IP address changes you will usually need to reannounce anyway, so this isn't really any different to the current situation. - We can ensure that no one node can connect to more than N other nodes by asking it to give us a collision-detecting SSK to insert (based on its node key) listing its peers at a specific point in time, like PISCES does. - Preventing an attacker from manufacturing Sybil nodes via path folding: We require a certificate to be an opennet connection. - Preventing an attacker from announcing on lots of IPs (e.g. via repeatedly resetting their modem) and then reusing them all at once on one IP: The certificate includes our IP address, and has to be revalidated when it changes, even if we don't reannounce. The simplest way to revalidate it is to talk to a bootstrap node. The bootstrap node could check not only that the node has access to that IP, but also limit the number of nodes that can use it. Normally we will have to reannounce when our IP changes, so this centralised involvement isn't any more than happens now. - Do we need to periodically revalidate even when the IP address doesn't change? If we don't, then a node gains the right to use an IP if it has ever used that IP - which could be months ago, so you could create a large number of nodes on a single IP address over time and then use all of them at once. - A distributed revalidation protocol would be possible, e.g. we choose a set of random port-forwarded nodes and give them the (cryptographic) right to renew the node's certificate, and to post to some global IP+time -> node list lookup space concerning that node only. -- Note that this involves SSKs with complex validation rules - PSKs, but with a global blacklist which is maintained on every node. DoS attacks against such a blacklist should not be possible as each set of validators is created by the bootstrap node. A similar mechanism is used by PISCES. -- Node connects to the validators, thus proving that it is the node they are supposed to be validating, and that it has access to the IP address. -- Node sends a certificate proving that it wants access to the given IP address at a given time (which is quantised). Certificate is wrapped with the signatures of the validators and the original signed cert from the bootstrap node allowing them to insert to the IP+time -> node lookup -> IP certificate. -- Validators all insert the IP certificate to the IP:time -> node lookup space. -- Validators all insert the IP certificate to another space (PSK, SSK with special rules), which corresponds to their right to validate the node (i.e. the IP address is not part of it). -- If there is no collision on the IP certificate, validators renew the node's certificate. -- If there is a collision on the IP certificate, the validators fetch the validation certificate for the existing user (the malicious set of validators), from the per-validator SSK mentioned above. If this doesn't exist, it can be inserted, since we have the full cert. If it does exist and is different to the collided IP certificate, this is proof that the validators that inserted to that IP address are malicious. We broadcast or insert the proof, the global validation blacklist is updated, and everyone moves to a new key (that is, future inserts will be checked against the blacklist). The malicious validating nodes' own certificates are no longer valid because they are on the blacklist, so they get disconnected, as well as no longer being validators. (Note that this means that we need to be careful with status, backups and timekeeping, but this should be a solvable problem). Hence one set of validators can only block 1 IP address in a given time slot; and to become validators, they need to be online, have another IP bootstrapping, and be randomly chosen by the bootstrap node, via its peers (surrounding the bootstrap node may be an option; long random routes starting on a large hybrid darknet would help with that). Unfortunately we can't check whether the node is online, because it may not be. As you can see, the distributed validation solution is a lot more complex than the centralised one. It makes it possible for existing opennet nodes to persist and change their IP address even if the bootstrap nodes are down, provided that their own validators/seednodes are up - bootstrap nodes are only needed for new nodes. It's more robust than the current situation. The catch is, it's also more work, more complex, and probably has subtle flaws. Given that right now almost every opennet node needs to contact the seednodes periodically when it's had some downtime or when its IP address changes, it may make sense to implement the centralised solution first. -- This FMS identity is not secure, it is run on my behalf by a friend. I will sign anything important. End of signed message
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
