Outline Cryptography for voting CSci 5271 Previous e-cash and - PDF document

Outline Cryptography for voting CSci 5271 Previous e-cash and techniques Introduction to Computer Security Announcements intermission Day 25: Electronic cash and Bitcoin Stephen McCamant Bitcoin design University of Minnesota, Computer Science & Engineering Bitcoin experience End-to-end integrity and verification Commitment to values Two phases: commit, later open Another analogy to a use of envelopes Tabulation cannot be 100% public Binding property: can only commit to a But how can we still have confidence in single value it? Hiding property: value not revealed until Cryptography to the rescue, maybe opened Techniques from privacy systems, others Trivia: either binding or hiding, but not Adoption requires to be very usable both, can be perfect Information-theoretic, like a one-time pad Randomized auditing Election mix-nets Independent election authorities similar to remailers or Tor nodes How can I prove what’s in the envelope Onion-encrypt ballot, each authority without opening it? shuffles and decrypts ♥ envelopes, you pick one and open Extra twist: prove no ballots added or the rest removed, without revealing permutation Chance ✶❂♥ of successful cheating Instance of “zero-knowledge proof” Better protection with repetition Privacy preserved as long as at least one authority is honest

Pattern voting attack Fun tricks with paper: visual crypto Want to avoid trusted client, but voters Widely applicable against techniques can’t do computations by hand that reveal whole (anonymized) ballots) Even a single race, if choices have Analogues to crypto primitives using enough entropy physical objects 3-choice IRV with 35 candidates: 15 bits One-time pad using transparencies: Buyer says: vote first for Bob, then 2nd and 3rd for Kenny and Xavier Chosen so ballot is unique Scantegrity II Outline Cryptography for voting Designed as end-to-end add-on to optical scan system Previous e-cash and techniques Fun with paper 2: invisible ink Announcements intermission Single trusted shuffle Checked by random audits of Bitcoin design commitments Version used in a DC-suburb municipal Bitcoin experience election Kinds of Internet payments Ideal: electronic cash Credit/debit cards: most popular Direct transactions without third party Wide adoption among consumers, little consumer fraud liability No transaction fees Restrictive merchant procedures Potentially anonymous PayPal Non-revocable: buyer bears fraud risk Easier to accept payments Centrally managed to deal with fraud

Micropayments Blinded signatures Claim: what the web needs is small Sign something without knowing its payments to support content value Too small for existing mechanisms Often used together with randomized One idea (Peppercoin): simulate small auditing payment with small probability of larger For RSA, multiple message by r ❡ , r payment random Actual market for micropayments has Allows a bank to “mint” coins that can been small still be anonymous Most buyers and sellers prefer free + other revenue Challenge: double spending Puzzles / proof-of-work Computational problem you solve to Any purely electronic data can be show you spent some effort duplicated, including electronic money Common: choose s so that ❤ ✭ ♠ ❦ s ✮ Can’t allow two copies to both be spent starts with many 0 bits Shows ideal no-third-party e-cash can’t For instance, required solved puzzles be possible can be a countermeasure against DoS Hashcash and spam Hash trees and timestamp services Merkle tree: parent node includes hash Idea: use proof of work to solve email of children spam problem Good hash function ✦ root determines Puzzle based on date and recipient whole tree Legitimate users send only a few messages Can prove value of leaf with log-sized Problem 1: mailing lists evidence Problem 2: spam botnets Application: document timestamping Never caught on (commitment) service

Outline HW2 due Sunday Cryptography for voting Non-early due date: 11:55pm this Previous e-cash and techniques Sunday Announcements intermission Q5 performance/load issues Avoid by not doing Q5 at the last minute, Bitcoin design testing on yourself Bitcoin experience Group project presentations Project progress reports Monday Start Monday, run next two weeks Due Monday 11:55pm Plan 12 minute presentation plus 3 Progress meetings next week will minutes Q&A mostly be after One student per group presents Email to start the conversation early Slides, BYO laptop recommended Outline Bitcoin addresses Cryptography for voting Address is basically a public/private signing key pair Previous e-cash and techniques Randomized naming, collision unlikely At any moment, balance is a perhaps Announcements intermission fraction number of bitcoins (BTC) Bitcoin design Anyone one can send to an address, private key needed to spend Bitcoin experience

