Double-Blind Compact E-cash from Bilinear Map

Abstract

Compact E-cash is the first scheme which can withdraw 2^l coins within 𝒪(1) operations and then store them in 𝒪(𝑙) bits. Because of its high efficiency, a lot of research has been carried out on its basis, but no previous research pay attention to the privacy of payees and in some cases, payees have the same privacy requirement as payers. We propose a double-blind compact E-cash scheme, which means that both the payer and the payee can keep anonymous while spending. In our scheme, the payer and the bank cannot determine whether the payees of two different transactions are the same one and connect the payee with transactions related to him, in this way, the privacy of the payee is protected. And our protocols disconnect the received coin from previous transaction, then, the coin can be transferred into an unspent coin which belongs to the payee. The proposed e-cash scheme is secure within y-DDHI and LRSW assumption.

1. Introduction

In electronic cash(E-cash) schemes, users are allowed to withdraw coins from the bank, and then pay coins to merchants as the service fees. If the merchant wants to spend these coins, he needs to deposit them to the bank and then the bank credits them into his account. And a good electronic cash scheme requires the follow four properties:

1. Balance: The users cannot spend more coins than they have even cooperating with other users and merchants.

2. Anonymity: If the user is honest, then it is impossible for the bank to infer the user’s identification even cooperating with any other malicious merchants and users.

3. Identifying double-spenders: The bank can identify the double-spender.

4. Exculpability. If the user is honest, then no one can frame him as a double-spender.

In compact E-cash scheme, a user can withdraw a wallet containing 2^𝑙 coins and store the wallet using 𝒪(l + k) bits, where k is a security parameter[1]. Compare to the best previously known scheme which requires at least 𝒪(2^𝑙 ∙ k) bits before, the storage efficiency of compact E-cash has made great progress. And many E-cash schemes have been put forward based on the compact E-cash. [2] introduces the bounded accumulator to construct the compact E-cash scheme. [3] introduces compact and batch spending to compact E-cash more practical and achieves spending multiple coins just in one protocol which makes compact E-cash more practical.[4] constructs a compact E-cash scheme without the random oracle. [5] presents an efficient and practical E-cash scheme based on an offline trusted third party (TTP). [6] constructs a new compact E-cash scheme with arbitrary wallet size using verifiable random functions and bounded accumulators. [7] achieves practical and complete tracing in compact E-cash scheme by designing new structure of knowledge proof and improves the complexity of withdrawing a wallet from 𝒪(k) to 𝒪(1). [8] introduces zero-knowledge proof with non-standard structure to solve the efficiency problem on coin-tracing.

Anonymity is an important research point in the field of E-cash and has attracted wide attention from the research community. [9] use a bounded accumulator with the classical binary tree to achieve full unlinkability and anonymity. [10] achieves full anonymity on divisible E-cash scheme without requiring a TTP.[11] constructs a multi-authority E-cash scheme based on blind threshold signature. [12] uses the malleable signatures to make coins transfer anonymously and safely.

However, none of the previous E-cash schemes consider the privacy protection for payees. And the privacy of payees needs to be considered in some cases. For example, when the payee of the coin is a person rather than a shop, he does not want anyone else to know how many coins he has received and other transaction.

In Bitcoin, the privacy protection for payees is realized and the privacy policy is to isolate the receipt and payment address from the physical identity of the holder [13]. However, all the transaction log is public, thus the only protection on user’s privacy is the pseudonyms [14]. An increasing body of research shows that Bitcoin can be de-anonymized [15], which can make serious violation of user’s privacy.

In view of the above problems, we introduce the concept of double-blind into compact E-cash, and protect the privacy of both users and merchants. Different from pseudonym in Bitcoin schemes, the signature from the bank belongs to the user and the merchant in our scheme is randomized in every transaction such that the bank cannot link the two transactions where the payee and payer remain the same. And the merchant can transfer the coin he received previously into a new coin for next spending anonymously without its account.

In Section 2, we present the related preliminaries used in the scheme. We provide security model in Section 3. Our scheme is described in Section 4. Security of the proposed scheme is analyzed in Section 5 and we provide the system efficiency in Section 6. Finally, in Section 7, we put the conclusion of the paper.

2. Preliminaries

2.1. Complexity Assumptions

2.1.1. y-Decisional Diffie-Hellman Inversion(y-DDHI) Assumption [16], [17]

Randomly given a generator 𝑔 ∈ 𝐺, where 𝐺 is a group, whose order is a prime number q, the values (𝑔, 𝑔^𝑥, … , 𝑔(^𝑥𝑦)) for random 𝑥 ∈ ℤ_𝑞, and a value 𝑅 ∈ 𝐺, it is hard to decide if 𝑅 =𝑔^1/𝑥 or not.

2.1.2. LRSW Assumption [18]

𝐺𝐺 = 〈𝑔〉 is a group. Let 𝑋, 𝑌 ∈ 𝐺, 𝑋 = 𝑔^𝑥, 𝑌 = 𝑔^𝑦. Let 𝑂_𝑋,𝑌(∙) denote an oracle whose input is a value 𝑚𝜖ℤ_𝑞, and outputs 𝐴 = (𝑎, 𝑎^𝑦, 𝑎^{𝑥+𝑚𝑥𝑦}) where a is randomly chosen by the oracle. For all probabilistic polynomial time adversaries𝒜, the negligible function 𝑣(𝑘) defined as follows:

Pr [(𝑞, 𝐺, 𝒢, 𝑔, ℊ, 𝑒) ← Setup(1𝑘); 𝑥 ← ℤ_𝑞; 𝑦 ← ℤ_𝑞; 𝑋 = 𝑔^𝑥; 𝑌 = 𝑔^𝑦; (𝑎, 𝑏, 𝑐, 𝑚) ← 𝒜^{𝑂_𝑋,𝑌}(𝑔, 𝐺, ℊ, 𝒢, 𝑞, 𝑒, 𝑋, 𝑌): 𝑚 ∉ 𝑄 ∧ 𝑚 ∈ ℤ_𝑞 ∧ 𝑚 ≠ 0 ∧ 𝑎 ∈ 𝐺 ⋀ 𝑏 = 𝑎^𝑦 ⋀ 𝑐 = 𝑎^{𝑥+𝑚𝑥𝑦}] = 𝑣(𝑘)       (1)

