1

INTRODUCTION

First of all, I'm a beginner in RSA mechanisms and similar but I'm really interested in knowing if this is possible.

In this scenario, I organized a party where certain people receive a special invitation voucher I made with my private key. They will later use it to enter and I will check if it is valid with a public key.

On the begining let's suppose the voucher has someone's ID and the voucher ID "signed" below by a private key. By this mean, I can ensure THIS person will enter with THAT entrance ID.

MAIN PART

But now I want this vouchers to be transferable in OFFLINE mode with some sort of program. So now it would consist of two blocks; the second one ensures the ticket IS the one. And the first block, would contain the actual holder of the voucher:

.............................................. BLOCK 1

ACTUAL HOLDER DATA

SIGNATURE OF THIS BLOCK

.............................................. BLOCK 2

ORIGINAL HOLDER

VOUCHER ID

SIGNATURE OF THIS BLOCK

..............................................

I provide the first invitee with his own private key, so he can modify the first block to change the ACTUAL HOLDER DATA in virtue of the new person he transfered the voucher to. When he/she does this, he also provides the private key to the new person.

THE FLAW

If (let's call him) Mallory makes a copy of his voucher before he transfers it to Alice correctly, he would be ALSO able to enter to my party although Alice should be the only one capable of entering. And so, the number of invitees could be infinite.

My question is simple, how can I disable Mallory's voucher?

Option 1 would be to make the transaction online and add to a server which acknowledges that Alice is the new owner of THAT voucher. Otherwise I need a mechanism to make the old voucher obsolete, unless anyone proposes something better.

Improve this question
8
  • If someone else can modify the message, then you don't have control of it, plain and simple. Either trust everyone who can modify the message, or don't trust anyone.
    – Ghedipunk
    Dec 12, 2019 at 23:52
  • @J.Francis - Names aren't completely unique identifiers in the first place. What's to prevent two people with the same name from sharing a copy of the original voucher? What's to prevent me from making a copy of the original voucher (byte-for-byte), making your "expected" copy, and then just showing up at the party before the other guy - do you let us both in, reject their entry, or eject me? Or, given the current scheme, making multiple legitimate copies, given the onus is on me to "forget" the original key.
    – Clockwork-Muse
    Dec 12, 2019 at 23:57
  • @Ghedipunk I want them to be able to edit the part of the message containing the actual holder so it can be transferred. The other part shouldn’t as it is protected by MY private key, and not the invitee’s key
    – John
    Dec 13, 2019 at 1:13
  • @Clockwork-Muse I was looking for something like name and ID. There must be no more than 1 voucher with the same voucher_id. If both come to the party at the same time, one of both is illegitimate and should not enter, but I’ve found no way to solve that, and it’s my main concern
    – John
    Dec 13, 2019 at 1:19
  • The problem is that any random sequence of bits is infinitely copyable. The only way to prevent copying is to not hand out the bits, period. Game companies have spent millions or billions of dollars on essentially this problem, and have yet to succeed (long term). Your best bet is to use a server you control.
    – Clockwork-Muse
    Dec 13, 2019 at 17:32

3 Answers 3

Reset to default
1

You cannot do it offline.

This kind of problem is solved on blockchain solution by using consensus (on permissionless blockchains) or a centralized database (on permissioned ones). Otherwise, I could receive 5 FakeCoins from someone, and give them to 10 people, multiplying the coins. By using a consensus algorithm, this multiplication is not possible: the second time I try to transfer 5 FakeCoins, the network would detect that I don't own that amount anymore and ignore the transfer. On permissioned blockchains, the validation server would do the same.

Back to your problem: you need a validation server. The same server that issues tokens can be used to validate the token transfer. If Alice receives one token, and transfers it to Bob, your server must sign the transfer somewhere on the block, and record the transfer on a internal record. Later, if Mallory managed to get Alice's transfer transaction and tries to transfer the token to itself, your server will not accept the transaction (because that token from Alice has already been transferred and she has no ownership of it) and will not sign it.

The endpoints validating the use of the token does not need to talk to your server, they only need the public key of it. They can validate your server signature, and allow or not the person depending on it.

Improve this answer
0

What is the problem you're trying to solve here?

Do you only want only specific people to enter? Just don't allow transferring of the vouchers offline. Issue a new voucher and revoke the old one via another mechanism if a person asks their voucher to be transferred.

Do you want the vouchers to be transferable? Just don't store the name on the voucher, and allow anyone with a signed ID to enter.

If you're giving a private key to someone, you're doing something very wrong.

Improve this answer
1
  • I’m looking for a way to prevent the multiplication of vouchers. I can give the voucher to A and he can transfer it to B. I want this transfer to be done in such way that me or my system don’t need to interact with them. If I don’t have the name of that person, he can get his voucher stolen and any other person may enter without the permission of one of my invitees. Was it clear? I’m on hold for any other question
    – John
    Dec 12, 2019 at 23:47
0

Solution

Every user could have a RSA keypair. The public keys should be known to you at least at the time of the event. So the old owner could sign the new owner's public key together with the current timestamp. If you use this the right way, you should be able to know who is the legit owner.

Problem

But this doesn't prevent selling the voucher multiple times, only using it. Furthermore, the old owner could sign with a fake key. In order to prevent that you could allow transactions only if the old user made their public key public to the server and was signed by the server.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .