1
$\begingroup$

I'm new to cyptography, so I apologize if this is a dumb/impossible goal or has already been answered (I was not able to find it by searching).

I wish to devise an anonymous protocol for transferring digital goods, where the message contents are publicly viewable, but neither sender nor recipient can be determined from the message contents alone.

Additionally, once the sender has transferred the goods to the recipient, he should not have the ability to resend the same goods again to another recipient. Only the initial recipient should have that ability (i.e. a recipient should obtain sole ownership of the goods once transferred).

The goods may change hands many times, and ownership should be publicly provable at the time of a transfer without revealing the identity of the sender or recipient.

My initial design is for all users in the system to generate their own public/ private keys and a transport (for Diffie-Hellman exchanges). A user's public identity would consist of their public key and transport.

When a sender wants to transfer goods, he first generates new random public/ private keys and transport (not his publicly known values, in order to obscure the fact that he is the sender). He uses these in a Diffie-Hellman exchange with the recipient's publicly known values to generate a shared secret. This shared secret is used as a salt to generate a specific public/private key pair. The sender also generates a completely random public/private key pair.

The sender uses the specific public key to encrypt the random private key. This encrypted value is included in the message contents, along with both public keys and the generated transport. The message contents also contain a random number, and that number encrypted with the specific public key.

The sender also adds the hash of a previous message which was used to transfer ownership of the goods to him originally. The sender then signs the message using the private key that was encrypted in that previous message.

Users in the network listen to messages, and attempt to recreate the shared secret from the public key and transport included in each message, using it as a salt to recreate the specific public/private key pairs. If the specific private key decrypts the correct random number, then a user comes to know that he is the intended recipient. He can then use the specific private key to decrypt the random private key, which he can now use to prove he has ownership of the goods.

The problem with this strategy of course, is that both the sender and recipient have access to the key used to prove ownership, and this would allow the sender to transfer the goods to additional recipients (i.e. the original recipient does not have sole ownership of the goods). Are there some additional cryptographic measures that could be added to this process to prevent the original sender from re-sending the goods? Or am I heading down a dead-end path and need a better strategy?

$\endgroup$
  • 1
    $\begingroup$ once the sender has transferred the goods to the recipient, he should not have the ability to resend the same goods again to another recipient - this is the double spending problem that is addressed by bitcoin/blockchain technology. $\endgroup$ – Ella Rose Jan 24 '18 at 0:27
  • $\begingroup$ But with bitcoin, the recipient of a transaction is publicly known, and therefore ownership is easy to verify. How might blockchain technology be used to address the "double spending problem" in a protocol where both sender and recipient should not be publicly known? $\endgroup$ – Paul Lamb Jan 24 '18 at 3:33
  • $\begingroup$ I don't know - I provided the link to the double spending problem not as an answer, but as a comment on something that you can search on. $\endgroup$ – Ella Rose Jan 24 '18 at 4:05
  • $\begingroup$ Thanks, Ella, that has let me to secret sharing which may be the key. If the system can bring in one or more third parties besides the sender and receiver, then shares of the secret could be available to the receiver which the sender is not aware of. $\endgroup$ – Paul Lamb Jan 24 '18 at 11:42
0
$\begingroup$

After some thought, I have devised one possible solution to the problem (I am definitely open to other ideas too).

Rather than proof of ownership being used solely for the purpose of a subsequent transfer, instead there can be an additional step added to the process whereby the recipient claims ownership of the goods. The system would not allow multiple claims of ownership for the same transfer request -- only the first claim would be validated, and subsequent claims rejected. Any time goods are transferred, both proof of ownership and proof of claim would be required.

Once a recipient identifies that he is the recipient of the goods (using the process I outlined above), he would broadcast his intent to claim ownership of the goods. At this time, he would use the encrypted random private key to verify that he is the intended recipient, and generate a new random public/private key pair. He would broadcast the new public key as part of his claim, and use the private key to later prove that he claimed ownership of the goods.

Of course, the sender would also have the ability to broadcast a valid claim of ownership after broadcasting the original transfer message (because sender and recipient are both obscured), but that is not a problem as long as the system only validates one claim. If the sender uses this to reclaim ownership, then the recipient will know that he has not received the goods and can respond accordingly.

This basically allows the sender one opportunity to change his mind before he relinquishes ownership of the goods. It also allows the sender to reclaim his goods if he accidentally sent them to the wrong address, or if the recipient does not respond in some reasonable amount of time. So definitely seems to be positive feature of the system.

| improve this answer | |
$\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.