Where Q is the set of queries that 𝒜 made to 𝑂_𝑋,𝑌(⋅), and ℊ = 𝑒(𝑔, 𝑔) is a generator of 𝒢.

2.2. Bilinear Maps[16],[19]

(𝑞, 𝑔₁, ℎ₁, 𝐺₁, 𝑔₂, ℎ₂, 𝐺₂, 𝐺, 𝑒) are the generated parameters of a bilinear mapping with corresponding to the security parameter 1^𝑘.The definition of bilinear maps and the exact meaning of the parameters are as follows:

1. 𝐺₁, 𝐺₂ are groups of prime order 𝑞 = Θ(2^𝑘);

2. each group has two generators where 𝐺₁ = 〈𝑔₁〉 = 〈ℎ₁〉 and 𝐺₂ = 〈𝑔₂〉 = 〈ℎ₂〉.

3. 𝜓 is a isomorphism from 𝐺₂ to 𝐺₁, where 𝜓(𝑔₂) = 𝑔₁ and 𝜓(ℎ₂) = ℎ₁;

4. 𝑒 is a bilinear map: 𝐺₁ × 𝐺₂ → 𝐺. The properties are as follow:

(Bilinear) for all 𝑔₁ ∈ 𝐺₁, 𝑔₂ ∈ 𝐺₂, and 𝑎, 𝑏 ∈ ℤ_𝑞, 𝑒(𝑔₁^𝑎, 𝑔₂^𝑏) = 𝑒(𝑔₁, 𝑔₂)^𝑎𝑏;

(Non-degenerate) if 𝑔₁ is a generator of 𝐺₁ and 𝑔₂ is a generator of 𝐺₂, then 𝑒(𝑔₁, 𝑔₂) is a generator 𝐺.

2.3. Signature of Knowledge

2.3.1. statistically indistinguishable [20]

Let 𝐿 ∈ {0,1}* be a language and let {𝐴(𝑥)}_𝑥∈𝐿 and {𝐵(𝑥)}_𝑥∈𝐿 denote two sets of random variables which can be indexed by 𝑥 ∈ 𝐿. A and B are statistically indistinguishable if their statistical difference is negligible, or more specifically, if for every polynomial 𝑝(∙) and for all long 𝑥 ∈ 𝐿 it holds that

\(\begin{aligned}\sum_{\alpha \in\{0,1\}^{*}}|\operatorname{Pr}(A(x)=\alpha)-\operatorname{Pr}(B(x)=\alpha)|<\frac{1}{p(|x|)}\end{aligned}\)       (2)

2.3.2. statistical zero-knowledge [21]

Given an interactive protocol (𝑃, 𝑉), if there exists a probabilistic expected polynomial-time simulator 𝑆_𝑉 and two ensembles {[𝑉, 𝑃](𝑥)}_𝑥∈𝐿 and {𝑆_𝑉(𝑥)}_𝑥∈𝐿 are statistical indistinguishable, then protocol (𝑃, 𝑉) is statistical zero-knowledge.

2.3.3. signature of knowledge [22]

A pair (𝑐, 𝑠) ∈ {0,1}^ℓ × ℤ_𝑞 satisfying 𝑐 = 𝐻(𝑦||𝑔||𝑦^𝑐𝑔^𝑠||𝑚) is a signature of knowledge of the discrete logarithm which denotes y to the base g, on the message 𝑚𝑚 and it’s denoted as SPK{𝑥: 𝑦 = 𝑔^𝑥}(𝑚).

SPK{𝑥: 𝑦 = 𝑔^𝑥}(𝑚) can be computed if 𝑥 ≡ log_g𝑦(mod 𝑞) is given by choosing a random 𝑟 ∈ ℤ_𝑞 and computing c and s as: 𝑐 = 𝐻(𝑔||𝑦||𝑡||𝑚) and 𝑠 = 𝑟 − 𝑐𝑥 (mod 𝑞). 𝑡 = 𝑔^𝑟 is the commitment to prove the knowledge of 𝑥 ≡ log_g𝑦(mod 𝑞). And 𝐻:{0,1}* → {0,1}^𝑘 is a strong collision-resistant hash function. Signature of knowledge is the non-interactive version of zero-knowledge proof protocol.

2.4. Pseudorandom Function [17]

Function 𝑓 ∈ 𝐹_𝑛 is defined by the tuple (𝐺, 𝑞, 𝑔, 𝑠), where 𝑔 is a generator of a group 𝐺 whose order is a prime order 𝑞 and 𝑠𝑠 is a seed selected in ℤ_𝑞. For 𝑥 ∈ ℤ_𝑞(except for 𝑥 ≡ −1 mod 𝑞), the function 𝑓_{𝐺,𝑞,𝑔,𝑠}(∙), simply denoted as 𝑓_𝑔,𝑠^𝐷𝑌(∙), is defined as 𝑓_𝑔,𝑠^𝐷𝑌(𝑥) = 𝑔^{1/(𝑠+𝑥+1)}.

2.5. Pedersen Commitment Scheme [23]

G is a group with prime order q, and generators are (𝑔₀, ⋯ , 𝑔_𝑚). In order to commit the set of values (𝑣₁, ⋯ , 𝑣_𝑚) ∈ ℤ_𝑞^𝑚, the user picks a random 𝑟 ∈ ℤ_𝑞 and sets 𝐶 = 𝑔₀^𝑟 ∏_𝑖=1^𝑚𝑔_𝑖^𝑣_𝑖.

2.6. CL Signatures [18], [24]

The CL Signature scheme consists of two protocols:

1.The first protocol occurs between the user and the signer with (pk_S, sk_S). The public input of both parties is pk_S. And the secret input of the user are values (𝑣₁, ⋯ , 𝑣_𝑚; 𝑟) such that 𝐶 = PedCom(𝑣₁, ⋯ , 𝑣_𝑚; 𝑟).The secret input of the signer is sk_S. During interacting, the signer cannot learn anything about the secret of the user. After the protocol, the user obtains the signer’s signature on the values which is denoted as 𝜎_pkS(𝑣₁, ⋯ , 𝑣_𝑚).

