On Sat, 29 Apr 2000, hal at finney.org wrote: <snip> > It would be useful against an attacker who wanted to see what data someone > was downloading and was eavesdropping on his line. Client encryption of > node data only goes so far; there has to be some way of guessing the key > and if the client can do it, the eavesdropper may be able to do so as well > (especially if he saw the client download a web page with a Freenet link > that included the key).
If the trailing field is not encrypted a second time, then a school or ISP or whatever could simply build a database of one ciphertext block of all popular freenet documents, and sniff the traffic for those. This provides a general attack against Freenet's existence on that network, which is a bigger problem then localizing suspected nodes and performing active man-in-the-middle attacks against them one at a time. > Without authentication though the system is still vulnerable to active > attacks, someone who can act as a "man in the middle" and meddle > with the key agreement protocol. Or, as Oskar says, they can simply > join the Freenet as a node and get some information from there about > who is requesting what data. (This part presumably works even with > authentication.) The real security threat is the boxing in. If the NSA can convince you that you are part of Freenet, when actually they have taken over all the connections, then they can monitor everything you request, and you would never be the wiser because the spoof it to make it look like your node is speaking to a whole bunch of others. The first model that comes to mind to fight this would be: A fingerprint of a nodes Public Key is always passed with it's address, and then the whole Public Key can be retrieved via a HandshakeRequest. So then you would start your node knowing one trusted node and it's fingerprint (you got this from some trusted channel). You start making requests, and with the replies you get DataSource addresses, together with fingerprints of their PKs. When you start making requests for those nodes, you make sure that the Public key they send back is validated by the fingerprint. This would make the fake node attack very difficult, because if they don't control the references that your first trusted node sends back, they can't pretend to be those nodes either, so they would have to make sure that they actually got the requests and could reset the DataSource themselves to use NSAs keys, but that is the same as being able to catch all your inserts from the beginning. It becomes sort of viral. If you know one node that the attacker can't pretend to be, then that will send you references to more nodes that the attacker can't pretend to be, and so on. > This gives me an idea for an interesting attack: someone wants to know > who is downloading some notorious, sensitive data file, like the article > about how Cubans should be free to emigrate. They run a node which > creates some bogus articles which hash to be close to the target one, > by exhaustive search. It then submits them into the network, making > itself a data source for hashes similar to the target. This will tend > to lure requests for the data, or inserts for it as well, towards itself. > Does this work? There is an issue here, because a DataInsert right now provides you with a way to get a reference to yourself with a key you yourself can decide. This reference is not going to be as "strong" as had you replied with data, because it get's reset after the first node, but it is still something. Personally I would prefer if the DataInsert set the reference up the stream, a DataSource could be passed down with the InsertReply and reset with at each step with some random probability, just like it is passed with the DataReply on DataRequests today. Since the InsertReply precedes the DataInsert, that would work. The problem is that that means a node needs a new way of announcing it's own presence to the network (and don't say Inform pages). I'm not sure if the current one of making an insert is good enough anyways, as it assumes that you are inserting something (not every node operator will have new data insert when he starts a new node) and possibly even that that data is interesting enough to request so that the reference will live long enough for the new node to actually get any DataRequests it can reset the DataSource of. If anybody has an idea, I am all ears. > > Hal > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
