Ring Signatures Monero Oct. 14, 2019 Overview Privacy Hierarchy - PowerPoint PPT Presentation

Ring Signatures Monero Oct. 14, 2019

Overview • Privacy Hierarchy • Monero • Secretly signing a transaction • Secretly receiving a transaction

Privacy Hierarchy Everything open Bitcoin Pseudonymous, amount open

Privacy Hierarchy Everything open Bitcoin Pseudonymous, amount open MimbleWimble Pseudonymous, amount secret

Privacy Hierarchy Everything open Bitcoin Pseudonymous, amount open MimbleWimble Pseudonymous, amount secret Pseudonymous, amount open CoinJoin miner/coordinator does not know input output

Privacy Hierarchy Everything open Bitcoin Pseudonymous, amount open MimbleWimble Pseudonymous, amount secret Pseudonymous, amount open CoinJoin miner/coordinator does not know input output amount open, transaction un-linkable Monero Secret receive/secret sending

Privacy Hierarchy Everything open Bitcoin Pseudonymous, amount open MimbleWimble Pseudonymous, amount secret Pseudonymous, amount open CoinJoin miner/coordinator does not know input output amount open, transaction un-linkable Monero Secret receive/secret sending ZCash, ZeroCash, ZeroCoin amount secret, transaction un-linkable

Monero • Anonymously receiving • Address is created from public key • Not possible to link target address to public key • Anonymous sending • Owner selects an anonymity set 𝒯 = { T 1 , T 2 , …, T n } • Shows that one in signed the transaction 𝒯

Anonymous Sending • Sending a transaction is one with a one-time ring-signature • o ne-time : signing a transaction more than once with the same key can be detected: Prevents double spend • ring-signature : Given a set of public keys, show that one of the corresponding private keys signed it

Ring signature tx 9: (__, pk) tx 10: tx 2: tx 4: (__, pk) (__, pk) (__, pk) tx 1: tx 5: tx 12: (__, pk) (__, pk) tx 3: (__, pk) (__, pk) tx 8: tx 7: (__, pk) (sk, pk) tx 6: tx 13: tx 11: (__, pk) (__, pk) (__, pk)

Ring signature tx 9: (__, pk) tx 10: tx 2: tx 4: (__, pk) (__, pk) (__, pk) tx 1: tx 5: tx 12: (__, pk) (__, pk) tx 3: (__, pk) (__, pk) tx 8: tx 7: (__, pk) (sk, pk) tx 6: tx 13: tx 11: (__, pk) (__, pk) (__, pk)

Ring signature tx 3: tx 4: tx 5: tx 7: (__, pk) (__, pk) (__, pk) (sk, pk) tx 8: tx 10: tx 12: tx 13: (__, pk) (__, pk) (__, pk) (__, pk) document sign ( document , sk , { pk 3 , pk 4 , …, pk 13 }) Signature

Ring signature pk 3 pk 4 pk 5 pk 7 pk 8 pk 10 pk 12 pk 13 document verify ( document , s , { pk 3 , pk 4 , …, pk 13 }) {True, False} Signature

Ring Signature • A signature that uses an anonymity set of public keys • The signer hides his/her identity in this set • Verifier can check whether someone of that set signed it • Verifier cannot identify who exactly signed it • Possible application: whistleblowing

Single ECC signature • common group element G • public/private key P = pG • Signature are 2 numbers s = ( c , d ), { c , d } ∈ ℤ • verify via c = ℋ ( document | G | cP + dG )

Single ECC signature • common group element , public/private key G P = pG • s = ( c , d ), { c , d } ∈ ℤ • verify via c = ℋ ( document | G | cP + dG ) same value

Single ECC signature • common group element G • public/private key P = pG • sign: • random r c = ℋ ( document | G | rG ) • • rG = ( cp + d ) G ⇒ d = r − cp c = ℋ ( document | G | cpG + dG ) c = ℋ ( document | G | cP + dG )

2 element ECC ring signature • common group element G • public keys { P 1 , P 2 } • signature s ring 2 = ( c 1 , c 2 , d 1 , d 2 ) c 1 + c 2 = ℋ ( document | G | c 1 P 1 + d 1 G | c 2 P 2 + d 2 G ) • Signer knows one of the private keys of { P 1 , P 2 }

2 element ECC ring signature • common group element G • own public/private key , other person’s key P 1 = p 1 G P 2 • sign: • random r , c 2 , d 2 c = ℋ ( document | G | rG | c 2 P 2 + d 2 G ) • • c 1 = c − c 2 ⇒ c 1 + c 2 = ℋ ( . . . ) rG = ( c 1 p 1 + d 1 ) G ⇒ d 1 = r − c 1 p 1 • c 1 + c 2 = ℋ ( document | G | c 1 p 1 G + d 1 G | c 2 P 2 + d 2 G )

General ECC ring signature • common group element G • public keys { P 1 , P 2 , …, P n } • signature s ring 2 = ( c 1 , c 2 , …, c n , d 1 , d 2 , …, d n ) c i = ℋ ( document | G | c 1 P 1 + d 1 G | … | c n P 2 + d n G ) ∑ i • Signer knows one of the private keys of { P 1 , P 2 , …, P n }

