2

I have a protocol I am designing that requires anonymity and privacy. My idea is to have a minimum number of hops in the network before the message can be sent to its intended destination. The response can then somehow be encrypted such that only the original asker can understand. To maintain privacy, each hop only knows its last hop in the route and the minimum hops is random allowing for nodes to maintain anonymity even from the closest hop.

For instance I have a protocol I already know won't work and is why I am here asking for suggestions:

Bob sends a message with a set number of hops before it can go to its intended target, it has the targets name/id, and it has a public key specifically created for talking to the target (these keys can also be thrown away). Bob sends this message through several hops until the minimum hop count is decremented to one. Each hop remembers only the last hop that the request came from and decrements the hop count. Once the last hop sees a count of 0 it forwards the request to the intended target. The target now encrypts the data with the associated key on the message and responds back through all of the hops until bob gets it. Only bob can read the message and only bob knows he is the last hop.

I am aware that any point in the chain can replace the key with their own so that when the data comes back it gets to peek at it before encrypting it with the original key and then forwarding back towards bob. What can fix this flaw/how can I allow encryption and anonymity?

Tyler Scott
  • 121
  • 3
  • How are you managing the navigation, selection, and routing of the hops? What does the "hopping" add to the security of the message? If Bob uses the target's public key, how could a node in the chain replace it? How are you hoping to improve on the basic TLS protocol? – schroeder Apr 18 '15 at 02:38
  • 5
    This sounds like you're trying to reimplement Tor. You should just use Tor. – cpast Apr 18 '15 at 02:42
  • 3
    I think that you are trying to battle different problems on different layers of the communication stack. You need to separate those problems and deal with them differently. Perhaps you need to explain what problem you are trying to solve? – schroeder Apr 18 '15 at 02:48
  • The idea of encrypting with a peers public key for some reason didn't occur to me as I figured the sender would need to ask for it, but my network could be built to compensate for that. – Tyler Scott Apr 18 '15 at 03:22
  • @schroeder, the hops are designed to prevent any nodes form knowing who is asking for some portion of data. As for the other aspects of the network, most of the nodes are managed via a dht, I think that I might end up using I2P to handle all of my routing for me. – Tyler Scott Apr 18 '15 at 03:24
  • 1
    Portion of data? You'll be needing to handle fragmentation, too? I think you have too many undisclosed requirements and you have not explained what problem you are trying to solve. I also think that since you used the terms 'dht' and I2P, that there are existing solutions to solve the 'hide the network flow' problem in the I2P space. – schroeder Apr 18 '15 at 04:40

0 Answers0