2. The second protocol occurs between the user and the verifier to prove knowledge of a signature. The public input of both parties is pk_S and the secret input of the user are values (𝑣₁, ⋯ , 𝑣_𝑚; 𝑟) and the signature 𝜎_pkS(𝑣₁, ⋯ , 𝑣_𝑚). There is no secret input on the verifier’s side. The verifier outputs whether the signature is valid or not.

The CL signature scheme’s security is based on RSA group or bilinear maps.

3. Definition of Security

3.1. Syntax [1]

Suppose that P is a protocol occurring between A and B, then 𝑃(𝐴(𝑥), 𝐵(𝑦)) denotes that A inputs 𝑥, and 𝐵 inputs 𝑦. There are three entries in our electronic cash scheme: user 𝒰, bank ℬ, and merchant ℳ. The protocols and algorithms are defined as follow:

● 𝐵/UKeyGen(1^𝑘, params) is an algorithm for ℬ to generate his key pair, and UKeyGen(1^𝑘, params) is the algorithm for 𝒰 and ℳ to generate key pair (ℳ can be seen as a special user).

● Sign(𝒨(sk_m, pk_B), ℬ(sk_B, pk_m)) is a protocol whose outcome is a certificate for 𝒨, which represents the legality of 𝒨 as a payee.

● Withdraw(𝒰(sk_u, pk_b, 2^𝑙), ℬ(sk_u, pk_b, 2^𝑙)) is a protocol occurring between 𝒰 and ℬ which allows 𝒰 to withdraw a wallet containing 2^ℓ coins from ℬ. ℬ records a debit of 2^ℓ coins for 𝒰′ account pk_u.

● Spend(𝒰(𝑊, pk_b, 𝜎_𝑚^𝑟), 𝒨(sk_m, pk_b, 𝜎_𝑚, 𝜎_𝑢^𝑟)) is a protocol occurring between 𝒰 and ℳ which enables 𝒰 to spend a coin anonymously. ℳ obtains (𝑆, 𝜋) which denotes the serial number and the validity proof of the coin and 𝒰 updates his wallet. Here, 𝜎_𝑚^𝑟 denotes the randomized signature.

● Deposit(𝒨(sk_m, 𝑆, 𝜋, pk_b), ℬ(sk_b, 𝜎_𝑚^𝑟)) is a protocol occurring between 𝒨 and ℬ allowing 𝒨 to deposit the coin he has received. After the protocol, ℬ adds the coin to the spent coins list.

● Transfer(𝒨(sk_m, 𝑆, 𝜋, pk_b), ℬ(sk_b, 𝜎_𝑚^𝑟)) is a protocol occurring between 𝒨 and ℬ allowing 𝒨 to convert the coin he has received into a new coin belongs to him anonymously. After the protocol, 𝒨 obtains a new wallet containing only one coin.

● Identify(params, 𝑆, 𝜋₁, 𝜋₂) is an algorithm to identify the double-spender with S and two validity proofs, 𝜋₁ and 𝜋₂. The output of this algorithm consists of a public key pk_u and a proof ∏_𝐺.

● VerifyGuilt(𝑆, pk_u, ∏_𝐺) is an algorithm to verify the proof ∏_𝐺 to prove that the user whose public key is pk_u is a real double-spender.

3.2. Security Definitions

Alg^{𝑋−𝑌(𝒜)} denotes an algorithm which has the access model X-Y to the adversary 𝒜 with input x. For the more details about X-Y model we refer to [1]

ℰ_Prot,𝑙^{𝑋−𝑌(𝒜)} denotes an extractor of the proof protocol Prot for language 𝑙 in the 𝑋 − 𝑌 model. For property formed (params, auxext), the extractor will output a w in expected polynomial time such that (x, w) ∈ l whenever the probability that the verifier accepts xx in the 𝑋 − 𝑌 model, is non-negligible.

𝒮_Prot,𝑙^{𝑋−𝑌(𝒜)} denotes a simulator of the proof protocol Prot for language 𝑙 in the 𝑋 − 𝑌 model. When interacting with 𝒜 in the 𝑋 − 𝑌 model, the zero-knowledge simulator 𝒮_Prot,𝑙^{𝑋−𝑌(𝒜)} makes 𝒜 unable to distinguish between the view generated by it and the view generated by a real user.

3.2.1. Balance

Let m₁ denote the message sent from 𝒰 to ℬ which can identify himself and b₁ denote the state of the bank when m₁ received. The balance property requires that:

1. There exists an efficiently decidable language 𝑙_𝑆 and an extractor ℰ_Prot,𝑙^{𝑋−𝑌(𝐴)} (𝑏₁, 𝑚₁) for all b₁ m₁, it extracts 𝑤 = (𝑆₁, … , 𝑆_𝑛, aux), where n denotes the capacity of the wallet. Such that (b₁, m₁, w)∈ 𝑙_𝑠 when the probability that the bank accepts in the Withdraw or Transfer protocol is non-negligible. The Transfer protocol can be seen as a special variant of Withdraw protocol.

2. On input (params, pk_B), the adversary 𝒜 plays the following game: 𝒜 can execute Withdraw, Transfer and Deposit protocols with the bank as many times as he wishes (he can spend the coin to himself). Let (𝑏₁, 𝑖, 𝑚₁, 𝐼, 𝑤_𝑖) ∈ 𝑙_𝑆 be the output of ℰ_Prot,𝑙^{𝑋−𝑌(𝐴)}(pk_i, 𝑏_1,𝑖, 𝑚_1,𝑖) if the ith Withdraw or Transfer protocol. Recall that 𝑤_𝑖 =(𝑆_𝑖,1, … , 𝑆_𝑖,𝑛, aux) is a set of n serial numbers belong to pk_i, where n is the capacity of the wallet. Let 𝐴_𝑓 = {𝑆_𝑖,𝑗|1 ≤ 𝑖 ≤ 𝑓, 1 ≤ 𝑗 ≤ 𝑛} represents serial numbers that 𝒜 get after 𝑓 executions of Withdraw or Transfer protocol. If in some Deposit or Transfer protocol, the bank accepts a coin whose serial number 𝑆 ∉ 𝐴_𝑓, then 𝒜 wins. We require that 𝒜 wins with only negligible probability.

