I am toying with eCash systems and blind signatures, and I started with Chaum's original formulation. In particular, I'm using this formulation from this link:
U chooses blinder
r and blinds message
m' = r^e H(m) mod n
m' to the server. He receives a signature
Now, my original
m should have two delimited fields, a serial number
S and a value
V, and although
S should remain unknown to the bank, the bank wants to know for sure that it is encrypting
V and not some other value. It is important that the user shows
S at the time of spending the key, but that this cannot be linked back to the request for the blind signature.
V part, I'm thinking of using a ZK proof, specifically a Sigma-protocol, to prove V is encoded in the hash. To do this, I'm planning to use a Pedersen hash, on a group
G with known generators
g,h such that their relative discrete log is not known.
H(m) = H(S, V) = g^S h^V
The User would send to the Signer a blinded value
m' = r^e H(S,V) mod n
where the group element
H(m) is serialized and interpreted as an integer.
The user would also send a ZK Proof for these statements:
Private Inputs: r, S, A Public Inputs: m', e, V, g, h, n Statement: m' = r^e * A A = serialized version of g^S h^V
The signer does not really care about the format of
S, as long as there is something in there. What it wants to be certain of is that the value it is signing,
V, is what has been publicly revealed (so that it can deduct the owner's account by the correct balance).
If the proof is correct, the Signer signs the message
m' and the User unblinds it to become
s = H(m)^d.
When the user spends the note, he will present the values
(S, V, s). A merchant can verify the signature by checking
VerifySig(s, H(S, V)) == True
and checking if that
S has already been seen before (to prevent double-spend).
H(S,V) have been revealed previously, so this spending is not linkable to the note creation.
I can see there is a frail point in bringing a group element in a proof of multiplication in an RSA-like group. And I haven't written the details of Sigma-proof yet. But does it look like this is a feasible approach, or would there be easier ways to do this?
I want something secure, of course, but my main concern at the moment is performance and as low interactivity as possible. Therefore, I would not like to use a cut-and-choose model.
Any help would be appreciated. Thanks.