#### [table of contents]

To do general secure computation, we will of course need to do more than secure addition. It turns out that the secret sharing scheme from the previous subsection already allows us to do more: we can also do secure multiplication.

Suppose two numbers have been secret shared as described above, so that and , and we wish to compute the product securely. We obviously have

.

It is now easy to see that if the ‘s and ‘s have been distributed as described above, it is the case that for each product , there is at least one player among the three who knows and and therefore can compute . For instance, has been given and can therefore compute and . The situation is, therefore, that the desired result is the sum of some numbers where each summand can be computed by at least one of the players. But now we are essentially done, since from **Secure Addition**, we already know how to add securely!

The protocol resulting from these observations is shown below. To argue why it works, one first notes that correctness, namely , follows trivially from the above. To show that nothing except is revealed, one notes that nothing new about is revealed in the first step, and because **Secure Addition** is private, nothing except the sum of the inputs is revealed in the last step, and this sum always equals .

**Secure Multiplication**

Participants are , input for is , input for is , where is a fixed prime agreed upon in advance. has no input.

- distributes shares of , while distributes shares of .
- locally computes , computes , and computes .
- The players use
**Secure Addition**to compute the sum securely, where uses as input.

It is interesting to note that even in a very simple case where both and are either or , secure multiplication has a meaningful application: consider two parties Alice and Bob. Suppose Alice is wondering whether Bob wants to go out with her, and also Bob is asking himself if Alice is interested in him. They would very much like to find out if there is mutual interest, but without running the risk of the embarrassment that would result if for instance Bob just tells Alice that he is interested, only to find that Alice turns him down. The problem can be solved if we let Alice choose where if she is interested in Bob and otherwise. In the same way, Bob chooses to be or . Then we compute the function *securely*. It is clear that the result is if and only if there is mutual interest. But on the other hand if, for instance, Alice is not interested, she will choose $a=0$ and in this case she learns *nothing new* from the protocol. To see why, notice that security of the protocol implies that the only (possibly) new information Alice will learn is the result . But she already knows that result will be ! In particular, she does not learn whether Bob was interested or not, so Bob is safe from embarrassment. By a symmetric argument, this is of course also the case for Alice.

This argument assumes, of course, that both players choose their inputs honestly according to their real interests. In the following section we discuss what happens if players do not follow the instructions and what we can do about the problems resulting from this.

From **Secure Multiplication**, we see that if Alice and Bob play the roles of and , respectively, they just need to find a third party to help them, to do the multiplication securely. Note that this third party is not a *completely trusted* third party of the kind we discussed before: he does not learn anything about or other than . Alice and Bob do have to trust, however, that the third party does not share his information with Bob or with Alice.

It is an obvious question whether one can do secure multiplication such that *only* Alice and Bob have to be involved? The answer turns out to be yes, but then information theoretic security. Instead one has to use solutions based on cryptography. Such solutions can always be broken if one party has enough computing power, but on the other hand, this is an issue with virtually all the cryptographic techniques we use in practice.

For completeness, we remark that Alice and Bob’s problem is a special case of the so-called match-making problem which has somewhat more serious applications than secure dating. Consider a set of companies where each company has a set of other companies it would prefer to do business with. Now we want that each pair of companies finds out whether there is mutual interest, but without forcing companies to reveal their strategy by announcing their interests in public.

Next we will investigate how to design protocols which remain secure even if some parties try to cheat in the protocols, i.e., we ask the question What if Players Do Not Follow Instructions?