XOR Protocol		The technique of splitting a piece of information I into halves, each of which contains 0 information about I will prove quite useful in the digital cash scheme described below. We formalize the idea into a protocol for splitting I into two pieces. Requirements We need I a piece of information which is a secret: Public Private R, I' I Generate a random bit string R the same length as the bit string encoding of I (Enc(I)). I' = ENC(I) XOR R The rule for XORing: Bit1 Bit2 Result 1 1 0 1 0 1 0 1 1 0 0 0 The intuition is that the result of XORing just tells you if the two input bits were the same or different. Note that XORing is easily reversible, because the following is true: (A XOR B) = C if and only if (B XOR C) = A So XORing can be used as a form of onetime pad (Vigenere) encryption: (M XOR K) = C if and only if (C XOR K) = M Bacause I' and R are related to I by XORing, I' is one half of I, R is the other. That is, to get Enc(I) back XOR I' and R together: I' XOR R = Enc(I) Enc(I) x R I' 1 x 1 0 1 x 0 1 0 x 1 1 0 x 0 0 A important property of the protocol: If Enc(I) has length n, every random string R of length n provides a different way of splitting Enc(I). There are 2n different random strings of length n. Thus there are 2n different ways of splitting Enc(I).
Bit- commitment		Alice wants to commit to the content of a certain secret, S, withOUT revealing it. She sends Bob a message that commits her to secret S at time T. Bob does not yet know S. But later he will be able to verify from the message Alice sent at time T that in fact she knew S at time T, and and wrote down its content correctly then. We start with S being just one bit (0 or 1), which we will call b. Secret transmission part (time T-1, T) Bob generates a random bit string R and sends it Alicewards at time T -1. At time T, Alice creates a message committing her to a certain secret bit, b. Let's say this message contains the result of a coin toss, and that result is Heads, which they have agreed to encrypt as "0". Alice's message contains 0 and Bob's random string R. She encrypts it using K: EK(R+0) Not having K, Bob does not know b=0. Verification part (time T+1 or later) Alice send Bob K Bob decrypts the message and reads b. He also verifies that R is the random string he sent. What is the point of putting R in? Suppose R were left out and the message contained only an encrypted version of b, which is 0 given the result of the coin toss, and 0 encrypts as hexadecimal "c": EK(0)= c Now after Bob guesses (correctly) that the coin toss resulted in H (= 0), Alice could hornswoggle him by searching for and presenting Bob with a key K', such that: EK'(1)= c But requiring Alice's message to include Bob's randomly chosen string R makes such key-swapping games infeasible. Alice would have to find a key K' such that: EK'(1+R)= c which is a much more difficult proposition given any reasonable encryption scheme. This should be reminiscent of our first coin-tossing game example with Alice and Bob, which we used to introduce the properties of oneway functions. The bit-commitment protocol can be entirely implemented using oneway functions. Note that in this case the one-way functions do not have to be 1-1. Thus they can be the kind of hash (or digest) functions we encountered with signature protocols for RSA. Secret commitment part: Alice generates two random bit strings R1 and R2. Alice creates and encodes (digitizes) a message consisting of R1 and R2 and the bit b: M = Encoding(R1+R2+b) Alice computes a oneway function H of M and sends a new message M' to Bob. M' = H(M)+R2 Verification part: Alice sends Bob M, the orginal message. Bob now verifies that M corresponds to the M' he received by computing H(M). If H(M)= M', then M' is valid. In particular, if M contains R2 and H(M) = M', then what Alice sent at time T was the actual result of applying H to what she sends now. Note: by including R1 in M' Alice guarantees that Bob can't learn the secret b ahead of time. IF the message was just R2+b and Bob knew R2, he could try both H(R2+1) and H(R2+0), see which one matched M', and learn b ahead of time. One advantage of the oneway function version over the original is: Fewer communications ( instead of 3).
Blind Signatures I		from Schneier, p. 549 Based on RSA. Requirements We need public and private keys e and d for Bob, and public modulus n. Privacy is thus as in RSA: Public Private e, p d Alice wants Bob to sign message m without knowing what's in it. Let (e,n) be Bob's public key. Alice chooses a random number k between 1 and n, computes t = mke mod n and sends it to Bob. We call k the blinding factor, because, not knowing k, Bob cannot use t to discover m. There asre a variety of other mathematical operations Alice could perform to serve the same purpose. This is just the simplest. Bob signs t by encrypting it with his private key: td = (mke)d mod n He now sends it back to Alice. Alice now divides t by k. s = td/k This is called unblinding because it results in something transparently related to m: td ≡ (mke)d ≡ (mdk), so td/k ≡(mdk)/k ≡ md (mod n) And md is easily turned back into m using Bob's public key: (md)e mod n = m Thus md is a message provably authenticated by Bob (because only Bob knows d), which Bob has never seen.
Blind Signatures II		The blind signature I protocol is not very useful, because it asks Bob to sign something he never sees. In this variant, we give Bob a chance to verify that he is signing the KIND of document he thinks he's signing without actually seeing the document. This idea will be used in the digital cash protocol, where the role of Alice will be played by a private citizen engaged in a finacial transaction, the role of Bob will be played by a financial institution (think "B" is for "Bank"), and the message will be an authorization for a funds transfer. One of the goals of digital cash protocols is to provide a mechanism for electronic funds transfer that allows for the same kind of anonymity buyers have when using cash. Blind signatures by authorizing financial institutions will play a key role. Alice and Bob agree on an amount of money to be authorized by a bank draft (or a "Bob" draft). Alice prepares n nearly identical messages, each with a different unique ID, each authorizing a funds transfer of the agreed upon amount. Alice blinds each of the n messages with a different blinding factor and sends them all to Bob. Verification step:: Bob chooses (n - 1) of the messages at random, asks Alice for the blinding factors, and unblinds those (n - 1) messages. He verifies that the messages are drafts for the agreed upon amount. Bob signs the last document, still blinded, and sends it back to Alice. Alice unblinds the last document and has a bank draft of the form md provably authorized by financial institution Bob, because only Bob knows Bob's private key. She can spend it with a merchant who then takes the draft to Bob to be reimbursed. Bob honors the draft because it has his signature, but he has no idea the draft came from Alice (assuming he does more than a few of these drafts). Each time he honors a draft he records its unique ID. This keeps Alice from using the same draft more than once. Discussion of verification step: The key point here is that if Alice tries to sneak in a draft for more than the agreed upon amount, she has only a 1 in n chance of escaping undetected. As in the zero-knowledge proof schemes, making n bigger decreases the chances of successful cheating. Bringing in the possibilties of legal penalties increases the risks associated with being caught. Moral: By making n and the legal penalties big enough the bank can attain whatever level of security it needs to feel comfortable. A key point: It must be extremely difficult to find blinding doublets, pairs of messages which, with different keys, are mapped to the same blinded message t. Otherwise Alice could cheat by preparing two messages, one of which, m1, is a draft for the agreed upon amount, and the other of which, m2, is a draft for an amount much larger than the amount agreed upon and then blind as follows: t = k1m1 = k2m2 When asked by Bob to unblind t, Alice produces k1 and the message with the agreed upon amount appears. After the bank has signed one message, Alice produces k2, the key for its blinding doublet, a bank draft for a million dollars appears, and Alice goes to Rio. No details given here: The math of the blinding functions rules this out.
Digital Cash		The blind signature protocol sketched above might look like the solution to the digital cash problem, but in fact it lacks certain very important features. Consider the fact that to get such a scheme to fly you have to convince a bank to come along for the ride. Banks --- pace the savings and loan industry --- are not known for their risk taking behavior. At least the following features, missing from the bare blind signature scheme, will be needed: In cases of fraud (attempted double spending of the same bank draft), we need to know whether the perpetrator is the merchant or the buyer. In cases of fraud where it's the buyer, we need to know who the buyer is, but ONLY in cases of fraud. (this is the tricky bit) Here's how to do that: Alice prepares n bank drafts for a given amount each with a unique ID. Identity bit strings: Each money order will also contain information uniquely identifying Alice. In fact it will contain n different pieces information, each of which will uniquely identify Alice. This is done by taking a string uniquely identifying Alice (say with her name and SS number or address) and splitting it n different ways using the XOR protocol described above. The result is n pairs of identity bit strings I1, ... In. We'll call the left half of pair Ii Ii[0] and the right half Ii[1]. Each pair when when XORed together with its corresponding half yields the string identifying Alice. I79[0] XOR I79[1] = "Alice Bentley, 12 E. Main Street ..." But when XORed with any other half yields nonsense: I73[0] XOR I79[1] = "xwt9w4u-4924gwprpfwp...." By way of illustration, let's suppose n=5, and that Alice's ID string is "01101", Then Alice's bit strings look like this:   0 1 XOR I1 10101 00111 01101 I2 10011 00001 01101 I3 01000 11010 01101 I4 11111 01101 01101 I5 01111 11101 01101 Alice also commits to EACH of the n pairs using the bit-commitment protocol described above. [Recall that this commits her to all of the bits in the pairs, without revealing what they are. This will keep her from changing the identity bit strings, even though they are just being stored electronically.] Summary of draft information: Summarizing the previous steps: EACH of the bank drafts is associated with the following contents: Public Part: Amount Uniqueness string Private Part: Identity Bit Strings: I1[0] I1[1] I2[0] I2[1] ..... In[0] In[1] Alice's bit commitment protocol keeps the private parts private until the verification part of the protocol (although she is already committed to the private part by the bit commitment protocol). Alice blinds all n bank drafts using a blind signature protocol. Signature: Bob (the bank) opens (n - 1) of the drafts to verify they have the agreed upon amount and signs the nth draft. Alice unblinds the the nth bank draft to spend it with merchant Mort (although the identity bit strings are still protected by the bit-commitment procol). Mort verifies Bob's signature to make sure the bank draft is valid. Selector string: Mort creates a random bit string S of length n. We call S the selector string. Each bit selects ONE of the pairs in an identity bit string in Alice's bank draft. Thus a 0 in the ith position of S selects Ii[0] on Alice's bank draft. By way of illustration, suppose Mort's selector is 00010. Alice must reveal the bits highlighted in red: Selector = 00010   0 1 XOR I1 10101 00111 01101 I2 10011 00001 01101 I3 01000 11010 01101 I4 11111 01101 01101 I5 01111 11101 01101 Notice that revealing these bit strings reveals nothing since in each case she has revealed only one member of a pair. And by itself one member of a pair is worthless. Mort gives Alice the goods or servioces she is purchasing. Mort goes to banker Bob with Alice's draft. Bob verifies the signature on the draft to verify that this check is his. The he checks the draft's unique ID in his database to see if he has cashed this draft before. If he has, he refuses to cash it. Fraud Detection: If the draft has been used before, Bob looks up the selector string used the previous time Alice tried to use this draft. Let's say the previous selector string was: Selector = 11011   0 1 XOR I1 10101 00111 01101 I2 10011 00001 01101 I3 01000 11010 01101 I4 11111 01101 01101 I5 01111 11101 01101 Notice that Bob now has both the left and right halves of pair I1, I2, and I5, all the positions where the two selector strings disagreed in their digit. He can XOR together any of these pairs to get Alice's ID string. Alice is caught!
Extortion		Digital Cash and the Hit Man: The problem. The buyer (in this case the hit man's client) is anonymous but the merchant (in this case the hit man) is not. However, crimes in which the criminal can play the role of buyer are possible. Thus, digital cash is a perfect vehicle for extortion. [S. von Solms and D, Naccache. "On Blind Signatures and Perfect Crimes". Computers and Security. v. 11, 1992, pp 581.583.] Why is this? What part of the protocol can be public? Could "the numbers" of the public part bve published in a newspaper?
Digital cash and taxes		A disaster for tax collectors? No. For the same reason as the hit man story. The one making the money is not anonymous.
Digital Cash: A failure		DigiCash: The 1994 company based on Chaum's original patents, went bankrupt: DigiCash, a software company that tried to create an electronic currency for Internet commerce, filed for bankruptcy on Tuesday, an apparent victim of consumers' preference to use credit cards for online purchases. DigiCash, founded in 1994, set out to create a mechanism for consumers to make "micropayments" for online transactions -- such as purchases of individual articles or music singles. Unlike credit cards, which reveal a buyer's identity to vendors, DigiCash's encryption would have made its electronic money as anonymous as cash. wired.com News story: 05:25 PM Nov. 06, 1998 PT Why? Timing I: Credit Cards work on the internet, also a function of cryptography: .... The market for micropurchases began to shrink in recent years as Internet consumers became more and more comfortable with using credit cards for purchases. In September, Mercantile Bank, the only US bank to agree to test DigiCash's system, ended its three-year relationship with the company, citing changing market conditions. .... [IBID] .... The electronic cash landscape is littered with the looted corpses of companies that tried and failed to compete with credit cards for online purchases. DigiCash, a pioneering firm in the area, declared bankruptcy in 1998 and sold its 16 patents and its domain name to eCash Technologies. Now eCash is having its own troubles: The company laid off 25 of its 65 employees in March. ... CyberCash... Now its founder, Bill Melton, is embroiled in a bizarre spat over whether CyberCash made money from porn sites -- in fact, they were its best customers -- and whether that made it appropriate for Melton to donate money to a Virginia gubernatorial candidate. wired.com News story: 02:00 AM Jun. 14, 2001 PT Not for lack of trying.... After Digicash, Robert Hettinga For the last six years, Robert Hettinga has been agitating, begging and pleading for the world to listen to his ambitious plans for digital money... Like any savvy techno-evangelist, Hettinga coined a name for his idea -- digital bearer certificates -- and envisions a day when Internet users can withdraw electronic cash by simply typing in an ATM card number and their PIN. Wired.com story Timing II: Digital Cash push coincided with internet bust, missed internet cash boom. [Hettinga's] two-year-old Internet Bearer Underwriting Corporation missed the ready capital of the online boom. It has attracted only $160,000 in funding, and has done about $100,000 of consulting work so far. "Quite frankly, the dot-com money has gone away," says Hettinga, 42. "We're also running over ground that CyberCash, DigiCash and a lot of other people have burned." PR problem: People view digital cash as something whose primary function will be to facilitate internet commerce Therefore: Success of digital cash is tied to success of internet commerce. [Only now really being established as the internet boom/bust cycle leaves some real winners like google, EBay, yahoo, amazon, PayPal...] Digital Cash somewhat a victim of its own hype: Billed as world-changing technology, it is really just another financial service. Market points Anonymity (still). But for the bank to make big money off this feature a big-market need for anonymity is required (gambling, porn sites), a far cry from a brave new digital utopia. Transaction costs: Hettinga says he can complete transactions for a minuscule amount. "What we can do is put money on the Net for 80/100ths of 1 percent. Transactions after that are pretty much free," he says. "You pull a dollar bill out of an ATM and that costs money. You don't pay for transactions after that." [Paypal's success in part due to transaction costs]: .... PayPal's relatively low 2.2 percent transaction fee plus 30 cents. Visa, by contrast, charges up to approximately 2.5 percent in transaction fees. Immediate transactions [PayPal, Visa, MasterCard cant do this...] ... because of the possibility of fraud, a Visa transaction does not complete -- meaning the seller doesn't get paid -- for up to 90 days [IBID]