Introduction to Practical Cryptography

Introduction to Practical Cryptography Forward Key Security Zero KnowledgeOblivious TransferMulti-Party Computation

Overview • Intended as overview of specific areas • Solutions/instances of some require background not covered in this class

Agenda • Forward Key Security • Zero Knowledge • Oblivious Transfer • Multi-party Computation

Forward Secure Encryption Schemes • Attacker learns key at time t • Should not be able to decrypt anything from prior to time t • Encryption algorithm – add an input, time • Esk(m) becomes E’sk(m,t) • Current key is a function of prior key • kt = F(sk,t) = G(kt-1,t) • Given sk, can compute entire sequence of kt’s • c = Ekt(m)

Digital Signatures • Alice has a secret key • Everyone else has the corresponding public key • Alice can sign message with her secret key: • Given a signature and a message, everyone can verify correctness using Alice’s public key: • Desirable property: non-repudiation. If Alice signed a contract, she can’t deny it later.

Digital Signature Schemes • Three algorithms Key-Gen, Sign, Verify: Key-Gen inputs: security parameter (“key size”) k output: keys (PK, SK) Sign inputs: message M, secret key SK output: signature S Verify inputs: M, signature S,public key PK output: valid/invalid • Strong security notion:even given signatures on messages of its choice,adversary cannot forge signatures on new messages

Problem with Signatures • Can’t tell when a signature was really generated • Not even if you include current time into the document – doesn’t say when it was signed • Therefore, signing key disclosed Þall signatures worthless (even if produced before disclosure) • Inconvenience: your notarized document is no longer valid • Repudiation: Alice gets out of past contracts by anonymously leaking her SK • Key revocation doesn’t help: it merely informs of the leak

Fixing the Problem • Attempt 1: re-sign all the past messages with a new key • Expensive • What if the signer doesn’t cooperate? • Attempt 2: change keys frequently, erasing past SK • Disclosure of current SK doesn’t affect past SK • However, changing PK is expensive, requires certification • Attempt 3: Employ time stamping authority (third party)

Forward Security • Idea: change SK but not PK [And97] • Divide the lifetime of PK into Ttime periods • Each SKj is for a particular time period, erased thereafter • If current SKj is compromised, signatures with previous SKj-t remain secure • Note: can’t be done without assuming secure erasure

Definitions: Key-Evolving Scheme [BM99] The usual three algorithms Key-Gen, Sign, Verify: Key-Gen inputs: security parameter (“key size”) ktotal number T of time periods output: (PK, SK1) Sign inputs: message M, current secret key SKj output: signature S (time period j included) Verify inputs: M, time period j,signature S,public key PK output: valid/invalid

Definitions: Key-Evolving Scheme [BM99] • The usual three algorithms Key-Gen, Sign, Verify: Key-Gen inputs: security parameter (“key size”) ktotal number T of time periods output: (PK, SK1) Sign inputs: message M, current secret key SKj output: signature S (time period j included) Verify inputs: M, time period j,signature S,public key PK output: valid/invalid • A new algorithm Update: Update input: current secret key SKj output: new secret key SKj+1

Definitions: Forward-Security [BM99] Given: • Signatures on messages and time periods of its choice • The ability to “break-in” in any time period b and get SKb adversary can’t forge a new signature for a time period j<b

Simple Schemes: Efficiency? • Long Public and Long Private Keys • T pairs (p1, s1), (p2,s2),……. (pt, st) • PK= (p1,p2,….,pt) • SK= (s1,s2,…..,st) • Update= erase si for period i • Drawback: public and private key linear in t = number of periods

Anderson: Long Secret Key Only • T pairs as before and an additional pair (p,s) • Sig(j)=SIG( j || pj) with key s, j =1,…,t [“certificate”] • Public key now = p (only) • Secret key = (sj, Sig(j)) j=1,..,t [Still linear] • The public key p is like a CA key and a signature will include the period, the certificate, the message, signature on the message with period’s secret key

Long Signatures Only • Have (p,s) • In period j get (pj,sj) and • Let Cert(j)= sig_s[j-1] (j || pj) • A signature is the entire certificate chain + signature, it is of the form: (j, sig_sj(m), p1, Cert(1),…pj, Cert(j)) • Think about it as a tree of degree one and height t for t periods • (signer memory still linear in t)

Binary Certification tree [BM] • Now (s0,p0) • Each element certifies two children left and right • We have a tree of height log t (for t periods) • At each point only a log branch of certificate is used in the signature • Only leaves are used to sign • Keys whose children are not going to be used in future periods are erased. • We get O(log t) key sizes, signature size

Concrete Scheme • Use a scheme based on Fiat-Shamir variant • Have the public key be a point x raised to 2t • Have the initial private key at period zero be x • Sign based on FS paradigm • Update by squaring the current key • The verifier is aware of the period so it knows that currently the private key is raised to the power 2t-1 (and the identification proofs are adjusted accordingly).

Replace keys Pseudorandomness • Have future keys derived from a forward secure pseudorandom generator • Pseudorandom generators which are forward secure are easy: replace the seed with an iteration of the function. • Possibilities in practice: • Block cipher – use previous output as next input • Stream cipher – previous output as next state