3.2.2. Identification of double spenders

This property requires that no probabilistic polynomial-time adversary can win the following game with non-negligible probability:

On input pk_B, 𝒜 can execute Withdraw, Taransfer and Deposit protocols with bank as many times as he wishes. We have 𝑤_𝑖 = (𝑆_𝑖,1, … , 𝑆_𝑖,𝑛, aux) is a set of n serial numbers belong to pk_i which we have defined in section 3.2.1. Let 𝐴_𝑓 = {𝑆_𝑖,𝑗|1 ≤ 𝑖 ≤ 𝑓, 1 ≤ 𝑗 ≤ 𝑛} represents serial numbers that 𝒜 get after 𝑓 executions of Withdraw or Transfer protocol. If in some Spend protocol, the bank, accepts a coin which was already recorded in the spent coin list, yet Identify outputs pk_U and ∏_𝐺 which is not accepted by VerifyGuilt, then 𝒜 wins the game.

3.2.3. Anonymity of the user

Consider an adversary 𝒜 with the bank’s public key pk_B issues the following queries:

PK of I: 𝒜 requests and received the public key of user 𝒰, generated as (pk_u, sk_u).

Withdraw with I: 𝒜 executes the Withdraw protocol with 𝒰:  

Withdraw(𝒰(pk_B, sk_u, 𝑛), 𝒜(state, 𝑛))

The user’s output of 𝑗th query is 𝑊_𝑗.

Spend from wallet j: 𝒜 executes the Spend protocol from 𝑊_𝑗:

Spend(𝒰(𝑊_𝑗), 𝒜(state)).

We require that 𝒜 cannot ask 𝒰 to pay more than n coins from 𝑊_𝑗 and there exists a simulator 𝒮^𝑋−𝑌(auxsim,∙) and the adversary 𝒜 can distinguish which of the following game he is playing with only negligible advantage:

Game R: 𝒜 issues the queries above to the real user 𝒰.

Game I: 𝒜 issues the PK and Withdraw queries to the real user 𝒰, but in the Spend query, 𝒜 interacts with the simulator rather than 𝒰.

Recall that there are many users executes Withdraw protocol with the adversary, and the Spend query is initiated by the user, so, the adversary cannot determine which user he interacts with.

3.2.4. Anonymity of the merchant

Here, we consider the anonymity of the merchant during the Sign, Spend and Transfer protocols. The adversary 𝒜 with the bank’s public key pk_B issues the following queries:

PK of M: 𝒜 requests and receives the public key of merchant 𝒨, generated as (pk_m, sk_m)

Sign with M: 𝒜 executes the Sign protocol with 𝒨:

Sign(𝒨(pk_B, sk_m), 𝒜(state))

We denote the merchant’s output after the query by σ.

Spend with M: we suppose that 𝒜 has a valid wallet 𝑊_𝑗, and executes the Spend protocol with 𝒨:

Spend(𝒜(𝑊_𝑗), 𝒨(σ)).

Transfer: 𝒜 executes the Transfer protocol with the merchant 𝒨:

Transfer(𝒨(pk_B, sk_m, 𝜋), 𝒜(state))

No adversary 𝒜 can distinguish which of the following game he is playing with non-negligible advantage:

Game R: 𝒜 issues the queries above to the real user 𝒨.

Game I: 𝒜 issues the PK and Sign queries to the real merchant 𝒨, but in Transfer and Spend query, 𝒜 interacts with the simulator rather than 𝒨.

3.2.5. Exculpability

Exculpability guarantees that no one can slander an honest user as a double-spender. We set an adversary 𝒜 who launches the following attack against a user:

Setup: The bank ℬ generates system parameters and the user 𝒰 generates the key pair (pk_u, sk_u). The adversary gets the bank’s public key pk_B.

Queries:

Withdraw wallet: 𝒜 plays the role of ℬ while executing Withdraw protocol with 𝒰. The output of 𝒰 after withdraw is a wallet 𝑊_𝑗. Recall that Transfer can be seen as a special Withdraw protocol.

Spend wallet: 𝒜 plays the role of the merchant 𝒨 while executing Spend protocol with 𝒰 whose input is 𝑊_𝑗. We require that 𝒜 cannot execute this query more than the capacity of 𝑊_𝑗.

Success criterion: After above queries, 𝒜 outputs (S, ∏) and wins the game if VerifyGuilt accepts.

The scheme guarantees exculpability if the adversary wins with negligible probability.

4. Double-Blind Compact E-cash based on bilinear map

4.1. The System Model

Our system model is illustrated in Fig. 1. Firstly, the user withdraws a wallet containing 2^𝑙 coins and the bank records a debit for the user’s account. Secondly, the user pays the merchant coins as the reward. After Transfer protocol, the merchant cuts off the connection between the coin he received and previous transactions for next spending. Before depositing this coin into his account, the final merchant could transfer the coin and pay the coin to himself for cutting off the link between the coin and previous transactions, so that no other entities can confirm whether the coin is from a special transaction.

Fig. 1. System design block diagram

4.2. Global parameters for the system

On input the security parameter 1^𝑘, the system is initialized and the public parameters used are following:

𝐺₁ = 〈𝑔₁〉 = 〈ℎ₁〉 and 𝐺₂ = 〈𝑔₂〉 = 〈ℎ₂〉, both have the same prime order 𝑞 = Θ(2^𝑘). These two groups are used to construct the Pedersen commitment scheme and CL signature scheme based on the bilinear map 𝑒: 𝐺₁ × 𝐺₁ → 𝐺₂.

𝐺 = 〈𝑔〉 is a group whose order is a prime number and denoted as 𝑞 = Θ(2^𝑘). And the use of this group is to generate the serial number and the security tag of coins.

4.3. B/U Keygen Algorithm

In BKeygen(1^𝑘, 𝜁), the bank generates a key pair (pk_B, sk_B) for CL signature, and the forms are as follows:

sk_B: 𝑥 ← 𝑍_𝑞, 𝑦 ← 𝑍_𝑞, 𝑧_𝑖 ← 𝑍_𝑞, 1 ≤ 𝑖 ≤ 3