Global transaction log Bitcoin network Use peer-to-peer network to distribute Basic transaction: Take ① ✶ from ❛ ✶ , ① ✷ transaction log from ❛ ✷ , . . . , put ② ✶ in ❛ ✵ ✶ , ② ✷ in ❛ ✵ ✷ , . . . Of course require P ✐ ① ✐ ❂ P ❥ ② ❥ Roughly similar to BitTorrent, etc. for Keep one big list of all transactions old data ever Once a client is in sync, only updates need to be sent Check all balances in addresses taken from are sufficient New transactions sent broadcast Consistency and double-spending Bitcoin blocks If all clients always saw the same log, Group ✘ 10 minutes of latest double-spending would be impossible transactions into one “block” But how to ensure consistency, if Use a proof of work so creating a block multiple clients update at once? is very hard Symmetric situation: me and “me” in All clients race, winning block Australia both try to spend the same propagates $100 at the same time Bitcoin blockchains Regulating difficulty Difficulty of the proof-of-work is Each block contains a pointer to the adjusted to target the 10 minute block previous one frequency Clients prefer the longest chain they Recomputed over two-week (2016 know block) average E.g., inconsistency usually resolved by Network adjusts to amount of next block computing power available

Bitcoin mining Outline Cryptography for voting Where do bitcoins come from originally? Previous e-cash and techniques Fixed number created per block, Announcements intermission assigned by the client that made it Incentive to compete in the block Bitcoin design generation race Bitcoin experience Called mining by analogy with gold Where Bitcoin came from Current statistics Block chain 271,000 blocks, about 14GB Paper and early implementation by 12M BTC minted (many presumed lost) Satoshi Nakamoto Theoretical value at market exchange Generally presumed to be a pseudonym rate ❃ $1 billion “Genesis block” created January 2009 Millions of addresses, probably many Containing headline from The Times (of London) about a bank bailout fewer users Mining power: 5 petahash/sec What can you buy with Bitcoin? Bitcoin as a currency Can be exchanged for dollars, etc. Random stuff from many small online Currently pretty cumbersome retailers In some ways more like gold than fiat Novelty/trials of some in-person currencies purchases No central authority Donations to like-minded non-profits Price changes driven more by demand than supply Illegal drugs (Silk Road successors) Exchange rate trend: volatile but Murder for hire: currently probably a upward fraud

Deflation and speculation Bitcoin mining trends Some people want bitcoins to spend on Exponentially increasing rates purchases Demand based on “velocity” CPU ✦ GPU ✦ FPGA ✦ ASIC Supply does not keep up with interest Specialized hardware eclipsing general So, value of 1 BTC has to go up purpose Others want bitcoins because they Including malware and botnets think the price will go up in the future Recent price trends suggest continuing Self-fulfilling prophecy investment But vulnerable to steep drops if expectations change Enforcing consistency Stealing bitcoins Structure of network very resistant to Bitcoins are a very tempting target for protocol change malware Inertia of everybody else’s code Private keys stored directly on client Changes unpopular among miners will machines Theft is non-reversible not stick Much easier than PayPal or identity theft Minor crisis in March: details of Standard recommendation is to keep database lock allocation cause half of keys mostly offline network to reject large block Bitcoin (non-)anonymity Next time Bitcoin addresses are not directly tied to any other identity But the block chain is public, so there’s Group project presentations lots of information List of largest balances on Wikipedia, academic research ❤tt♣✿✴✴❡♣r✐♥t✳✐❛❝r✳♦r❣✴✷✵✶✸✴✼✽✷ Real unlinkability is a research topic