Assuming an attacker that can do mobile attacker source tracing but not global attacks, which is true 1) on darknet, and 2) on opennet if the attacker has limited budget and the network is large: - We encrypt all the CHKs below the top block randomly. - We use an SSK for the top block, and make sure that there are multiple CHKs immediately below it (for reliability).
An SSK consists of a nearly 1KB pubkey, 100 bytes of headers and a 1KB data payload. We can therefore use very expensive onion routing with a very low actual overhead: We route through 3 nodes, which are roughly speaking globally random. The reason for them being globally random is to satisfy the 2 basic criteria for mixnets: 1. The selection of this node, our predecessor or our successor must not give us a lot of information about the originator. 2. The exit node must not be able to tell that it is close to the originator. It could be far away or near, the set of possible originators must be very large. We obtain each node via a rendezvous tunnel: We send out 3 "anchor" requests, initially routed randomly and then to a random key specified by the originator, and each one routed through a different original peer. When the anchor requests converge a shared secret scheme establishes a connection, and we return an acknowledgement down the shortest anchor connection. The actual insert is encrypted onion-style to the three nodes and sent between them by routing to the node's location (possibly including its previous few locations and some sort of globally unique ID e.g. the hash of the pubkey). We do not expect a response. We allow a fairly high latency on each hop to provide mixing and hence resistance to traffic analysis and some resistance to traffic labelling attacks. So it's similar to Mixmaster. It can be attacked by not doing the insert. One solution to this is to subscribe to the key ourselves: For a WoT, chat or messaging application, we will be subscribed to the key. For a freesite or other predictable key, likewise there is nothing unusual about fetching the key. If we don't see it in a reasonable time we can send another insert, through different nodes. Alternatively we can insert down 2 or 3 paths at once. Even if we have to insert down 3 paths, and even if it takes 7 hops for each route, because the payload is so small, this is not a big deal: 2KB (unfortunately we will need to include the pubkey since it's encrypted) * 3 (we are using 3 paths) * 3 (O -> A, A -> B, B -> C; 3 nodes) * 7 (hops at each point) Gives 126KB. Which is actually not all that much. 42KB for one path (assuming we reinsert if we don't see it; there is some risk in this), 84KB for two paths. The main difficulty is what happens if an attacker's nodes just swallow the insert and never relay it - either as one of the chosen nodes or one of the nodes along the path. But the effectiveness of such an attack is only linear. We can completely prevent traffic labelling by not expecting any feedback and creating a new tunnel for each request. On the other hand, this combined with the number of nodes involved results in a large number of predecessor samples. But without traffic labellng these predecessor samples are worthless unless all the nodes are conspiring or the flow can be identified. So, provided we can limit it to *SSK inserts*, and provided the attacker doesn't have sufficient penetration to block inserts (they would need approx 1 in 21 nodes, 1 in 7 if we use 3 tunnels), we can have an effective onion routing system for the parts that need to be onion routed. For CHK inserts, it would be possible but rather expensive, possibly infeasibly so. For requests we need a reply so would have to be more conventional - long lived tunnels, worrying about predecessor samples, it'd be a different system, and it'd be expensive, probably infeasibly so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110223/299f6e39/attachment.pgp>
