Sorry, on re-read I noticed you want to use the *private* key to generate A. Forgeddaboutit.
This just raises another risk: you're making public extra info related somehow to your private key, which if you're not extra careful can be a big fail. Bart Polot On 29 November 2012 20:14, Bart Polot <bart.po...@gmail.com> wrote: > Another problem I see is: if you are using K as a seed to generate a > consistent set A, it could be possible to just collect a large set of > HELLOs "B" and see if any Ki in B generates a large subset of B. Then the > Ki must be real and all the generated HELLOs, fake, and you are busted. > > Bart Polot > > > On 29 November 2012 19:53, Christian Grothoff <groth...@in.tum.de> wrote: > >> On 24 November 2012 13:56, LRN <lrn1...@gmail.com >> >>> <mailto:lrn1...@gmail.com>> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> This is the idea that i've been thinking on. >>> It should be possible for GNUnet node operator to hide the fact that >>> his machine runs a GNUnet node. >>> >>> Ways to achieve this: >>> >>> 1) Fake HELLO messages. >>> AFAIU, right now anyone can collect HELLO messages (by running a >>> node, >>> or by querying a hostlist server), and then claim (with certain >>> degree >>> of sureness) that GNUnet nodes run on all addresses listed in these >>> messages. Companies that track torrent users do this for BitTorrent. >>> They may then proceed to actually connect to listed addresses to >>> verify them, but that is quite another story. >>> The solution is to spread fake HELLOs with fake public keys and fake >>> addresses. >>> A node should use its private key (key K) as a seed to generate a set >>> fake of addresses (set A). Then use K and A themselves to generate >>> fake public key (key F) for each A, thus getting a complete HELLO >>> message. The use of K as a seed ensures that the node will keep lying >>> about the same set of addresses (how large that set should be is an >>> open question) with the same keys, making the fakes more believable >>> (observer might think that these are real nodes, maintaining their >>> real HELLOs over time; failure to validate any of them might be >>> blamed >>> on firewalls, etc). >>> Address sets will intersect (A1 and A2 generated from K1 and K2 may >>> share some elements), obviously, although that might not be true for >>> IPv6 addresses... >>> I expect that address generator will apply some rules to generate >>> believable addresses (i.e. don't generate invalid IP addresses, like >>> 10.1.0.255). >>> As an extra, a node could validate generated addresses and do >>> non-agressive portscanning (or something similar - we're not speaking >>> only of tcp) on them, to be able to add ports (or other parts of the >>> address) that look believable to observers. >>> >>> AFAIU, right now nodes won't gossip about fake HELLOs (i.e. a node >>> will never tell another node about a HELLO it got, unless it >>> validated >>> that HELLO). That might need to be changed to allow nodes to choose a >>> random subset of invalid HELLOs and gossip about them as well. >>> Otherwise only the node that generated them will be able to spread >>> them. >>> Not sure about hostlists. >>> >>> Extra yummy feature - add user-configurable fake templates, which >>> could have addresses only, or addresses and private keys. GNUnet node >>> will use templates from time to time (configurable) instead of >>> generated addresses, and will generate missing template elements. >>> It would be neat to be able to tell the world that 65.55.58.201 [1] >>> runs a GNUnet http_server transport on port 80... >>> >> >> This is also too complex >> >>> >>> >> ______________________________**_________________ >> GNUnet-developers mailing list >> GNUnet-developers@gnu.org >> https://lists.gnu.org/mailman/**listinfo/gnunet-developers<https://lists.gnu.org/mailman/listinfo/gnunet-developers> >> > >
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