pk_B: 𝑋 = 𝑔₁^𝑥, 𝑌 = 𝑔₁^𝑦, 𝑍_𝑖 = 𝑔_𝑖^𝑧_𝑖, 1 ≤ 𝑖 ≤ 3

In Ukeygen(1^𝑘, 𝜁), 𝒰 generates a unique key pair (pk_𝒰, sk_𝒰) = (𝑔₁^𝑢, 𝑢) for random 𝑢𝜖ℤ_𝑞. Recall that merchants can be seen as special users and also generates a unique key pair (pk_𝒨, sk_𝒨) = (𝑔₁^𝑚, 𝑚) for a random 𝑚 ∈ ℤ_𝑞.𝜁 denotes the necessary common parameters.

4.4. Overview of our scheme

we explain the main idea of each protocol to help readers to better understand our scheme in this section.

4.4.1. Withdraw Protocol

In this protocol, the user runs the CL Signature protocol with the bank for obtaining the signature on his secret values. Here, the original signature σ_u is the identification of the user, and in next protocols, we use randomized signature σ_u′ which is also valid but independent of σ_u' to prove the validity of the user as a payer, such that others cannot determine whether two transactions are linkable.

4.4.2. Sign Protocol

In this protocol, the merchant runs the CL Signature protocol with the bank for obtaining the signature on his private key Here, the original signature 𝜎_𝑚 is the certificate of the merchant, and in next protocols, we use randomized signature 𝜎_𝑚′ which is also valid but independent of 𝜎_𝑚 to prove the validity of the merchant as a payee.

4.4.3. Spend Protocol

In order to protect the anonymity of both users and merchants while spending, the public keys of both two parties are not disclosed to each other. So, in order to prove the validity of the merchant as a payee and the validity of the user as a payer, we construct two zero-knowledge proof.

In our scheme, there are two kinds of wallet, one contains 2^𝑙 coins from Withdraw, and the other contains only one coin from Transfer. Serial number and security tag of the two wallets construct similarly, so the user may spend the latter wallet as the former. To prevent this from happening, we change the structure of the latter wallet. And if the user is not honest, the merchant can detect it and reject this coin.

4.4.4. Deposit Protocol

The merchant sends the serial number and the validity proof of the coin to the bank and proves that he is the payee of the coin using the signature 𝜎_𝑚′ and sk_m. If the verification is passed and the bank confirms that the serial number has not been used before, then the bank accepts this coin and credits the merchant’s account. And if the same serial number is received by the bank with same R for the second time, it indicates that the merchant sends the same coin twice; Otherwise, if R is different, the bank recognizes the user as a double-spender and runs Identify algorithm to get his public key.

4.4.5. Transfer Protocol

The merchant sends the coin to the bank and proves that he is the payee of the coin using the signature 𝜎_𝑚′ and sk_m. If the verification is passed and the bank confirms that the serial number has not been used before, then the bank accepts this coin and the merchant can transfer the coin into a new coin whose value comes from the sent coin without the merchant’s account.

4.5. Protocols and Algorithms of Our Schemes

In this section, we mainly talk about the interaction steps in each protocol. And more details are put in Appendix A.

4.5.1. Withdraw Protocol

In this protocol, the user’s wallet containing 2^𝑙 coins is (sk_u, 𝑠, 𝑡, 𝜎, 𝐽), where 𝜎_𝑢 denotes the signature on (sk_u, 𝑠, 𝑡) from the bank and J is the coin counter with l bits. In the process of interaction, the bank cannot learn anything about (sk_u, 𝑠, 𝑡). The interactions between the user 𝒰 and the bank ℬ are following:

1. 𝒰 proves the knowledge of sk_u to ℬ for identifying himself.

2. 𝒰 selects random value 𝑠', 𝑡 ∈ ℤ_q and sends ℬ a commitment

𝐴′ = PedCom(sk_u, 𝑠′, 𝑡; 𝑟) = 𝑔₁^𝑟𝑍₁^𝑢𝑍₂^𝑠′𝑍₃^𝑡.       (3)

ℬ sends a random r’ ∈ ℤ_q. U computes s = s’ + r’. U and ℬ respectively computes

𝐴 = 𝑍₂^𝑟′ 𝐴′ = PedCom(sk_u, 𝑟′ + 𝑠′, 𝑡; 𝑟) = PedCom(sk_u, 𝑠, 𝑡; 𝑟).       (4)

3. 𝒰 runs the CL signature protocol with ℬ and obtains ℬ′ s signature on secret values which is:

𝜎_𝑢 = (𝑎, 𝑎^𝑦, 𝑎^𝑥𝐴^𝛼𝑥𝑦, 𝐴₁, 𝐴₂, 𝐴₃, 𝐵₁, 𝐵₂, 𝐵₃)       (5)

4. 𝒰 saves the wallet 𝑊 = (sk_u, 𝑠, 𝑡, 𝜎, 𝐽), and J is initialized to zero.

5. ℬ records 2^𝑙 coins for the user’s account pk_u.

4.5.2. Sign Protocol

The output of this protocol is a certificate 𝛿_m, which represents the legitimacy of the merchant 𝒨 as a payee. The interactions between the merchant 𝒨 and the bank ℬ are following:

1. 𝒨 runs the CL signature protocol with ℬ and obtains ℬ′s signature on sk_m which is:

𝜎_𝑚 = (𝑎, 𝑎^𝑦, 𝑎^𝑥𝑀^𝛼𝑥𝑦, 𝐴₁, 𝐵₁).       (6)

2. 𝒨 saves the certificate 𝛿_m = (sk_m, 𝜎_𝑚).

𝛿_m is the original certificate belonging to the merchant, and in the other protocols, we use the randomized certificate 𝜎_𝑚′ to prove the legitimacy of the merchant as a payee.

4.5.3. Spend Protocol

In this protocol, both the user and the merchant use the randomized signature to identify themselves, and the signatures is different after randomization in each transaction, so the link between each transaction is cut off. And the coin counter J is shown to the merchant in order to construct the proof of knowledge efficiently. The interactions between the user 𝒰 and the merchant 𝒨 are following:

1. 𝒨 proves knowledge of sk_m to 𝒰 with 𝜎_𝑚′, where 𝜎_𝑚′ denotes the randomized signature from ℬ.

