1 / 12

Combating Double-Spending Using Cooperative P2P Systems

Combating Double-Spending Using Cooperative P2P Systems. Author : Ivan Osipkov , Eugene Y. Vasserman , Nicholas Hopper , Yongdae Kim Source : International Conference on Distributed Computing Systems, 25-27 June 2007,page 41-50 Presenter : Hsiao-Chi Chiang ( 江小琪 )

hadley-franco
Download Presentation

Combating Double-Spending Using Cooperative P2P Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Combating Double-Spending Using Cooperative P2P Systems Author :Ivan Osipkov , Eugene Y. Vasserman , Nicholas Hopper , Yongdae Kim Source : International Conference on Distributed Computing Systems, 25-27 June 2007,page 41-50 Presenter : Hsiao-Chi Chiang(江小琪) Date : 2010/10/15

  2. Outline Introduction E-cash system Algorithm Security Complexity Experiment result Conclusions

  3. Introduction • Goal • Introduces a new peer-to-peer system architecture to prevent double-spending without requiring an on-line trusted party or tamper-resistant software or hardware. • Scenario • This system design is a three-party model,with • the broker as a dedicated (but not necessarily on-line) server • the merchant as a drop-in module for an existing web server • the client as a browser plug-in

  4. E-cash system Merchant 1 Client C (3)Certify e-coin C E-cash aware Witness 1 Mc (1)Withdraw e-coin(s) C (4)Sign payment transcript (2)Buy with e-coin C Merchant 2 M (5)Redeem payment transcript(s) Broker B Witness 2 Cash transactions Bank E-cash unaware

  5. Protocol • Operations with e-cash involve three protocols: • withdrawal • payment • Deposit (1) Let q be two large primes (2) g be a random generator of order q (3) ˂g˃ is subgroup generated by g (4) let g 1 and g 2 be two random generators of ˂g˃ (5) B chooses a secret key x and publishes the authenticated key y = g x

  6. Algorithm 1-Withdrawal Protocol Broker B Client C (0)Publish SigB(version/date , {IMc , r Mc,1 , rMc,2}) (1) Send a, b • 1.Choose: • random ti , i=1,…,4 • and x1,x2,y1,y2 • 2.Compute: • α=agt1yt2 , β=bgt3 z t4 • ϵ = Η(α||β||z|| A ||B) • A = g1x 1g2x 2, B = g1y 1g2y 2 • e = ϵ-t2-t4 mod q a=gu , b=gs Zd random u,s,d Z=Ƒ(info) (1) (2) Send e (2) c = e-d mod q r = u-cx mod q x= secret key (3) (3) Send ( r , c , s ) • Client Compute ρ = r+t1 mod q • ω= c+ t2 mod q • σ = s+t3 mod q • δ = e-c+t4 mod q • Check equality ω+δ=ϵ= Η(gρyω||gσzδ|| z || A ||B) mod q • The bare coin = ( ρ , ω , σ , δ , A ,B ) • Attaches the SigB(version/date , {IMc , r Mc,1 , rMc,2}) • C = ( ρ , ω , σ , δ , A ,B , SigB(version/date , {IMc , r Mc,1 , rMc,2}))

  7. Algorithm 2-Payment Protocol Client C Witness Mc Merchant M (1) (2) Coin_hash= h ( ρ , ω , σ , δ , info, A ,B ) nonce =h(salt c ||IM ) , salt c is random IMis the identify of the merchant (1) (coin_hash , nonce) v is either some random value, or tuple (x 1 , x 2 ) or (y 1 , y 2 ) r1=x1+d‧y1 r2=x2+d‧y2 d=Ho(C,IM,data/time) M check witness, commitment, nonce and A‧Bd=g1r1‧g2r2 (3) (2) SigMc(coin_hash , nonce , h(ν) , te , commit ) (3) Payment transcript = ( C , r1, r2 , IM , data/time) SigMc (coin_hash , nonce , h(ν) , te, commit ) salt c (4) Mccheck payment transcript check nonce =h(salt c ||IM ) (4) Payment transcript = ( C , r1, r2 , IM , data/time , salt c) (5) SigMc ( payment transcript )or (x1,x2) and/or (y1,y2) or refuse (6) Service , (x1,x2) and/or (y1,y2)

  8. Algorithm 3-Deposit Protocol Merchant M Broker B (1)Send payment transcript , SignMc (payment transcript ) Payment transcript = ( C , r1, r2 , IM , data/time , salt c) C = ( ρ , ω , σ , δ , A ,B , SigB(version/date , {IMc , r Mc,1 , rMc,2})) B verifies its own signature on the coin B verifies the signature of the witness on the payment, computes d and checks the A‧Bd=g1r1‧g2r2 (2) B searches its database to determine if the bare coin = (ρ, ω, σ, δ, info, A, B) has previously been deposited.

  9. Security • If the client knows a representation of A (B) : • 1) the client actually constructed the coin. • 2) the client knows no other representation of A (B). • we can make the following conclusions: • 1) only the coin owner can successfully make a payment. • 2) a payment transcript does not allow one to generate another payment transcript. • 3) if the coin owner double-spends, the representation of A and/or B can be extracted which serves as a definitive proof of double-spending.

  10. Complexity Table.1 Number of cryptograghic operations +2 -1

  11. Experimental Result Table 2. Wall-clock runtime and bandwidth for payment protocol over 100 trials An informal survey of a popular ad-supported web site shows that it serves up 37.13KB in two ad images and associated links for the main page. The client and broker were located in Wisconsin, the witness in California, and the merchant in Massachusetts.

  12. Conclusions A framework for anonymous e-cash that prevents double-spending without an online trusted authority or special-purpose hardware. If the coins are stolen, the damage to the client will consist only of the value of the stolen coins.

More Related