On 09/04/14 23:09, Matthew Toseland wrote: > On 01/04/14 20:10, Matthew Toseland wrote: >> On 01/04/14 19:12, Matthew Toseland wrote: >>> On the other hand, it may be possible to improve opennet's stability, >>> and to persist our list of "established" peers across restarts of both >>> sides within reason. If we can get it to the point where good nodes >>> require their peers to have been connected almost continually for a week >>> plus, >> Sorry, to clarify: "Good nodes" (high uptime nodes) ideally would >> require their "established" peers to have been connected for a week plus >> to maintain their "established" status. They can of course have peers >> which are not "established"; those peers don't receive high HTL requests. >>> then this would help significantly, and it could have interesting >>> performance properties too, e.g. it might allow us to use Bloom filter >>> sharing on opennet. >>> >>> Note also that *we need this sort of structure for tunnels anyway*: For >>> both security and performance we need nodes that participate in tunnels >>> to be reasonably fast and reliable. >> So, priorities for security: >> 1. Force opennet nodes to not change location. >> - Opennet nodes don't change location at present; a hybrid node doesn't >> swap. >> - Drop opennet peers with prejudice if they change their location. >> 2. Identify "established" opennet peers and only route high HTL requests >> to them (and darknet peers). >> - This makes "fast MAST" much harder, paves the way for tunnels and some >> interesting performance optimisations. >> - (Possibly longer term) Try to persist "established" status across >> restarts on both sides, within limits. > One serious problem with this: If you get a HTL 18 request from a node > that is not likely to be a core opennet node, what do you conclude? :( > > So maybe we need to wait until we have tunnels ... on the other hand if > you're directly connected to the target, you can usually identify what > it's doing anyway ... ??? In particular, consider the connect-to-everyone attack: If Mallory connects to every node (he needs ~ 1% of the network, all of which need to be core nodes), and the target happens to be non-core, then he can *IMMEDIATELY* identify the target, Bob, when Bob sends an identifiable, high HTL insert to him - because he doesn't route high HTL requests for other nodes!
Whereas in any other case he'd need to do statistical analysis and/or add more connections to promising nodes. Which is still terrible. So it's a bit faster once he's got his core nodes. On the other hand he has to pay time and resources to get core nodes, so it will cost him more to get the same number of connections.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