2. 𝒰 computes 𝑅 = 𝐻(𝜎_𝑚||info), where info ∈ {0,1}∗ is provided by the merchant. 𝒰 randomly selects J ∈ [0, 2^𝑙 − 1] and J hasn’t used before.

3. 𝒰 sends a coin serial number and a security tag to the merchant:

\(\begin{aligned}S=F_{g, S}^{D Y}(J)=g^{\frac{1}{J+s+1}}\end{aligned}\),       (7)

\(\begin{aligned}T=p k u F_{g, t}^{D Y}(J)^{R}=g^{u+\frac{R}{J+t+1}}\end{aligned}\)       (8)

4. 𝒰 sends J and a ZKPOK Φ of (sk_u, 𝑠, 𝑡, 𝜎) such that:

● 𝑆 = 𝐹_𝑔,𝑠^DY(𝐽)

● 𝑇 = pku𝐹_𝑔,𝑡^DY(𝐽)^𝑅

● 𝑉erifySig(pk_𝐵, (sku, 𝑠, 𝑡), 𝜎_𝑢′ ) = true

5. If Φ verifies and 𝒰 is honest, 𝒨 accepts the coin (𝑆, (𝑅, 𝑇, Φ)).

6. 𝒰 records his counter J is used.

Recall that there are two kinds of wallet in our scheme, if 𝒰 uses the wallet containing only one coin as the wallet containing 2^𝑙 coins, 𝒨 will determine that the user is dishonest and reject this transaction.

4.5.4. Deposit Protocol

In this protocol, the interactions between the merchant 𝒨 and the bank ℬ are following:

1. 𝒨 proves knowledge of sk_m to ℬ with 𝜎_𝑚′.

2. 𝒨 sends ℬ the coin (𝑆, 𝜋 = (𝑅, 𝑇, Φ)) bound to 𝜎_𝑚′.

3. If Φ verifies and the pair (𝑆, 𝜋) is not already in spent coin list (i.e., the coin is not used before), then ℬ adds (𝑆, 𝜋) to spent coin list and credits ℳ′ account.

4.5.5. Transfer Protocol

Transfer protocol can be seen as a special variation of Withdraw protocol and the interactions between the merchant ℳ and the bank ℬ are following:

1. 𝒨 proves knowledge of sk_m to ℬ with 𝜎_𝑚′

2. 𝒨 sends ℬ the coin (𝑆, 𝜋 = (𝑅, 𝑇, Φ)) bound to 𝜎_𝑚′.

3. If Φ verifies and the pair (𝑆, 𝜋) is not already in spent coin list (i.e., the coin is not used before), then ℬ adds (𝑆, 𝜋) to spent coin list and allows 𝒨 to transfer the coin.

4. 𝒨 selects random value 𝑠’, 𝑡 ∈ ℤ_𝑞 and sends ℬ a commitment as shown in (3), ℬ sends a random 𝑟’ ∈ ℤ_𝑞. 𝒰 computes 𝑠 = 𝑠’ + 𝑟’. 𝒰 and ℬ respectively computes A as shown in (4).

5. 𝒨 runs the CL signature protocol with ℬ and obtains ℬ’s signature on secret values and the signature is:

𝜎_𝑚 = (𝑎, 𝑎^𝑦, 𝑎^𝑥𝐴^𝛼𝑥𝑦, 𝐴₁, 𝐴₂, 𝐴₃, 𝐵₁, 𝐵₂, 𝐵₃)       (9)

6. 𝒨 saves the wallet 𝑊 = (sk_m, 𝑠, 𝑡, 𝜎_𝑚), here the new wallet will only contain a coin, and the bank doesn’t record the account for pk_m.

The structure of 𝜎_𝑚 in this protocol is different from 𝜎_𝑢 in Withdraw protocol, we do this to distinguish the two kinds of wallet.

4.6. Identify Algorithm

Suppose (𝑆, 𝜋₁) is in spent coin list for the number S. And the bank accepts a coin with (𝑆, 𝜋₂) ,then the bank can identity the double-spender

\(\begin{aligned}p k=\left(\frac{T_{2}^{R_{1}}}{T_{1}^{R_{2}}}\right)^{\left(R_{1}-R_{2}\right)^{-1}}\end{aligned}\).       (10)

Suppose coin 𝑆 belongs to the user with pk_u = 𝑔^𝑢, then each 𝑇_𝑖 constructed as (8). As the bank runs this algorithm with different R (i.e., 𝑅₁ ≠ 𝑅₂), then the bank can compute the double-spender’s public key:

\(\begin{aligned}\left(\frac{T_{2}^{R_{1}}}{T_{1} R_{2}}\right)^{\left(R_{1}-R_{2}\right)^{-1}}=\left(\frac{g_{3} u R_{1}+R_{1} R_{2} \alpha}{g_{3} u R_{2}+R_{1} R_{2} \alpha}\right)^{\left(R_{1}-R_{2}\right)^{-1}}=g_{3}^{\frac{u\left(R_{1}-R_{2}\right)}{\left(R_{1}-R_{2}\right)}}=g_{3}^{u}=p k_{u}\end{aligned}\).       (11)

The output of this algorithm is a proof ∏_𝐺 = (𝜋₁, 𝜋₂) and public key of the double-spender pk_U.

4.7. VerifyGuilt Algorithm

Recall that everyone can call this algorithm to verify whether the user is a double-spender. Let another user 𝒱 parse the proof ∏_𝐺 as (𝜋₁, 𝜋₂) and each 𝜋_𝑖 as (𝑅_𝑖, 𝑇_𝑖, Φ_𝑖), then run Identify(params, 𝑆, 𝜋₁, 𝜋₂) and compare its output to pk_𝒰 given as input. If these values match, then 𝒱 verifys each Φ_𝑖 with respect to (𝑆, 𝑅_𝑖, 𝑇_𝑖). If all checks pass, 𝒱 accepts that the user with pk_𝒰 is a double-spender; otherwise, deny that the user is a double-spender.

5. Security Analysis for the Proposed E-cash System

5.1. Balance

