# Is signing a message hash a valid replacement for blind signature?

I didn't understand how the blind signature implementations work. But I devised my own way of doing it:

• Alice would compose the message
• Alice would calculate the hash of the message
• Alice would hand the hash to Bob
• Bob would sign it with his private key
• Alice would hand the message and the signed hash to Carol
• Carol would calculate the actual hash using the message
• Carol would decode the signed hash with Bob's public key
• Carol would compare the actual hash with the decoded hash

Wouldn't this algorithm replace the blind signature implementation as described in Wikipedia in every case?

• Doesn’t your scheme plainly reveal k bits of the information in Alice’s message to Bob, where k is the length of the hash? If I understand the definition of blind signature schemes correctly, that is not a blind signature scheme. Mar 29 '11 at 2:17
• @Tsuyoshi: Indeed. As I pointed in my answer below, since the hash function is deterministic, it cannot be used for blinding. You stated this in another correct way: Hash functions reveal (partial) information about the message being hashed. The problem with Wikipedia's definition is that it is not formal enough. I ask the OP to take a look at the formal definition on page 7 of Security of Blind Digital Signatures (blindness property). Mar 29 '11 at 7:10

## 1 Answer

Wouldn't this algorithm replace the blind signature implementation as described in Wikipedia in every case?

No, because hashing is a deterministic algorithm. Let M be Alice's message, and $H(\cdot)$ be the hash function.

In your algorithm, Alice passes H(M) to Bob, who can store H(M) for later reference. This way, Bob effectively creates a database of message hashes signed by him, as well as the ID of the user who asked for Bob's signature. Let $D = \{\langle H(M_1), ID_1 \rangle, \langle H(M_2), ID_2 \rangle, \ldots \}$ be this database.

On seeing a message-signature pair $(M, \sigma)$, Bob hashes M to H(M), and searches D for H(M). If H(m) is found, Bob can easily recover the ID of the user. Hence, this method does not blind the identity of the user.

• Hiding the ID of the user doesn't seem to be a requirement for a blind signature. The Wikipedia definition states only that the signer must sign the message without knowing the message. In which of the use cases of this tool does my algorithm fail? In digital cash or cryptographic eletronic voting systems? Mar 28 '11 at 19:32
• @Jader: In e-voting systems, it's ideal that the ballots cannot be linked to the voters (anonymity). On the other hand, the voters must be authorized to do so. That's why they need a signed (authorized) ballot. The signature process must be blinded to protect the anonymity. Since the hashing is deterministic, the signer, on seeing a message M (when votes are later revealed to be counted), can compute H(M), and decide whether he previously signed H(M). The database D mentioned above helps the signer to reveal the identity of the voter as well (extra bonus!). The same holds for digital cash. Mar 28 '11 at 20:03
• @Sadeq I'll have to study more until I understand this Mar 29 '11 at 14:12
• @Jader Let's say you sign 10 blinded messages with a proper blind signature scheme. Later you see a message floating around with your signature on it. You know it must be one of the 10 you signed but you shouldn't be able to tell which one it was. That is the property Sadeq is trying to explain that your protocol lacks. Without this property, all the evoting applications fail and I imagine all the digicash ones as well. Mar 30 '11 at 19:55
• If your system is such that the signer will never encounter a message he signed (or collude with someone who will) or there is some motivation for delaying the time between him signing and him learning the message, then in these limited threat models, your system could work (I would add randomness to the hash). It however is not a "blind signature," it is just a signed commitment. Mar 30 '11 at 19:55