Zero Knowledge Bob Alice I know X Prove it X Some exchange, but which does not provide X • Interactive method for Alice to prove to Bob that she has/knows x without revealing x to Bob. • Motivation: authentication • Alice wants to prove her identity to Bob via some secret but doesn't want Bob to learn anything about this secret • Login methods where password is not stored on server (maybe hash of password is stored) • Alice (user/client) proves to Bob (server) that she knows the password without giving Bob the password

Zero Knowledge • Interactive method for Alice to prove to Bob that she has/knows x without revealing x to Bob. • Zero-knowledge proof must satisfy three properties: • Statement is “alice knows x” • Completeness: if the statement is true, the honest verifier (that is, one following the protocol properly) will be convinced of this fact by an honest prover. • Soundness: if the statement is false, no cheating prover can convince the honest verifier that it is true, except with some small probability. • Zero-knowledge: if the statement is true, no cheating verifier learns anything other than this fact. • Completeness and soundness needed for any interactive proof

Zero Knowledge • Example use: enforce honest behavior while maintaining privacy • Force a user to prove that its behavior is correct according to the protocol. • Used in secure multiparty computation

Zero Knowledge • Jean-Jacques Quisquater, et. al "How to Explain Zero-Knowledge Protocols to Your Children“ • Peggy (prover) has uncovered the secret password to open a magic door in a cave. The cave is shaped like a circle, with the entrance in one side and the magic door blocking the opposite side. • Victor (verifier) will pay Peggy for the secret, but not until he's sure that she really knows it. Peggy says she'll tell him the secret, but not until she receives the money. • Zero knowledge – need a method by which Peggy proves to Victor that she knows the word without telling it to him • Solution • Victor waits outside the cave, Peggy goes in. Label the left and right paths from the entrance A and B. She takes either A or B at random (Victor does not know which) • Victor enters the cave and shouts the path (A or B at random) on which she must return • Peggy returns along the path chosen by Victor, opening the door if it was not the path on which she had entered the cave • If Peggy did not know the word, there is a 50% chance she can return on the correct path; repeat the above many times, Peggy’s chance of successfully returning becomes negligible (assume chance of Peggy guessing the word is negligible) • If Peggy returns correctly each time, this proves she knows the word door A B enter

Oblivious Transfer Bob Alice 0 or 1 m = 1 • Alice transfers a secret bit m to Bob with probability ½ such that • Bob knows whether or not he receives m • Alice doesn’t know if m transferred to Bob

Oblivious Transfer – Example Method • Alice oblivious transfer to Bob • Alice • picks 2 random primes p,q, set n = pq • encrypt message m using n (such as with RSA) • c = resulting ciphertext • sends n and c to Bob • Bob • picks a  Z*n at random • sends w = a2 mod n to Alice • Alice • computes square roots of w: S = {x,-x,y,-y} • picks one of the four at random, s  S and sends to Bob (probability s = a or –a is ½) • Bob • if s ≠ a, -a: Bob can factor n and obtain m (and will know he has m) • Won’t walk through why – see Rabin cryptosystem • Bob obtains m with probability ½ and Alice doesn’t know result

Oblivious Transfer – Example Method • Works if Bob selects a at random (doesn’t cheat) • Not known if Bob gains any advantage (can cheat) if intentionally selects a specific a

Oblivious Transfer – Application • Alice and Bob will each sign a contract only if the other also signs it • Idea • If names are of equal length, could sign a letter at a time, alternating • But someone must go last and could abort – not complete last letter • Sign small fragment at a time – bit, pixel • Don’t know who will be last • If one stops, both are approximately at same point • But one could send garbage in a fragment • Oblivious transfer solves the problem

Oblivious Transfer – Application • Alice and Bob each • create 2 signatures, pick 2 random keys and encrypt each signature (such as with a block cipher) • Alice • LA = “Alice, this is my signature of the left half of the contract” • RA = “Alice, this is my signature of the right half of the contract” • Keys KLA, KRA • CLA = EKLA(LA), CRA = EKRA(RA) • Bob • LB = “Bob, this is my signature of the left half of the contract” • RB = “Bob, this is my signature of the right half of the contract” • Keys KLB, KRB • CLB = EKLB(LB), CRB = EKRB(RB) • Contract is considered signed only if Alice and Bob each have both halves of other’s signature

Oblivious Transfer – Application • Alice sends one of KLA, KRA to Bob using oblivious transfer • Bob sends one of KLB, KRB to Alice using oblivious transfer • Alice and Bob exchange bits of both keys, one bit at a time from each key, in order, until all bits are sent. • If Alice sees a mistake in key bits received, Alice aborts • Likewise if Bob sees a mistake • Bob does not know if Alice has KBL or KBR, so he cannot risk sending an incorrect value for either key • Likewise for Alice • Must exchange bits simultaneously; otherwise, last one could flip last bit

Agenda • Forward Key Security • Zero Knowledge • Oblivious Transfer • Multi-party Computation Some slides are modified from a presentation by Juan Garay, Bell Labs

