[freenet-chat] Re: [Tech] Caching issues was Re: Migration path, please! (Re: [freenet-support] Freenet 0, 5 and 0, 7

[Matthew Toseland]

From Frost:
----- Anonymous ----- 2006.08.30 - 20:33:35GMT -----
Right now there is a 100% chance to find out if a single request was
local or not due to store probing. If all local request were cached you
wouldn't be able to tell if a single request was local or not because a
store probe would always succeed without telling you if that key was
requested locally or by a remote peer. Thus you would have to either
seize the store or probe for a lot of different keys which both would
only tell you that the node has cached x keys of splitfile y without any
100% security that these keys all really were requested locally (and not
from a single peer of that node that had only one connection working
like a leaf to the attacked node). This is in my eyes already way better
then the situation right now.

You could do some crazy things like not caching local requests while
blocking requests for the key x comming from the node from which you got
key x (it should have cached it anyway) for a certain time but that
would fail as soon as you are connected to two nodes controlled by the
same person and it would require that the block time is around as long
as the maximum lifetime of a key in the local cache. It would be better
then now but I don't know how ressource consuming and complex a
implementation of that idea would be; I imagine that it would require
massive key tables for even a small amount of time.

Another idea which was metnioned some time ago was to store local
requests in a temporary cache but I think that would cause problems if
anyone probes the store before and after a restart of the node.
-------------------------------------------------------------

He's right, I'll make inserts be cached locally for the time being.

On Tue, Aug 29, 2006 at 08:54:04PM +0100, Matthew Toseland wrote:
> On Fri, Aug 25, 2006 at 08:59:23AM -0400, fwolff33 at aol.com wrote:
> >   
> > Juiceman wrote:
> > >With 10 connections, the data that could intercepted by one attacker
> > >is roughly 10%. The problem is the attacker doesn't know how many
> > >connections you have, so you could just be passing on data from any
> > >number of connections you have.
> >  
> > It's currently trivialy easy to find out if a request of a connected peer was forwarded by that peer or if it was a local request from that peer because local requests aren't stored in the datastore/-cache. (http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity, search for the headline "Datastore") Thus you only have to probe the datastore of the requesting peer after sending the data to it and can find out if it was forwarded or originated there. In my opinion this isn't really acceptable on either a dark- or opennet (perhaps on a true darknet but that doesn't exist right now) but it certainly would cause havoc on an opennet.
> 
> This is true (for inserts; requests are cached anyway). The problem is that
> the alternative, caching local inserts, is equally dire; the attack that
> the Register highlighted last year: Anything you insert is 100% in your
> datastore, so if it is seized, or if an attacker makes the requests
> remotely and times them, they can guess what you've been browsing. (As
> on 0.5).
> 
> What do you suggest we do? A "client cache" (temporary cache using
> ephemeral keys) would help slightly. Premix routing would seem to be the
> ultimate solution, but is difficult, and thus not to be implemented
> before 0.8. I have been toying with the idea of some kind of
> non-encrypted semi-permanent tunnels to provide some request security; a
> tunnel would be a random route taken by a whole bunch of requests, or
> even all local requests from a node over a period; it would be randomly
> either forwarded or broken up and the requests routed on each hop. While
> it is being forwarded, the requests aren't cached, and don't check the
> cache. This would provide a small anonymity set, but better than
> nothing.
> -- 
> Matthew J Toseland - toad at amphibian.dyndns.org
> Freenet Project Official Codemonkey - http://freenetproject.org/
> ICTHUS - Nothing is impossible. Our Boss says so.



> _______________________________________________
> Tech mailing list
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-- 
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/chat/attachments/20060831/3c55e700/attachment.pgp