http://wiki.freenetproject.org/PreTunneling
Is this of any interest? Is it practical? Would it provide any real anonymity? ----------------- Proposal: PreTunneling The protocol is not really premix routing, because it lacks onion encryption and source routing. So an adversary would directly route requests to his siblings. On the other hand the adversary does not get any advantage by pretending to be many nodes. There is no defined anonymity set. However the protocol still makes correlation attacks a lot harder. The tunnels are bidirectional and end-to-end encrypted to some other node. Messages are authenticated in every node by a public key. Both ends use the same private key. 1) Node Alice wants to set up a tunnel to some unknown node that will be named Bob. In order to send a secret to him, she creates two requests that reveal it, when they are combined. She sends both to the same random destination. The two requests are called tunnel request and decryption request. The route of the tunnel request will determine the route of the tunnel. Alice simply routes the tunnel request to an appropriate neighbour, as if she were just propagating it. The decryption request is send to some other neighbour or better through an existing tunnel, if available. The protocol forbids sending tunnel requests through tunnels, because they would either lead to longer and longer tunnels or provide an adversary with short-cuts to the decryption request path. 2) Eventually both requests meet in one or two nodes. If there are two, then the one upstream on the tunnel request path will win. Or if they are on different branches, then the one that first reaches their common root will win. For better security the first few nodes on the decryption request path should reject a corresponding tunnel request pretending that they detected a loop in the tunnel request path. Alice probably wants the final tunnel to be shorter by a certain number of nodes, in order to decrease latency, make the tunnel more reliable and reduce overhead for the network. This instruction is found in her secret message. The node that is reached by propagating the message upstream is named Bob. (If the number that Alice has chosen is too large, then she will receive her own message and the tunnel set-up fails.) 3) Alices message is also part of a Diffie-Hellman key exchange. Bob completes it. He uses the new secret key for generating an asymmetric key pair. The asymmetric cipher just has to be hard enough not be broken during the life time of the tunnel. Bob sends the public key and his part of the DH key exchange to Alice. He authenticates his message to Alice using the old secret key from Alices message. The nodes in the tunnel save the public key in order to authenticate later messages. Other upstream messages are accepted by nodes after they have seen the first valid downstream message. Authentication on every node is necessary in order to prevent a malicious tunnel node from inserting fake messages for traffic analysis. 3) Alice verifies Bobs messages and generates the new symetric key. She also uses it for generating the common private key. 4) Alice can send local requests (and maybe remote decryption requests) through the encrypted tunnel, and Bob will send back the results. The nodes in the tunnel prevent replay attacks. Alice should try to route local requests to their closest tunnel as often as possible. However she must make sure that she does not become vulnerable to correlation attacks using traffic analysis of her tunnels. -------------- 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/20070518/7b3a28de/attachment.pgp>