Part 1. Let 𝒜 be an adversary who executes 𝑓 Withdraw or Transfer protocols with an extractor ℇ acting as the bank. Suppose that the proof of knowledge is done interactively, and let ℇ′ denote the extractor of the proof of knowledge in CL signature, and for each Withdraw protocol, ℇ acts as an honest bank, except during the proof of knowledge where ℇ runs the code of ℇ′ to extract (𝑢, 𝑠, 𝑡) . At the end of each Withdraw execution, ℇ outputs (state_ℇ, 𝐴, 𝑤) ∈ 𝑙_𝑆, where A is a commitment computed by PedCom(𝑢, 𝑠, 𝑡; 𝑟). Let 𝐴_𝑓 = {𝑆_𝑖,𝑗|1 ≤ 𝑖 ≤ 𝑓, 1 ≤ 𝑗 ≤ 𝑛} denote the set of serial numbers after 𝑓 Withdraw executions. And the proof of knowledge in the Withdraw protocol is non-interactive, so both ℇ and ℇ′ must be given control over the random oracle and their access model to 𝒜 must be black-box.

Part 2. Recall that 𝐴_𝑓 contains all the valid serial numbers produced by 𝒜. Thus, if 𝒜 wants to win the game, he must make ℬ to accept a coin where S ∉ 𝐴_𝑓 with non-negligible probability. Now suppose 𝒜 convinces ℬ to accept the invalid coin (𝑆, 𝜋) during Deposit or Transfer protocol. Then 𝒜 must have concocted a false proof Φ that meets the following conditions: (1) 𝒜 knows a signature from ℬ on the values(𝑢, 𝑠, 𝑡) corresponding to the invalid coin and (2) that S and T are correctly formed. Due to the security of CL signature, we know case (1) only happens with negligible probability 𝑣₁(𝑘). Case (2) happens with negligible probability 𝑣₂(𝑘) due to the discrete logarithm assumption and the security of DYPRF[17]. Thus, 𝒜 wins with only negligible probability 𝑣₁(𝑘)*𝑣₂(𝑘).

5.2. Identifying of double-spenders

We need to point out the case in which this property does not apply well. Suppose that the bank issues CL signatures on wallet secrets 𝑠₁ and 𝑠₂ belong to different users, such that |𝑠₁ − 𝑠₂| < 2^𝑙 ,the two users can both generate a valid spending proof for some coin 𝑆 = 𝑓_𝑔,𝑠′^DY(𝑠 − 𝑠′ + 1) = 𝑔^1/(𝑠+1) and there will be two valid coin in the bank’s spent coin list as (𝑆, 𝜋₁) and ( 𝑆, 𝜋₂). However, the probability of that happening is 2^𝑙+1/𝑞 which is negligible. We refer readers to [1] for more details about this.

As defined in balance, let ℇ be the extractor interacting with 𝒜 during the Spend protocol to extract 𝐴_𝑓 = {𝑆_𝑖,𝑗|1 ≤ 𝑖 ≤ 𝑓, 1 ≤ 𝑗 ≤ 𝑛}. Now, suppose the merchant 𝒨 has received two coins (𝑆, 𝜋₁) and (𝑆, 𝜋₂) for some 𝑆𝜖𝐴_𝑓 and deposits them to the bank ℬ and ℬ parses each 𝜋_𝑖 as (𝑅_𝑖, 𝑇_𝑖, Φ_𝑖). Since 𝒨 chooses R randomly while executing Spend protocol with the user and 𝑅₁ ≠ 𝑅₂ with high probability. If each 𝑇_𝑖 = pk_𝒰𝑓_𝑔,𝑡^DY(𝐽 + 1)^𝑅 has the same pk_u, 𝐽 and 𝑡, then the algorithm Identify (𝜁, 𝑆, 𝜋₁, 𝜋₂) will recover pk_u successfully due to the correctness of the algorithm.

Since 𝑅₁, 𝑅₂ are computed by the hash function, and uniquely fixes 𝑇₁ and 𝑇₂ as the only valid security tags in the two transactions. To deviate from these tags during Spend, 𝒜 must concoct the proof Φ which happens with negligible probability (which has been discussed in Balance).

Recall that Identify can output the public key of double-spender pk_U along with proof ∏_𝐺 that he has double-spent coin S. Since the essence of VerifyGuilt is to run the algorithm Identify again, and then compare the output and pk_𝒰 given as input and VerifyGuilt will always accept the output of Identify.

5.3. Anonymity of users

The simulator 𝒮 inputs the global parameters, some additional information auxsim, and capacity of a valid wallet 𝑛. 𝒮 is controlled by the random oracle and the input-output model to the adversary 𝒜. 𝒮 executes Spend protocol with 𝒜 as follows:

1. 𝒜 proves knowledge of his secret key sk to 𝒮.

2. 𝒮 receives inf 0∈{0,1}* and the transaction information, then computes 𝑅 ∈ ℤ𝑞^∗.

3. 𝒮 chooses values 𝑢, 𝑠, 𝑡𝜖ℤ_𝑞 randomly and selects J within [0, n), then computes the serial number 𝑆 and the security tag 𝑇.

4. 𝒮 sends 𝒜 the coin (𝑆, 𝜋),where 𝜋 = (𝑅, 𝑇, Φ), and Φ is a simulated validity proof which is constructed as follows:

(a)A = PedCom(𝑢) 𝐵 = PedCom(𝑠), 𝐶 = PedCom(𝑡) and a simulated signature proof that 𝒮 knows the values (u, s, t) signed by the bank. (𝒮 invokes the simulator in CL Signature).

(b) a proof Γ that 𝑆 and 𝑇 are computed correctly as (7) and (8).

Observe that the invoked simulator handles the difficulty of 𝒮′𝑠 job.

We now explain why 𝒜 is unable to distinguish between the output of 𝒮 and that of a real user. First, 𝒜 did not learn anything meaningful about (u, s, t) in the Withdraw protocol due to the security of CL signature. Thus, 𝒜 cannot distinguish between s and t chosen by 𝒮 and those chosen by the user. Due to security of the DYPRF[17], 𝒮 and T generated by 𝒮 are computationally indistinguishable from the elements in 𝐺, and thus, equally to those generated by real users with any valid value 𝐽. Finally, the only difference between 𝒮′𝑠 Φ and that of a real user is the simulated signature proof. However, we construct this proof by running CL Signature, so 𝒜 distinguishes between Game R and Game I with negligible probability based on the bilinear map under the assumption called LRSW.

