Mesmerizing Chameleon Signatures
By: Steven Yue
Tags: Cryptocurrency, Cryptography, Computer Science, Programming

The Construction — Factoring based

In order to build a Chamaleon Hash Function, we know that we just need to build a Claw-free pair of Trapdoor Permutations. The paper briefly introduced two candidates that have this property. The first one is factoring based.

If you know RSA, then you know that RSA is based on the assumption that it’s very hard to factor a large integer N into two prime factors N = pq .

Here we will use the same idea: We basically set a large integer N = pq where p and q are prime numbers. We set the permutation functions F_0, F_1 to be the following:

F_0(x) = x^2 mod N

F_1(x) = 4x^2 mod N

Pretty simple, right? And actually, assuming that large integer factoring is hard, this is proven to be claw-free!

But what’s the trapdoor to this? The trapdoor is just the knowledge of primes p and q. If you know them, then you can very efficiently compute the square root when inverting them. If you don’t know p and q, then it will be very hard to compute the permutations in the reverse direction.

The Construction — Discrete-log based

If you are familiar with other Crypto algorithms, you should be expecting this section to come.

Whenever we build some generic algorithm, we can always fill in the blank with a set of candidates. Integer factoring being one of them, and the other one is Discrete-log based groups.

I’ll probably write another post about how groups work, but basically it’s like the following:

Imagine if there’s a field of numbers, and all these numbers sit in a ring. If a number goes too high and reaches the max, then it falls back to 0 and starts over again. We call numbers (or generally speaking, elements) that have this property a group.

If you are picturing something like a 32-bit unsigned integer that overflows back to 0, you are on the right track. The simplest group is a finite field of integers. For example, all uint32 values form a group of size 2**32 . There’s also a special notation for a group G with size q : Z_q . Usually, we want this q to be a prime because everything works elegantly when there are prime numbers around.

In every group, we can find some element g that’s called the generator of this group. What it means is that if we repeated multiply this element g by itself, we can obtain every single number in this group. Here we gave a very simple example where generator g = 3 and group size q = 5 .

Group = {0, g, g^2, g^3, ..., g^q}

{0, 3, 3^2 mod 5, 3^3 mod 5, 3^4 mod 5} = {0, 3, 4, 2, 1}

Once we understand these fundamental ideas of how groups work (although there are many more nuances), we can directly use these groups to create Chameleon Hash Functions.

During set up, both parties need to first agree on what group they will be using and they need to fix a generator g of the group. The recipient will randomly sample an element x from the group Z_q . Then he simply sends the generator raised to the order of x — g^x to the signer. We denote this term as y .

So how does the signer create a valid commitment? First, she needs to sample a random nonce r , and then she simply computes:

ChamHash(m,r) = g^m * y^r

Pretty simple construction right? Now we should prove that this scheme is indeed hiding and binding.

Before getting to the proof, we need to take a look at the famous discrete-log assumption: Computational Diffie-Hellman Assumption/CDH.

The CDH assumption stemmed from the Diffie-Hellman key exchange protocol. Basically, it says that performing integer logarithms on group elements is hard. Namely, if we have g and g^x in some good group G , it’s computationally infeasible to get x just by looking at these two given elements. In our case, by looking at the y from the recipient, the signer will have no idea what the random x actually is.

Now let’s see the proof.

Hiding: The hiding property here is actually based on the assumption that if you don’t know the exponents (m, r, x) to the generators, then the output will just look like a random number to you. Because of CDH, one cannot extract any valuable information given the output and the generator.

Binding: This scheme is binding because of CDH. Since the signer has knowledge of the value x , she cannot really produce another pair m', r' that opens the hash commitment. I won’t show the detailed proof here, but basically, if the signer is able to produce such a pair, then she can efficiently recover the original x the signer chose.

Finally, let’s see how would the recipient forge an arbitrary opening. If the recipient wants to open the commitment into a desired bogus message m' , then he will need to produce m', r' that satisfies the following equation:

g^m * h^r = g^m' * h^r'

g^m * (g^x)^r = g^m' * (g^x)^r'

m + xr = m' + xr'

Since the recipient already knows x , he can simply obtain the necessary r' by (m + xr — m')/x .

And now we are done! If you made it through here, you already understand two valid constructions of the Chameleon Hash Function. The next is just to combine it together and make it a valid signature scheme.

Putting it all together

Since we already discussed how the signature scheme works at a higher level, I’ll briefly recap the signature scheme here. Assume we use the discrete-log based construction.

During the setup phase, Alice and the platform agree on some certain group G and its generator g . Then the platform will randomly sample an element x and pass along y = g^x to Alice. Alice will also generate a signing key and a verifying key for a normal signature scheme (like ECDSA). Alice will then make her bid (let’s say her bid is 100 ) and sample some random nonce r . She will produce a Chameleon Hash hash = g^100 * y^r . Then she can sign the hash with a regular signature scheme to obtain the signature sig = Sign(sign_key, hash) . Finally, Alice sends the signature along with the hash and the bidding to the platform. The platform verifies the validity of the hash by running Verify(verify_key, hash, sig) .

Again, if the signature and the hash are leaked to other parties, people will only see that Alice signed on some random garbage stream of bytes. If the platform tries to provide a valid opening to this hash, no one will believe him because he has the power to forge anything he’d like to. This ensures the secrecy of Alice’s bidding.

Problem solved. Now we have a pretty cool signature scheme that we can choose to only disclose our signatures to designated parties. Alice is now happy.

Further Enhancements

In the original paper, the authors didn’t just stop right here. They also elaborated on how to enhance this protocol even further. I’m going to talk about two interesting ones.

Recipient’s Identity: Right now, in this scheme, Alice didn’t really specify whom she wanted to disclose her signature to in the signature. This empowers Alice so she can deny any signature if she doesn’t feel like accepting them. She can simply say — Oh this signature was intended for someone else, not you — to get around the legal disputes every time.

The way to fix it is to also let Alice sign the intended recipient’s name in her normal signature. Then Alice couldn’t lie about it anymore.

Exposure-freeness: The other concern is that in the case of legal dispute, it seems like Alice has to provide her m, r pair in order to prove a collision to the judge. This will, unfortunately, leak Alice’s original message m to the public. Maybe Alice will be too embarrassed to reveal her message in court.