Zero knowledge proof of equality Alice and Bob each secretly chooses an integer between 1 and 10, a and b. They want to know (with high probability) whether or not a equals b, without revealing any other information. Can they?
 A: In typical mathematician fashion, let me explain how to reduce your problem to a harder one ☺, namely homomorphic encryption.  (Edit: I should have made it clear that the problem of constructing homomorphic encryption schemes, at least to the extent required here, is indeed solved.)
Assume Charlie is an "honest but curious" third party (i.e., Charlie can be trusted to perform computations honestly but should not be allowed to know $a$ or $b$): I hope it is not unreasonable to assume the existence of Charlie.  Alice and Bob ask Charlie to set up a homomorphic encryption scheme and give them the public key.  Alice and Bob each encrypt their integer using this public key, and share the (encrypted) result, but don't give it to Charlie.  They then use the homomorphic properties of the scheme to compute the (encrypted) value of the "if $a=b$ then $1$ else $0$" function (as a boolean function, this does not require a large number of bit multiplications, so the homomorphic properties required are not too difficult to obtain).  Both can perform the computation.  They send the result to Charlie for decryption, and Charlie can return the result.  Thus, at the end, Alice, Bob and Charlie each know whether $a=b$ but not what the numbers are except those they themselves chose.
Edit 2: as per Pace Nielsen's comment, I should have clarified that this kind of encryption is non-determinististic: there isn't just one cyphertext for each of the values from 1 to 10, there are a huge number, and neither Alice nor Bob can decrypt the other's value by simply trying out all possibilities.
Of course, this leaves a lot of questions unanswered, like whether we can arrange for Charlie not to know whether $a=b$, or do without Charlie altogether (probably something can be done with functional encryption or homomorphic encryption with a secret key that is split between Alice and Bob, but there are usually lots of honesty assumptions that might not be obvious).  Perhaps more insidiously, I don't know how to make sure that Alice does not select a number outside the allowed range (a number that would essentially return "no" to any comparison with a number honestly chosen by Bob).
A: This partial answer is from an information theoretic perspective: This cannot be done with small number of rounds of talking. Suppose the players receive a number between 1 and $n$ and they want to know the answer with probability $1-\epsilon$. If the number of rounds in their conversation is smaller than $\log^*\min\{n, 1/\epsilon\}$, some extra information reveal must happen. This follows from [arXiv:1304.1217], though the reduction needs some explaining. Here $\log^*$ is the iterated logarithm function.
When an unbounded number of rounds is allowed, equality can be determined with probability 1 by revealing a very small amount of information (independent on $n$). Good thing about 0 information is it is 0 no matter how we measure it, but for non-zero information we need to specify how we measure it.
There is a fixed protocol P such that for any $(a,b)\in [n]\times[n]$ the parties learn whether $a=b$ with probability 1 and
for any distribution $\mu$ on $[n]\times[n]$, if $(A,B)\sim \mu$,
$$ I(A;\Pi\,|\, B) + I(B;\Pi\,|\,A) < 4.5, $$
where $\Pi$ is a random variable denoting their conversation.
This protocol is from ECCC:TR11-123, Proposition 3.21.
A: You are asking the socialist millionaire problem. There are several solutions to the problem, amongst them the one showed on the Wikipedia page, using the Diffie–Hellman-Merkle key exchange for secure multiparty computation.
The table describing it is a bit hard to copy into mathoverflow, but you can have a look at the protocol diagram:

A: I believe this task can be solved without the need for an "honest but curious third party" so long as Alice and Bob commit to performing the following full protocol:
Alice and Bob share a large prime number $p > 5$ and compute $a^\prime = a^p\,\mathrm{mod}\,10$ and $b^\prime = b^p\,\mathrm{mod}\,10$, respectively.  Their resulting numbers will be equal if and only if their original numbers were equal, i.e., $a^\prime = b^\prime$ if and only if $a = b$.  Then they run Yao's secure multi-party protocol for the Millionaires' problem twice, to test first if $a^\prime \geq b^\prime$ and if $b^\prime \geq a^\prime$.  (No other information is revealed through this protocol.)  If the answer to both questions is yes, then $a^\prime = b^\prime$ and hence $a = b$.  If the answer is no to one of these questions, then $a^\prime > b^\prime$ or $b^\prime > a^\prime$ and hence $a \neq b$.  Because of the prime exponentiation, neither party can tell whether $a > b$ or $b > a$.
A: (EDIT: Since the sample space is so small Alice would just be able to retry 1..10 and crack this)
As a software developer this is how I would try solve the problem:
Alice and Bob each hash their numbers with something like scrypt; then
they send each other the resultant hash.
They try and rehash their numbers using the scrypt check function; if the check passes then they have the same number.
Details:
Scrypt generates a random salt then hashes the number + the salt then reshashes that X times (X is configurable but == a lot) [Or something like that]
Alice will have generated a different salt than Bob.
The hash from scrypt includes the random salt and number of hashing rounds
Alice using her number, bobs salt and number of rounds can re run the hash algorithm; if she gets the same resultant hash then the numbers (are very probably*) the same. Bob can do the same.
FYI this is how how passwords "should" be stored in a data base.
* There could be a hash collision, but that is very unlikely.