General ECC ring signature • common group element G • own public/private key , other keys P i = p i G P j • sign: • random (except ) r , c 1 , c 2 , …, c n , d 1 , d 2 , …, d n c i , d i c = ℋ ( document | G | c 1 P 2 + d 1 G | … | rG | … | c n P n + d n G ) • c i = c − ∑ c k ⇒ ∑ c k = ℋ ( . . . ) • k : k ≠ i k rG = ( c i p i + d i ) G ⇒ d i = r − c i p i • c i = ℋ ( document | G | … | … | ( c i p i + d i ) G | … | … ) ∑ i

ECC Ring Signature • We have now a method to sign a message anonymously • We pick a set of public keys • The verifier can not determine who exactly signed it • It only knows “one of this group”, but not more

One-Time ECC Ring Sign. • Assuming we have one key for each transaction • We can send a transaction • No one knows which one was send • We can show that it was valid • What keeps us from double spending? • If no one knows which transaction was send, why not send it twice

Unique Element: Key Image • We add values to the signature to detect double spending • Public/private key p , pG = P • Compute the “ key image ” I = p ℋ ( P ) ∈ ℤ • This value is unique to each key I • Given , neither the private key, nor the public key can I be inferred

Unique Element: Key Image • Public/private key , “ key image ” p , pG = P I = p ℋ ( P ) ∈ ℤ • Signature: • s = ( I , c 1 , c 2 , …, c n , d 1 , d 2 , …, d n ) • For each public key: • L i = c i P i + d i G • R i = c i I + d i ℋ ( P i ) ∑ c i = ℋ ( document | G | I | L 1 | L 2 | … | L n | R 1 | R 2 | … | R n )

One-Time ECC Ring Sign. • Create the signature (similar to before): • Random value for own public key r • L own = rG • R own = rI • Random for all other public keys c i , d i P i • L i = c i P i + d i G • R i = c i I + d i ℋ ( P i )

One-Time ECC Ring Sign. • Given: • L i = c i P i + d i G R i = c i I + d i ℋ ( P i ) • L own = rG R own = rI c = ℋ ( document | G | I | L 1 | … | L n | R 1 | … | R n ) • c own = c − ∑ c i d own = r − c own p • i • L own = c own P + d own G

One-Time ECC Ring Sign. • Signature: • s = ( I , c 1 , c 2 , …, c n , d 1 , d 2 , …, d n ) • Verify via • L i = c i P i + d i G R i = c i I + d i ℋ ( P i ) = ℋ ( document | G | I | L 1 | … | L n | R 1 | … | R n ) ? ∑ c i i

One-Time ECC Ring Sign. • s = ( I , c 1 , c 2 , …, c n , d 1 , d 2 , …, d n ) = ℋ ( document | G | I | L 1 | … | L n | R 1 | … | R n ) ? ∑ c i • i • Properties: • Given a valid signature, we can not infer which private key was known • The key image is tied to the private key I • Two separate signatures using the same private key need to use the same key image I

One-Time ECC Ring Sign. Summary • A user choses an anonymity set of public keys • Signs a transaction, so that • It is impossible to identify who signed it • Signing more than once with same private key can be detected • If each transaction has its own public/private key, we can detect double-spending

Monero • Anonymously receiving • Address is created from public key • Not possible to link target address to public key • Anonymous sending • Owner selects an anonymity set 𝒯 = { T 1 , T 2 , …, T n } • Shows that one in signed the transaction 𝒯

Anonymous receiving • Create a unique address from a user’s public key • No outside observer can link the address with the key • User can identify which payment are send to him/her pk money that is for f(pk,r) me! (r) ? (sk, pk)

Keys in Monero • Each user has an address template, consisting of 2 keys • ( private key ) a , b ∈ ℤ a ≠ b • ( public key ) ( aG , bG ) = ( A , B ) • ( tracking key ) ( a , B )

Receiving Money • Alice wants to send money to Bob • random value, one-time public key r R = rG • one-time public key as address P = ℋ ( rA ) G + B • Alice sends transaction Amount : 1234 XMR Public key: R Address : P

Receiving Money • Alice wants to send money to Bob • Alice creates P = ℋ ( rA ) G + B • Bob sees Amount : 1234 XMR Public key: R Address : P • and can check if P = ℋ ( aR ) G + B • His key ( a , b ), ( aG , bG ) = ( A , B )

Receiving Money • Alice creates P = ℋ ( rA ) G + B • Bob’s key: ( a , b ), ( aG , bG ) = ( A , B ) Alice can create this P = ℋ ( rA ) G + B = ℋ ( raG ) G + B = ℋ ( arG ) G + B = ℋ ( aR ) G + B Bob can create this

Receiving Money • Alice creates P = ℋ ( rA ) G + B = ℋ ( aR ) G + B • Bob can detect payments directed to him • No one else can see that this is a payment for Bob