1
$\begingroup$

With all the NSA stuff in the news, I've been thinking about how to ensure the "who's talking to who" is just as private as the contents of the messages. I had an idea on the subject, about which I've got two questions: the first, does this concept work (i.e. meet its stated objectives); and if so, what services employ this technique.

The problem: how to ensure that the "who" is just as private as the "what" of communication

The idea:

  • There exists a voluntary network of nodes that all have public key encryption systems, and published public keys.
  • The sender sends a message to the first intermediate node, encrypted with that intermediate node's public key.
  • The first intermediate node decrypts the message, which contains the second intermediate node's address and a payload that's encrypted with the second intermediate node's public key. The first intermediate note sends the payload to the second intermediate node.
  • The second intermediate node decrypts the message, which contains the third intermediate node's address and a payload that's encrypted with the third intermediate node's public key. The second intermediate note sends the payload to the third intermediate node.
  • The third intermediate node decrypts the message, which contains the final recipients node's address and a payload that's encrypted with the final recipients's public key. The third intermediate note sends the payload to the final recipient.
  • The final recipient decrypts the message.

Key points about this system:

  • the sender needs the public keys of all intermediate nodes (a published database would be needed of addresses and public keys)
  • I was originally thinking of this in respect of email, but it should work with any communication, e.g. snail mail, IP packets, etc
  • on a computer it should be fairly easy to automate the multiple layers of encryption
  • the number of nodes can be manually selected, or selected at random
  • the nodes themselves should be selected at random
  • the communication could contain multiple next-hop nodes with a priority order, in case nodes fail. The nodes could provide an acknowledgement message back to the node they received communication from
  • the messages could potentially be randomly padded to ensure that the reducing size of the message over time (as address headers are removed) does not give a clue to the communication direction
  • random communication could be added to the network to further confuse snoopers
  • to prove the source of the correspondence to the sender, the sender and recipient would need to pre-agree a secret that the sender would include in the message. Alternatively, the entire system could be set up such that each node gives a unique secret to each other node encrypted using that node's public key. This would establish encrypted relationships by default, without the need for pre-agreeing, and wouldn't allow anyone to infer relationships from the establishment of the original secret

Challenges:

  • as the network scales, the database of addresses and public keys becomes potentially too large
  • if the secret sharing mentioned in the key points is employed, the number of secrets each node would need to hold could get prohibitively large if the network gets large
$\endgroup$
1
$\begingroup$

Like @StephenTouset said

You appear to be reinventing the concept of onion routing.

For a practical example, check the Tor Project (based on the Onion Routing program) which enables online anonymity and directs internet traffic through a worldwide network consisting of thousands of relays to conceal a user's location… which would cover most of what you need.

But there are other implementations out there too; most of them handling encrypted, anonymous data (voice, text, binary) transfers using random node allocations and bridging.

Besides that, it is worth diving into mixnets too.

For more, the anonymity bibliography might come handy as an orientation for further research.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.