Secure MPC • A set of parties with private inputs wish to compute some joint function of their inputs. • Parties wish to preserve some security properties. E.g., privacy and correctness. • Example: secure election protocol • Security must be preserved in the face of adversarial behavior by some of the participants

Secure MPC Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] : • n parties {P1, P2, …, Pn}: each Piholds a private input xi • One public function f (x1,x2,…,xn) • All want to learn y = f (x1,x2,…,xn) (Correctness) • Nobody wants to disclose his private input (Privacy) 2-party computation (2PC) [Yao 82, Yao 86]: n=2 Studied for a long time. Focus has been security.

Secure MPC s3 s4 Alice s2 s5 sn s1 s Alice has a secret key, s, (such as a key to a system) Afraid she may lose s Want to give is to someone, but don’t trust anyone with entire secret Share secret among n people: s = s1 s2  s3  s4  s5  … sn

Secure MPC s3 X s4 Alice s2 s5 sn s1 s • Suppose need more flexibility • ith person loses si or is malicious • n people • Any subset of size t can recover s • Any subset of size < t cannot recover any information about s

Secure MPC • Use polynomials • Finite field F (such as some Z*p for prime p) • F(x) = a0x0 + a1x1 + a2x2 + … atxt • Coefficients a0, a1, a2 … at F • t+1 terms (degree is t)

Secure MPC • Polynomials properties: • Interpolation: given t+1 distinct points, (x1,y1), (x2,y2) … (xt+1,yt+1) , can find a0, a1, a2 ,… at • Secrecy: if have only t (or fewer) distinct points, can’t determine anything about a0

Secure MPC • Coefficients • Pick a1, a2 .. at at random • set a0 = s • Each person is associated with a distinct point • Person i assigned distinct xi • Set si = f(xi) : (xi,si) is point for person i

Secure MPC • Polynomial construction requires honesty • Entity choosing ai’s, xi’s is dishonest • Collusion – person 2 may give (x2,s2) to person 10 • Verifiable secret sharing • Each person can verify piece received is a proper piece • Allows for O(log n) colluders • Based on factoring [Chor, Goldwasser, Micali, Awerbuch]

Instances of 2PC • Authentication • Parties: 1 server, 1 client. • Function : if (server.passwd == client.passwd), then return “succeed,” else return “fail.” • On-line Bidding • Parties: 1 seller, 1 buyer. • Function: if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2, else return “no transaction.” • Intuition: In NYSE, the trading price is between the ask (selling) price and bid (buying) price.

Instances of MPC • Auctions • Parties: 1 auctioneer, (n-1) bidders. • Function: Many possibilities (e.g., Vickrey*). • Consider a secure auction (with secret bids): • An adversary may wish to learn the bids of all parties – to prevent this, requires privacy • An adversary may wish to win with a lower bid than the highest – to prevent this, requires correctness • *sealed-bid, bidders submit written bids without knowing the bid of the others. Highest bidder wins, but pays second-highest bid. Intent: bidders bid true value.

MPC Protocols Consider 2PC (MPC is similar). Two parties: P0 and P1. Encode function as a Boolean circuit of ANDs and XORs Bits on each wire are shared using XOR Per-gate evaluation: (Shared) Inputs: x = x0  x1,y = y0  y1 XOR:No interaction needed ( x  y) = ( x0  y0 ) ( x1  y1 ) AND:More complex (needs interaction) Each party reveals his shares

MPC – Elections • m voters: v1, v2, … vm • ith voter inputs xi • Result: function, f, of xi’s • Required properties • Only authorized voters can vote • Each can only vote once • Each vote is secret • No vote can be duplicated by another voter • Vote tally correctly computed • Anyone can check the tally is correct • Fault tolerate protocol: works if some number of “bad” parties • Cannot coerce a voter into revealing how he/she voted (no vote-buying) • Meeting all requirements tricky, especially last • In real life – system, logistical problems main issues as opposed to protocols

MPC –Digital Cash • Required properties • Prevent forgery • Prevent or detect duplication • Preserve customer’s anonymity • Practical: • operationally feasible (ex. no large single database of all issued digital cash)

Digital Cash • 3 protocols • Withdrawal – user can obtain a digital coin • Payment – user buys goods from vendor using digital coin • Deposit – vendor gives digital coin to bank to be credited to the vendors account • Notation: • U = user • B = Bank • V = vendor • D = digital coin of $100 • SKB{x} = signature of B on x

Digital Cash - Withdrawal • U notifies B wants to withdraw D • B gives D to U D = SKB{I am a $100 bill, #4527} • U checks signature • accepts D if it is valid • else rejects D • Bank deducts D from U’s account if U accepts D

Digital Cash - Payment • U pays V with D • V checks signature • accepts D if it is valid • else rejects D

Digital Cash - Deposit • V gives D to B • B checks signature • accepts D if it is valid and credits V’s account • else rejects D

Digital Cash – Do Properties Hold? • Prevent forgery • ok, infeasible under basic assumptions of signature schemes • Prevent or detect duplication • Very easy to duplicate coins, double spend • Preserve customer’s anonymity • No anonymity – know U and where D was spent

Introduction to Practical Cryptography