Consequences for ULPRs and passive requests: When the top block is inserted, ULPRs can tell us immediately. We download the top block. That tells us the keys of the second layer. However, if we bust nodes in the right areas, they will not tell us anything about it, at least not from their ULPR data structures, because those structures are deleted when the data is found. (Obviously as with many places in the node it is possible that there are un-garbage-collected remnants...)
On the other hand, can ULPR data structures tell us anything about a request? Well, ULPRs, in the current half-finished implementation, record the nodes that requested the key, the time at which they requested it (so they can expire), the boot IDs of the nodes at the time (so they can be dumped if the node restarts), the nodes we routed the requests to, their locations, boot IDs and times (so we can reject requests when the key has already been routed to the best node for it). If an attacker can bust a bunch of nodes that were involved in a request, he may be able to use this to try to trace the key's requestors. However, if the key is found, he has nothing, since it is forwarded and the ULPR structures are deleted (except the UID of the request, which will tell him whether or not a node participated in a specific request; this is essential to prevent loops). So against an attacker that can compromise nodes at will (while not necessarily owning all of them at any one time), ULPRs may enable him to trace previous unsuccessful requests. However, this only makes a difference for hit-and-run inserts: If there is any sort of ongoing anything, he can simply compromise nodes, plant whatever logging is needed, and wait. And then only if he is not able to permanently compromise a large fraction of the network in preparation for needing to do a trace. Most of the above data is vital afaics. We could eliminate the requestor part of it by offering any newly found data to ALL of our peers, but in the short term this would definitely make the situation worse for local attackers. In the long term, we probably will go in this direction: publishing Bloom filters for the data in our store to our trusted darknet peers for a few hops (even for one hop) would be a significant optimisation, and announcing the key to all our peers when we find data is essentially that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071220/8ef7e9a1/attachment.pgp>