5.4. Anonymity of merchants

Suppose that the simulator has a received coin(𝑆, 𝜋). We consider the anonymity of merchants in Spend, and Transper protocols. The Simulator executes Spend and Transper with 𝒜 as follows:

1. 𝒮 randomly chooses 𝑢 ∈ ℤ_𝑞, then sends the simulated signature and a simulated proof of knowledge from ℬ.

2. 𝒮 sends an optional transaction string info.

3. 𝒮 receives the coin (𝑆, 𝜋).

4. 𝒮 sends the simulated signature proof and the coin (𝑆, 𝜋) to the bank.

5. 𝒮 selects random value 𝑠’, 𝑡 ∈ ℤ_𝑞 and sends ℬ a commitment (3). ℬ sends a random 𝑟’ ∈ ℤ_𝑞 and 𝒮 computes 𝑠 = 𝑠’ + 𝑟’. 𝒮 and ℬ locally compute (4).

6. 𝒮 runs the CL signature protocol with ℬ and obtains ℬ’s signature.

7. 𝒮 saves the wallet 𝑊 = (sku, 𝑠, 𝑡, 𝜎).

Observe above that the only difference between the output of 𝒮 and that of a real merchant is the simulated proof. However, we ran the CL signatures to make the 𝒜 can’t distinguish the simulated one or the real one. So 𝒜 distinguishes between Game R and Game I with only negligible probability under LRSW assumption.

5.5. Exclupability

The exclupability definition requires that no adversary could produce a serial number and a proof of guilt to slander an honest as a double-spender (i.e., VerifyGuilt accepts the serial number and the proof with negligible probability).

Recall that the proof ∏ = (𝜋₁, 𝜋₂) for coins (𝑆, 𝜋₁) and (𝑆, 𝜋₂) is guilt of the user pk_u. And any valid 𝜋, involves the proof to prove the knowledge of the user’s secret key sk_u with different randomized signature. If 𝒜 wants to win, there are two situations need to be discussed as follows: (1)𝒜 is successful at producing a false ∏ or (2) if (𝑆, 𝜋₁) and (𝑆, 𝜋₂) are both valid coins of different users. In the first instance, 𝒜 successfully concocts a false proof ∏ means that 𝒜 can forge the underlying proof of knowledge which happens with only negligible probability; And in the second instance, that means (𝑆, 𝜋₁) and (𝑆, 𝜋₂) are registered to different users which we have discussed in section 5.2. And VerifyGuilt will deny the user with pk_u as input is a double-spender, because the Identify algorithm will recover a valid public key same as pk_u with negligible probability. Thus 𝒜 wins with only negligible probability.

6. Efficiency Analysis

6.1. Storage Efficiency of E-Cash Systems

The storage cost of different E-Cash schemes are presented in this section. In order to put all schemes at the same security level, we require the order of the cyclic group G is 1024- bit in [1] and [8]. The prime order p of 𝐺₁ and 𝐺₂ in bilinear map is 160-bit in [1], [25] and our scheme. we select 𝑙 = 10 in [1], [8]and our scheme. For more intuitive comparison, we put total storage space of each protocol in Table 1.

Table 1. Storage Space Comparison

l: the coin counter’s bit quantity; x: in bilinear groups it is 160, and in RSA group, it is 1024; n: denotes how many parts one coin can be divided into. -: not available.

6.2. Computation Efficiency of E-Cash Systems

Bilinear pairings and multi-based exponentiations of each protocol are listed in the Table 2, which are the main computation operations in E-cash scheme. In order to compare different schemes conveniently, slight computations are neglected uniformly. To evaluate the time required for each protocol, we test the time of bilinear map and single-based exponentiation using the JAVA programming language with the JPBC Library (jpbc-2.0.0). All tests are implemented on a laptop computer with the following features: (1) CPU: AMD Ryzen 5 4600U; (2) Physical Memory: 16GB; and (3) OS: Windows 10

Table 2. Computation Cost Comparison

M: multi-based exponentiation operation; P: bilinear pairing maps; -: not available; k: is a system parameter, which denotes the cheating probability 2^−k at most; n: how many parts one coin can be divided into; l: the coin counter’s bit quantity.

We test the single-based exponentiation 30 times, and take the average 0.965 ms. And the bilinear map is also tested 30 times, the average value is about 7.608 ms. And if the algorithm is well constructed, it will not take far more time to compute the multi-based exponentiation than the single-based exponentiation[8]. And normally a multi-based exponentiation takes only 10 more percent time if the multi-exponentiation multiplies up to 3 exponentiations. So, it can be evaluated that the time of one multi-based exponentiation operation is about 1.061ms. So, we can simply calculate the time of each protocol in our scheme without considering other negligible computations and communication time. The evaluated time of each protocol is in Table 3.

Table 3. Evaluated time of each protocol in our scheme

6.3. Comparison among E-Cash Systems

The comparison among the E-cash schemes is presented in the Table 4, and we can see that our scheme, [22] and three systems in [1] are all compact E-cash schemes and the computation complexity of wallet is all 𝒪(1) or 𝒪(𝑘). Compared with [8] and System I and System II in [1], our scheme cannot trace double-spender’s unspent coins efficiently, but its unique properties makes it also competitive which are:

1. the merchants can keep anonymous;

2. the coin received can be converted into a new coin anonymously without the merchant’s account.

Table 4. The Function Comparison among E-Cash Schemes

-: not available; k: the security parameter, which means the cheating probability is 2^−k at most; n: how many parts which one coin can be divided into.

7. Conclusion

After studying a lot of literature, we notice that no previous research pay attention to the privacy of merchants in E-cash system. So, we introduce the concept of double-blind to make both users and merchants anonymous. And based on the anonymity of merchants, the merchant can transfer the coin he received into a new coin for next spending without revealing the account to the bank. The proposed compact E-cash scheme satisfies Balance, Identifying double-spender, Anonymity of users and merchants and Exculpability under LRSW and y-DDHI assumption. Our solution to the privacy protection of merchants is also useful for other similar E-cash schemes, such as divisible E-cash and transferable E-cash.

Appendix