Is there a cryptographic algorithm that can make a "lottery ticket"?

Question

With public-key cryptography, I know Alice can "seal" a message that only Bob can open. But in that case, Alice knows the message that she is sealing.

What if Alice wants to seal a random number which she doesn't know? Could she seal it such that only Bob can determine it, not Alice?

Here, more specifically, is the kind of situation I'm wondering about:
Say the random number is from a uniform distribution 1 through 10. Alice seals an envelope containing the random number, without knowing what it is. While she doesn't know the number, she can be sure that it is one of the options 1-10 with uniform probability. Bob (and only Bob) can unseal it, and he can be sure that he's the only person who can. So when he opens it, he knows he is the first and only person to see what random number was generated by Alice. Then he can tell Alice what he got. And provide verification, so that Alice is then able to verify that Bob is being truthful about the number he claimed he got.

Bob should have cryptographic assurance that:

1. He was the first to "scratch off" (identify) the randomly generated number.
2. The number was fairly generated from the [1..10] uniform distribution.

Is such a cryptographic algorithm known or possible?

---

EDIT: Thank you for all the helpful discussion and feedback!

To take this question one step further: is there a way that Alice can prepare and send the "ticket" to Bob using only one message?

Meaning, basically: Can Alice prepare such a ticket using only Bob's public key?

Or, more exactly: Alice, in preparing the ticket to send to Bob, can use Bob's public key, or other previously known information -- but she can generate multiple different tickets to send without needing Bob to contact her each time a new one is generated. Only one packet -- the one from Alice to Bob, would be needed to send Bob one ticket.

Is an algorithm possible to create the "lottery ticket" with this additional "single-packet" limitation?

Answer 1

Bob picks an integer $n$ between 0 and 9 (inclusive), and a uniformly random 128-bit blinding factor $b$. Bob informs Alice of the hash commitment $c=H(n \mathbin\| b)$. $H()$ is a cryptographically secure hash, such as SHA256. $n$ and $b$ should be represented in fixed-bit-length form inside the hash concatenation.

Alice picks a uniformly random integer $n'$ between 0 and 9 (inclusive). She informs Bob of $n'$.

Bob can now calculate his lottery ticket value as $v = 1 + ((n+n') \operatorname{mod} 10)$.

When Bob wishes to announce $v$, he also needs to announce his values $n$ and $b$ so that the world can verify that those values match his commitment $c$.

If Alice only knows Bob's public key and cannot wait for Bob to provide a commitment:

Bob has the (private, public) EC key pair $(b, B=bG)$, where $G$ is a well-known base point.

Alice picks a uniformly random 128-bit integer $s$, and informs Bob of $s$.

Bob calculates $X=bH_p(s)$, where $H_p()$ means to hash the input and interpret the result as an EC point. This means that the private key $x$ such that $X=xG$ is unknowable.

Bob calculates $t=H_4(X \mathbin\| i)$, where $i$ is a 128-bit number initially set to the value zero and $H_4()$ means to truncate the result of a cryptographically secure hash to 4 bits. He then uses rejection sampling to determine his lottery ticket $v$ as follows:

If $0\leq t\leq 9$, Bob determines $v=t+1$. Otherwise, he increments $i$ and tries again. Bob must accept the first value of $t$ that is in the required range, and Alice will be able to check he has done so.

When Bob is ready to announce his lottery ticket $v$, he needs to announce $X$ and provide a discrete-log-equivalence proof demonstrating that the point $X$ on the base point $H_p(s)$ shares the same private key $b$ as Bob's public key $B$ on the base point $G$. This proves that $X$ was calculated correctly.

The construction $X=bH_p(s)$ is known as a verifiable pseudo-random function (VPRF). It allows Alice to choose the input of a PRF that only Bob will be able to perform, and for which Bob will be able to provide proof that he has performed the PRF correctly.

Note that Bob must check that Alice has not provided the same seed $s$ twice, as this would allow Alice to cause Bob to receive the same lottery ticket value again in the future.

Answer 2

The primitive you are looking for is called a (two-party) coin-flipping protocol: an interactive, two-party protocol which allows two players to sample a random number without being able to bias the outcome.

The other answers have described some classical examples of coin-flipping protocols over a ring $\mathbb{Z}_n$: each party picks a random number from the prescribed set and commits to it; then, both parties open the commitment, and the sum of the numbers over $\mathbb{Z}_n$ is the result.

An important point of caution, though: the above protocol is fine if you apply it in a context where the protocol will be ran only once and there is no point in aborting (terminating early) the protocol. The point is the following: often, when we define a coin-flipping protocol, we can envision using it in many different runs of larger protocols. But with the above protocol, one of the party can see the outcome before the other party, and decide to terminate the protocol if he is not happy with the result.

Think of it as follow: we run many protocols online which start with a coin-flipping. Everytime, Bob sees the result first, and Bob gains an advantage if the outcome is odd. Then Bob could simply decide to abort the protocol whenever the outcome is even (claiming, e.g., a network failure). This would effectively bias the outcome of the protocol, when we condition on successful termination, and provide Bob an unfair advantage in any successful execution.

There is an important area of cryptography that deals precisely with this problem, which is called fair coin flipping. The short version is:

• It is provably impossible to remove all bias - one of the parties will always be able to gain some advantage by terminating early
• You can do much better than the above protocol, though, and reduce the bias to $O(1/\sqrt{r})$ (assuming one-way functions) or even $1/r$ (assuming public-key cryptography) using a protocol with $r$-rounds.
• There are some converse results as well (showing these assumptions are necessary)
• You can do better in the quantum setting (this result is provably optimal)
• You can partially circumvent this issue by using timed commitments or other related notions.

Answer 3

1. Bob generates a random number, hashes it with a cryptographically secure algorithm, and gives the hash to Alice
2. Alice also generates a random number and sends her number to Bob
3. Bob takes his number and XORs it with Alice's number. The resulting number is the lottery ticket. Because neither party knows what number the other party generated, neither party could have predicted the result.
4. Bob sends his random number to Alice. Now Alice can verify Bob's hash to confirm that he did not change his number after receiving the number from Alice. The ticket is now known to both parties.

Answer 4

Encrypted data and signatures should be virtually indistinguishable from random bits. If they are not, then there is likely a vulnerability in the algorithm. So I'm ignoring that and assuming an algorithm that generates signatures that are for all intents and purposes random bits that can't be associated with the incoming data without knowing the key.

1. Alice provides Bob some random data and a set of rules
2. Bob signs the random data with his public key and applies the rules to the signature to get the number. At this point, Bob is the only person that knows what the signature looks like and therefore what the number is.
3. Later Bob can provide the signature to Alice, and Alice can use Bob's public key to verify the signature was applied to the exact data that Alice provided, and use the rules she provided to calculate the number.

Any power of 2, such as 1-8 or 1-16, is uniformly possible. Let's say a signature is 1024 bits. Alice may provide the rules 'Look bits 57-60 for a 4 bit number from 0-15'.

1-10 is not exactly possible, but can be closely approximated. The rules could be that Bob should treat the entire signature as a 1024 bit unsigned integer and take the value mod 10 to get 0-9. Some digits will be very slightly more likely than others, but the difference is so small that you can ignore it for practical purposes. The decimal numbers 0-6 would occur 1797693134862315907729305190789024733617976978942358629823994724593847971630483535632962422413721 times and the numbers 7-9 would only occur one fewer times.