Continued from Is there a flaw in this ECC blind signature scheme?
The problem
I needed a partially blind signature scheme for one of my projects, but couldn't find one on the internet, so I've made one (I think).
Is there anyone who can verify my results
Actors
- Alice (signer, i.e. bank)
- Bob (requester, i.e. payer)
- Bill (Verifier, i.e payee)
All actors agree on elliptic curve parameters:
Curve: y^2 = x^3 + a*x + b mod p
Base point: P
Order of base point: n
Alice generates his private key by choosing random value x
in [1, n-1]
range, then she computes and publishes Q = x*P
The algorithm
Alice holds record for Bob's and Bill's account balances, Bob want's to make a payment to Bill. For that purpose:
- Bob generates a token message
M = "This is 5 dollar Serial No. 111222333"
- Bob generates public info message
Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
, - Bob hashes his token message which results with
m = hash(M)
- Bob hashes his public info message
z = hash(Z)
- Bob generates random blinding factor
v = random()
- Bob blinds his token message
u = (m - v) mod n
- Bob sends
(u, Z)
to Alice - Alice by looking into
Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
sees that Bob want to charge 5 USD from his account - Alice charges 5 USD from Bob's account and blindly signs
u
by generating pair(s', R')
- For that purpose Alice generates random value
r = random()
that will be used for protecting her private keyx
- Then Alice computes
s' = (x - r + u + hash(Z)) mod n = (x - r + u + z) mod n
- And
R' = r * P
- For that purpose Alice generates random value
- Alice sends the resulting
(s', R')
pair to Bob - By receiving
(s', R')
Bob unblinds the message into(s, R)
, this is done according to following steps:- Bob generates random unblinding factor
w = random()
- Bob then computes
s = (s' + w - m) mod n
- Bob then computes
R = R' + (m - w - v)*P
- Bob generates random unblinding factor
- Bob then pays for services from Bill by sending him tuple
(s, R, Z, M)
By receiving Bob's tuple
(s, R, Z, M)
Bill validates:- Token message
M = "This is 5 dollar Serial No. 111222333"
- Public info
Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
- The signature
(s, R)
by checking equations*P - Q + R = z*P + m*P
: - Since
s = s' + w - m
thens
is also equal tox - r + v + z + w
- Since
R = R' + (m - w - v)P
thenR
is also equal tor*P + (m - w - v)*P
which in turn is equal tor*P + m*P - w*P - v*P
Then the initial equation
s*P - Q + R = z*P + m*P
yields to:(x - r + v + z + w)*P - Q + (r*P + m*P - w*P - v*P) = z*P + m*P
which in turn yields to:
x*P - r*P + v*P + z*P + w*P - Q + r*P + m*P - w*P - v*P = z*P + m*P
by applying simplification we get that:
z*P + m*P = z*P + m*P
- Token message
After performing validation checks Bill asks Alice to add 5 USD to his account by sending her the tuple he received from Bob
(s, R, Z, M)
When Alice receives
(s, R, Z, M)
- She validates
Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
- She validates M = "This is 5 dollar Serial No. 111222333"
- She adds (111222333, 2018-01-01 12:00:00Z) to her database of expired tokens
- The token will be deleted after 2018-01-01 12:00:00Z preventing the database to grow indefinitely
- She validates
Alice is able to verify her own signature (s, R, Z, M)
by repeating steps made by Bill though she is not able to track who made a payment to Bill. It's true because even if Alice has recorded the s'
component in her database during signature phase, she will not be able to match it because during repayment phase she will receive (s, R)
instead of (s', R')
and so by subtracting recorded s'
from s
she will get:
s - s' = ((x - r + v + z + w) - (x - r + v + m + z) + m + z) mod n =
= (x - r + v + z + w - x + r - v - m - z + m + z) mod n =
= w mod n
and there's no way for Alice to discover w
Here is another example with real numbers: https://dl.dropboxusercontent.com/u/51743054/PartiallyBlindSignatureExample.pdf
P.S. The scheme provided in the following paper seem like has a flaw in it (during signature phase, a signer may embed requesters identity data into h(z) which may be recovered during verification phase and so requester's identity may be disclosed by the verifier, if signer and verifier share common database):
http://ijns.femto.com.tw/contents/ijns-v14-n6/ijns-2012-v14-n6-p316-319.pdf
I've taken that paper as a base work and fixed (I think) the problems that were in it, now it shouldn't leek requester anonymity.