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]
(𝑞, 𝑔1, ℎ1, 𝐺1, 𝑔2, ℎ2, 𝐺2, 𝐺, 𝑒) 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. 𝐺1, 𝐺2 are groups of prime order 𝑞 = Θ(2𝑘);
2. each group has two generators where 𝐺1 = 〈𝑔1〉 = 〈ℎ1〉 and 𝐺2 = 〈𝑔2〉 = 〈ℎ2〉.
3. 𝜓 is a isomorphism from 𝐺2 to 𝐺1, where 𝜓(𝑔2) = 𝑔1 and 𝜓(ℎ2) = ℎ1;
4. 𝑒 is a bilinear map: 𝐺1 × 𝐺2 → 𝐺. The properties are as follow:
(Bilinear) for all 𝑔1 ∈ 𝐺1, 𝑔2 ∈ 𝐺2, and 𝑎, 𝑏 ∈ ℤ𝑞, 𝑒(𝑔1𝑎, 𝑔2𝑏) = 𝑒(𝑔1, 𝑔2)𝑎𝑏;
(Non-degenerate) if 𝑔1 is a generator of 𝐺1 and 𝑔2 is a generator of 𝐺2, then 𝑒(𝑔1, 𝑔2) 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 𝑥 ≡ logg𝑦(mod 𝑞) is given by choosing a random 𝑟 ∈ ℤ𝑞 and computing c and s as: 𝑐 = 𝐻(𝑔||𝑦||𝑡||𝑚) and 𝑠 = 𝑟 − 𝑐𝑥 (mod 𝑞). 𝑡 = 𝑔𝑟 is the commitment to prove the knowledge of 𝑥 ≡ logg𝑦(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 (𝑔0, ⋯ , 𝑔𝑚). In order to commit the set of values (𝑣1, ⋯ , 𝑣𝑚) ∈ ℤ𝑞𝑚, the user picks a random 𝑟 ∈ ℤ𝑞 and sets 𝐶 = 𝑔0𝑟 ∏𝑖=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 (pkS, skS). The public input of both parties is pkS. And the secret input of the user are values (𝑣1, ⋯ , 𝑣𝑚; 𝑟) such that 𝐶 = PedCom(𝑣1, ⋯ , 𝑣𝑚; 𝑟).The secret input of the signer is skS. 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(𝑣1, ⋯ , 𝑣𝑚).
2. The second protocol occurs between the user and the verifier to prove knowledge of a signature. The public input of both parties is pkS and the secret input of the user are values (𝑣1, ⋯ , 𝑣𝑚; 𝑟) and the signature 𝜎pkS(𝑣1, ⋯ , 𝑣𝑚). 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((skm, pkB), ℬ(skB, pkm)) is a protocol whose outcome is a certificate for , which represents the legality of as a payee.
● Withdraw(𝒰(sku, pkb, 2𝑙), ℬ(sku, pkb, 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 pku.
● Spend(𝒰(𝑊, pkb, 𝜎𝑚𝑟), (skm, pkb, 𝜎𝑚, 𝜎𝑢𝑟)) 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((skm, 𝑆, 𝜋, pkb), ℬ(skb, 𝜎𝑚𝑟)) 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((skm, 𝑆, 𝜋, pkb), ℬ(skb, 𝜎𝑚𝑟)) 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, 𝑆, 𝜋1, 𝜋2) is an algorithm to identify the double-spender with S and two validity proofs, 𝜋1 and 𝜋2. The output of this algorithm consists of a public key pku and a proof ∏𝐺.
● VerifyGuilt(𝑆, pku, ∏𝐺) is an algorithm to verify the proof ∏𝐺 to prove that the user whose public key is pku 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 m1 denote the message sent from 𝒰 to ℬ which can identify himself and b1 denote the state of the bank when m1 received. The balance property requires that:
1. There exists an efficiently decidable language 𝑙𝑆 and an extractor ℰProt,𝑙𝑋−𝑌(𝐴) (𝑏1, 𝑚1) for all b1 m1, it extracts 𝑤 = (𝑆1, … , 𝑆𝑛, aux), where n denotes the capacity of the wallet. Such that (b1, m1, 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, pkB), 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 (𝑏1, 𝑖, 𝑚1, 𝐼, 𝑤𝑖) ∈ 𝑙𝑆 be the output of ℰProt,𝑙𝑋−𝑌(𝐴)(pki, 𝑏1,𝑖, 𝑚1,𝑖) if the ith Withdraw or Transfer protocol. Recall that 𝑤𝑖 =(𝑆𝑖,1, … , 𝑆𝑖,𝑛, aux) is a set of n serial numbers belong to pki, 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 pkB, 𝒜 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 pki 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 pkU 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 pkB issues the following queries:
PK of I: 𝒜 requests and received the public key of user 𝒰, generated as (pku, sku).
Withdraw with I: 𝒜 executes the Withdraw protocol with 𝒰:
Withdraw(𝒰(pkB, sku, 𝑛), 𝒜(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 pkB issues the following queries:
PK of M: 𝒜 requests and receives the public key of merchant , generated as (pkm, skm)
Sign with M: 𝒜 executes the Sign protocol with :
Sign((pkB, skm), 𝒜(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((pkB, skm, 𝜋), 𝒜(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 (pku, sku). The adversary gets the bank’s public key pkB.
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:
𝐺1 = 〈𝑔1〉 = 〈ℎ1〉 and 𝐺2 = 〈𝑔2〉 = 〈ℎ2〉, 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 𝑒: 𝐺1 × 𝐺1 → 𝐺2.
𝐺 = 〈𝑔〉 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 (pkB, skB) for CL signature, and the forms are as follows:
skB: 𝑥 ← 𝑍𝑞, 𝑦 ← 𝑍𝑞, 𝑧𝑖 ← 𝑍𝑞, 1 ≤ 𝑖 ≤ 3
pkB: 𝑋 = 𝑔1𝑥, 𝑌 = 𝑔1𝑦, 𝑍𝑖 = 𝑔𝑖𝑧𝑖, 1 ≤ 𝑖 ≤ 3
In Ukeygen(1𝑘, 𝜁), 𝒰 generates a unique key pair (pk𝒰, sk𝒰) = (𝑔1𝑢, 𝑢) for random 𝑢𝜖ℤ𝑞. Recall that merchants can be seen as special users and also generates a unique key pair (pk, sk) = (𝑔1𝑚, 𝑚) 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 skm. 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 skm. 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 (sku, 𝑠, 𝑡, 𝜎, 𝐽), where 𝜎𝑢 denotes the signature on (sku, 𝑠, 𝑡) from the bank and J is the coin counter with l bits. In the process of interaction, the bank cannot learn anything about (sku, 𝑠, 𝑡). The interactions between the user 𝒰 and the bank ℬ are following:
1. 𝒰 proves the knowledge of sku to ℬ for identifying himself.
2. 𝒰 selects random value 𝑠', 𝑡 ∈ ℤq and sends ℬ a commitment
𝐴′ = PedCom(sku, 𝑠′, 𝑡; 𝑟) = 𝑔1𝑟𝑍1𝑢𝑍2𝑠′𝑍3𝑡. (3)
ℬ sends a random r’ ∈ ℤq. U computes s = s’ + r’. U and ℬ respectively computes
𝐴 = 𝑍2𝑟′ 𝐴′ = PedCom(sku, 𝑟′ + 𝑠′, 𝑡; 𝑟) = PedCom(sku, 𝑠, 𝑡; 𝑟). (4)
3. 𝒰 runs the CL signature protocol with ℬ and obtains ℬ′ s signature on secret values which is:
𝜎𝑢 = (𝑎, 𝑎𝑦, 𝑎𝑥𝐴𝛼𝑥𝑦, 𝐴1, 𝐴2, 𝐴3, 𝐵1, 𝐵2, 𝐵3) (5)
4. 𝒰 saves the wallet 𝑊 = (sku, 𝑠, 𝑡, 𝜎, 𝐽), and J is initialized to zero.
5. ℬ records 2𝑙 coins for the user’s account pku.
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 skm which is:
𝜎𝑚 = (𝑎, 𝑎𝑦, 𝑎𝑥𝑀𝛼𝑥𝑦, 𝐴1, 𝐵1). (6)
2. saves the certificate 𝛿m = (skm, 𝜎𝑚).
𝛿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 skm 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 (sku, 𝑠, 𝑡, 𝜎) 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 skm 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 skm 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:
𝜎𝑚 = (𝑎, 𝑎𝑦, 𝑎𝑥𝐴𝛼𝑥𝑦, 𝐴1, 𝐴2, 𝐴3, 𝐵1, 𝐵2, 𝐵3) (9)
6. saves the wallet 𝑊 = (skm, 𝑠, 𝑡, 𝜎𝑚), here the new wallet will only contain a coin, and the bank doesn’t record the account for pkm.
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 (𝑆, 𝜋1) is in spent coin list for the number S. And the bank accepts a coin with (𝑆, 𝜋2) ,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 pku = 𝑔𝑢, then each 𝑇𝑖 constructed as (8). As the bank runs this algorithm with different R (i.e., 𝑅1 ≠ 𝑅2), 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 ∏𝐺 = (𝜋1, 𝜋2) and public key of the double-spender pkU.
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 (𝜋1, 𝜋2) and each 𝜋𝑖 as (𝑅𝑖, 𝑇𝑖, Φ𝑖), then run Identify(params, 𝑆, 𝜋1, 𝜋2) 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 𝑣1(𝑘). Case (2) happens with negligible probability 𝑣2(𝑘) due to the discrete logarithm assumption and the security of DYPRF[17]. Thus, 𝒜 wins with only negligible probability 𝑣1(𝑘)*𝑣2(𝑘).
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 𝑠1 and 𝑠2 belong to different users, such that |𝑠1 − 𝑠2| < 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 (𝑆, 𝜋1) and ( 𝑆, 𝜋2). 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 (𝑆, 𝜋1) and (𝑆, 𝜋2) for some 𝑆𝜖𝐴𝑓 and deposits them to the bank ℬ and ℬ parses each 𝜋𝑖 as (𝑅𝑖, 𝑇𝑖, Φ𝑖). Since chooses R randomly while executing Spend protocol with the user and 𝑅1 ≠ 𝑅2 with high probability. If each 𝑇𝑖 = pk𝒰𝑓𝑔,𝑡DY(𝐽 + 1)𝑅 has the same pku, 𝐽 and 𝑡, then the algorithm Identify (𝜁, 𝑆, 𝜋1, 𝜋2) will recover pku successfully due to the correctness of the algorithm.
Since 𝑅1, 𝑅2 are computed by the hash function, and uniquely fixes 𝑇1 and 𝑇2 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 pkU 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 ∏ = (𝜋1, 𝜋2) for coins (𝑆, 𝜋1) and (𝑆, 𝜋2) is guilt of the user pku. And any valid 𝜋, involves the proof to prove the knowledge of the user’s secret key sku 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 (𝑆, 𝜋1) and (𝑆, 𝜋2) 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 (𝑆, 𝜋1) and (𝑆, 𝜋2) are registered to different users which we have discussed in section 5.2. And VerifyGuilt will deny the user with pku as input is a double-spender, because the Identify algorithm will recover a valid public key same as pku 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 𝐺1 and 𝐺2 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
References
- J. Camenisch, S. Hohenberger, and A. Lysyanskaya, "Compact E-Cash," 060, 2005. Accessed: Apr. 10, 2021. [Online]. Available: http://eprint.iacr.org/2005/060
- M. H. Au, Q. Wu, W. Susilo, and Y. Mu, "Compact E-Cash from Bounded Accumulator," Topics in Cryptology - CT-RSA 2007, Berlin, Heidelberg, pp. 178-195, 2006.
- M. H. Au, W. Susilo, and Y. Mu, "Practical Compact E-Cash," in Proc. of Australasian Conference on Information Security and Privacy, pp. 431-445, 12th Australasian Conference, ACISP 2007, Townsville, Australia, July 2-4, 2007.
- M. Belenkiy, M. Chase, M. Kohlweiss, and A. Lysyanskaya, "Compact E-Cash and Simulatable VRFs Revisited," in Proc. of Pairing-Based Cryptography - Pairing 2009, pp. 114-131, Third International Conference Palo Alto, CA, USA, August 12-14, 2009.
- Q. Wang, "Compact k-spendable E-cash with anonymity control based offline TTP," International Journal of Innovative Computing, Information and Control, 7(1), 459-469, 2011.
- P. Martens, "Practical Compact E-Cash with Arbitrary Wallet Size," Cryptology ePrint Archive, 2015.
- B. Lian, G. Chen, J. Cui, and D. He, "Compact E-Cash with Practical and Complete Tracing," KSII TIIS, vol. 13, no. 7, pp. 3733-3755, Jul. 2019.
- B. Lian, G. Chen, J. Cui, and M. Ma, "Compact E-Cash with Efficient Coin-Tracing," IEEE Trans. Dependable and Secure Comput., vol. 18, no. 1, pp. 220-234, Jan. 2021. https://doi.org/10.1109/TDSC.2018.2882507
- M. H. Au, W. Susilo, and Y. Mu, "Practical Anonymous Divisible E-Cash from Bounded Accumulators," in Proc. of International Conference on Financial Cryptography and Data Security, pp. 287-301, 12th International Conference, FC 2008, Cozumel, Mexico, January 28-31, 2008.
- S. Canard and A. Gouget, "Divisible E-Cash Systems Can Be Truly Anonymous," in Proc. of Advances in Cryptology - EUROCRYPT 2007, pp. 482-497, 26th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Barcelona, Spain, May 20-24, 2007.
- W.-S. Juang and H.-T. Liaw, "A practical anonymous multi-authority e-cash scheme," Applied Mathematics and Computation, vol. 147, no. 3, pp. 699-711, Jan. 2004. https://doi.org/10.1016/S0096-3003(02)00805-6
- F. Baldimtsi, M.Chase, G. Fuchsbauer, and M.Kohlweiss, "Anonymous Transferable E-Cash," in Proc. of Public-Key Cryptography -- PKC 2015, pp. 101-124, 18th IACR International Conference on Practice and Theory in Public-Key Cryptography, Gaithersburg, MD, USA, March 30 -- April 1, 2015.
- S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," Decentralized Business Review, 21260, 2008.
- I. Miers, C. Garman, M. Green and A. D. Rubin, "Zerocoin: Anonymous Distributed E-Cash from Bitcoin," in Proc. of 2013 IEEE Symposium on Security and Privacy, pp. 397-411, 2013.
- E. Ben Sasson et al., "Zerocash: Decentralized Anonymous Payments from Bitcoin," in Proc. of 2014 IEEE Symposium on Security and Privacy, pp. 459-474, 2014.
- D. Boneh and X. Boyen, "Short Signatures Without Random Oracles," in Proc. of Advances in Cryptology - EUROCRYPT 2004, pp. 56-73, International Conference on the Theory and Applications of Cryptographic Techniques, Interlaken, Switzerland, May 2-6, 2004.
- Y. Dodis and A. Yampolskiy, "A Verifiable Random Function with Short Proofs and Keys," in Proc. of Public Key Cryptography - PKC 2005, pp. 416-431, 8th International Workshop on Theory and Practice in Public Key Cryptography, Les Diablerets, Switzerland, January 23-26, 2005.
- J. Camenisch and A. Lysyanskaya, "Signature Schemes and Anonymous Credentials from Bilinear Maps," in Proc. of Advances in Cryptology - CRYPTO 2004, pp. 56-72, 24th Annual International Cryptology Conference, Santa Barbara, California, USA, August 15-19, 2004.
- D. Boneh, B. Lynn, and H. Shacham, "Short Signatures from the Weil Pairing," in Proc. of Advances in Cryptology - ASIACRYPT 2001, pp. 514-532, 7th International Conference on the Theory and Application of Cryptology and Information Security Gold Coast, Australia, December 9-13, 2001.
- J. Camenisch, "Group signature schemes and payment systems based on the discrete logarithm problem," Ph.D. dissertation, Dept. Tech. Sci., ETH Zurich., Swiss, Switzerland 1998.
- F. Boudot, "Efficient Proofs that a Committed Number Lies in an Interval," in Proc. of Advances in Cryptology - EUROCRYPT 2000, pp. 431-444, International Conference on the Theory and Application of Cryptographic Techniques Bruges, Belgium, May 14-18, 2000.
- G. Ateniese, J. Camenisch, M. Joye, and G. Tsudik, "A Practical and Provably Secure Coalition-Resistant Group Signature Scheme," in Proc. of Advances in Cryptology - CRYPTO 2000, pp. 255-270, 20th Annual International Cryptology Conference Santa Barbara, California, USA, August 20-24, 2000.
- T. P. Pedersen, "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing," in Proc. of Advances in Cryptology - CRYPTO '91, pp. 129-140, 1992.
- J. Camenisch and A. Lysyanskaya, "A Signature Scheme with Efficient Protocols," in Security in Communication Networks, pp. 268-289, Third International Conference, SCN 2002 Amalfi, Italy, September 11-13, 2002.
- S. Canard, D. Pointcheval, O. Sanders, and J. Traore, "Divisible e-cash made practical," IET Information Security, vol. 10, no. 6, pp. 332-347, Nov. 2016. https://doi.org/10.1049/iet-ifs.2015.0485