December 1992 - cypherpunks-legacy

bank protocol run through
by Karl L. Barrus 03 Dec '92

03 Dec '92

I find it useful to work through a protocol by hand a few times to really see what's going on. Here is an example of the digital bank protocol. It is meant for people who are curious to see if it works, as educational material for new subscribers, or general interest. I'm choosing relatively small numbers to use: in a real implementation, they would be much much larger. OK, let's start! ---------------------------------------- On the bank's side, it chooses the primes p = 2038074743 and q = 2038074947 and so the public key n = pq = 4153749073821763621 also phin = Euler totient function of n = (p-1)(q-1) = 4153749069745613932 The bank decides to make people use the exponent 5 (it's just easier to tell if GCD[5, phin] is 1) 1) Alice chooses a random x, r. She hashes x to yield fx x = 3141526535 r = 5772156649 fx = 2718281828 Here, I just picked the value of the hash function from the mathematical air, so to speak. Alice computes B = r^5 fx mod n = (5772156649^5 2718281828) mod 4153749073821763621 = 592088213321408342 -> B = PowerMod[r^5 fx, 1, n] in Mathematica Alice sends B to the bank. 2) The bank takes fifth root of B. Or, it raises B to the power that is the inverse of 5 mod n. To find the inverse of 5 mod n, compute inv1 = 5^(-1) mod phin = 5^(-1) mod 4153749069745613932 = 1661499627898245573 The bank can do this since it knows the factorization of n. -> inv1 = PowerMod[5, -1, phin] in Mathematica So, to take the fifth root: D = B^inv1 mod n = (592088213321408342 ^ 1661499627898245573) mod 4153749073821763621 = 1189395596986402260 -> D = PowerMod[B, inv, n] in Mathematica Just as a check: D^5 mod n = = (1189395596986402260 ^ 5) mod 4153749073821763621 = 592088213321408342 = B So we're OK. -> Mod[D^5, n] in Mathematica Bank sends Alice D. 3) Alice extracts C by dividing D by r. Or, she solves the following equation for C: D = C r mod n, or 1189395596986402260 = C 5772156649 mod 4153749073821763621 This can be solved by multiplying D by the inverse of r mod n, and taking the result mod n. You don't need to know the factors of n. As a technical note, there will be only one solution since GCD[D,n] = 1, which is usually true since n only has two factors p and q. The bank is in trouble if GCD[D, n] != 1 since that means n can be factored by the information in D. inv2 = r^(-1) mod n = 5772156649 ^ (-1) mod 4153749073821763621 = 3900656075651054436 -> inv2 = PowerMod[r, -1, n] in Mathematica So, C = (D inv2) mod n = (1189395596986402260 3900656075651054436) mod 4153749073821763621 = 3844350519262422248 -> C = Mod[D inv2, n] in Mathematica Just as a check: C r mod n = = (3844350519262422248 5772156649) mod 4153749073821763621 = 1189395596986402260 = D So we're OK. -> Mod[C r, n] in Mathematica So now Alice has x = 3141526535 and C = 3844350519262422248 4) Alice pays Bob by giving him (x, C) 5) Bob verifies that C = fx ^ (1/5) mod n. Or, he verifies that fx = C^5 mod n C^5 mod n = = 3844350519262422248 ^ 5 mod 4153749073821763621 = 2718281828 which does indeed equal f(3141526535) = 2718281828 where f is our hashing function. So Alice isn't cheating by sending a bogus (x, C) But Bob must also send (x, C) to the bank to verify Alice isn't trying to spend the money more than once! ---------------------------------------- So there it is, with numbers and Mathematica statements for those who have access to Mathematica. Hopefully, the numbers are large enough to convince people it didn't work out by chance. Now, the code to perform the math must be written, as well as the scripts to support the bank. Has anyone used the RSAREF routines, or should we stick to what's supplied with PGP? I haven't thought that far ahead. Like I said earlier, I'll pick up work on this in a few weeks. --- /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

uh oh, o-o
by peter honeyman 03 Dec '92

03 Dec '92

the following remarks were transcribed from today's live satellite broadcast from sun on object oriented technologies, hosted by john gage. in his introductory remarks, he said: I found something else that a number of you probably have read already, it's in a way relevant to this, about searching through large archives. This is John Gilmore, Sun employee number five. [Holding up to the camera last Saturday's NYT article.] This is John in his normal confrontational stance with the National Security Agency. John wanted two textbooks on cryptanalysis that were classified, then declassified briefly, then reclassified. Using good search techniques, using what Bob Kahn would call "knowledge robots" or "knowbots", objects searching for your bibliographic material on the net, John found them in a public library and that made the NSA very upset. For about three days there was a fight, this was in Saturday's New York Times, there was a fight until Tuesday of this week, yesterday, they declassified these books. So using object technology in some rough sense to pore through enormous amounts of information is a topic that may sound futuristic but it's very, very real, we think, and we'll talk about that. enjoy. peter

1 0

digital banking, file formats, etc.
by Karl L. Barrus 03 Dec '92

03 Dec '92

This is a run through of Hal Finney's summary of the bank protocol. Here is what I envision the digital bank working like, with rough sketches of file formats, conspicuously similar to the remailer's :-): 1) Alice chooses x, r Alice computes B = r^3 * f(x) mod n Alice sends the following message to the bank via an anonymous remailer :: withdraw <account name> <B = r^3 * f(x) mod n> Reply-To: <an anonymous remailer> <remailing request to Alice encrypted with appropriate remailer public key> In the final version, this message will be encrypted as well 2) Bank computes D = B^(1/3) checks <account name> for balance, withdraws if ok Bank sends to appropriate remailer :: Encrypted: PGP <remailing request included in Alice's mail> <D> 3) Alice computes C = f(x)^(1/3) by dividing D by r. Alice gives Bob (x, C) - via anonymous mail, presumably :-) 4) Bob wants to verify (x, C) Bob mails to Bank via anonymous remailer :: verify <x> <C> Reply-To: <an anonymous remailer> <remailing request to Bob encrypted with appropriate remailer public key> In the final version, this message will be encrypted as well 5) Bank checks x to see if its been used Bank sends back to remailer :: Encrypted: PGP <remailing request included in Bob's mail> <usage status: used or unused> 6) Bob accepts the "cash" Bob sends to bank via anonymous remailer :: deposit <account name> <x> <C> Reply-To: <an anonymous remailer> <remailing request for Bob encrypted with appropriate remailer public key> 7) Bank checks x, C, account name; if everything OK, deposit Bank replies via anonymous remailer :: Encrypted: PGP <remailing request included in Bob's mail> <message indicating deposit accepted or rejected> Alice and Bob may send message to and receive messages from the bank via anonymous remailers. Or more than one... During the testing/development phase, account names and balances can be made public (available via finger command or something like that) for verification. Account names can be hashes of some user chosen string (Email address plus random text, etc.) Customers must be able to choose: two random numbers x, r compute: f(x) r^3 * f(x) mod n f(x)^(1/3) or C^3 solve: D = C r mod n for C Bank must be able to solve: D^3 mod n for D So, PGP has routines which can generate random number, calculate hashes, and be modified slightly to perform the necessary math. The Bank will be supported by a host of scripts and the math performing PGP routines. Sometime later I will post a run through of the digital bank protocol (all numbers and done with Mathematica) as an example for those who are interested in an example of the protocol. Any input or comments or help will be welcome. Or, if someone else is further along than me, I volunteer! Unfortunately, since the end of the semester draws near, I will be unable to work on this very much for the next few weeks. Besides, I've got to go pick up the O'Reilly and Associates Perl book to move this project along... --- /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

No Subject
by nobody＠rosebud.ee.uh.edu 03 Dec '92

03 Dec '92

This is a test post of a triple-remailed message, all encrypted. Sent at Wed Dec 2 16:17:47 GMT 1992 (Signed) Guess Who?

1 0

Suggest splitting things up
by crunch＠netcom.com 03 Dec '92

03 Dec '92

To Cypherpunks: Greetings, Back on-line again, after wading through about 225 messages that has accumulated in the last 4 days. The volume of messages is really getting high, and perhaps we might want to try and break them up into the following proposed lists. a) PGP Development - a mailing list has already been set up, but is reserved exclusivly for those doing the actual coding work. b) Digital money - A lot of traffic seems to contain this subject, which is all very interesting, but doesn't apply to me because money is something I never seem to have anyway. c) Key management and collaboration - for discussion on various key exchange methodology. Anyway, this is just a thought. And might help to cut down traffic. One also might consider setting up a newsgroup. JD

2 1

Information wanted
by centaur＠netcom.com 02 Dec '92

02 Dec '92

Hello there! I'm interested in getting information on the cypherpunk movement. Could y'all perhaps e-mail me back with your manifesto and suchlike things? Much obliged! Paul --

1 0

Help with the contents of the Cypherpunks Mail Archive
by hugh＠domingo.teracons.com 02 Dec '92

02 Dec '92

As I said I would at the last 'in person' meeting I am starting up a mail archive of usefull things for old and new Cypherpunks. At first we will have a few files that can requested over email, ftp and more complex files sturctures might come later. The most important files that needs to get built are the FAQ (Frequently Asked Questions), the Glossary and the bibliographys. These need to be done keeping in mind who we want to reach, the programmer new to crypto systems and useage. This is a group effort, if you have a good definition of a word send it to me, I will likely use it! If you think you can do a great job of describeing one of the questions from the FAQ in a page or so, whip it out and send it to me! I will compile/edit what ever comes my way into the right place in the archive files. Once we have a good FAQ then when new folks join the list we can send them the FAQ to read and get them up to speed that much faster. This will mean that we will have just repetition on the main list and therefore a better signal to noise ratio! So, go over the list at the end of this email message and see if there is anything you want to tackle, and if there is write some of that English code! ||ugh Daniel Keeper of the archive for now... Propsed contents of the Cypherpunks mail archive. Glossory Bibliography Beginers Anotated Bibliography by Subject FAQ --- A beginers guide to Cypherpunking What is the cypherpunks list all about? Why do I need crypto? What is privacy? What are public keys? What is the differences between DES & RSA? Why can't I just use rot13? Why is generateing random numbers hard? Why do crypto in software insted of hardware? Why is this crypto stuff still legal? What journals are there on this subject? What are the good beginer books on crypto systems? What is the NSA and why does everyone seem to hate them? What is crypto anarchy? Is all I need to crypt my email? What are remailers and DC-Nets? What can I do? Sources Remailer sources Random number generators & testers

2 1

FAQ in sci.crypt
by tcmay＠netcom.com 02 Dec '92

02 Dec '92

Cypherpunks of Cypherspace, I just found a new FAQ and bibliography in sci.crypt. It's by Larry Loen and is intended as a stopgap FAQ, as sci.crypt hasn't had a good FAQ in a while. It doesn't cover the digital cash, anonymous remailers, crypto anarchy, etc. kinds of stuff, but it answers FAQs about one-time pads, ciphers, RSA, etc. Since this is a mailing list, I will not forward it. (It's 26 or so screenfuls of VT-100 screens, which is fairly long.) Also, I still have the "Crypto Glossary" available for forwarding to any newcomers to this list. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement.

1 0

.
by nobody＠rosebud.ee.uh.edu 02 Dec '92

02 Dec '92

Subject: Digital Cash One point of digital cash is to allow electronic payments, so printing it on paper would not be useful as other than a novelty. People would have to scan the bit patterns back in, which would be inconvenient. How big will a piece of digital cash be? An electronic "dollar bill" in the simple scheme of Chaum's consists of two parts: (x, f(x)^(1/e). X is a random number, f(x) is a one-way function like MD5, and e is the exponent which could be taken to represent the denomination of the bill. MD5 takes 64 bytes as an input "chunk" so that would be a natural size for x. f(x)^(1/e) is f(x) "signed" by the bank using exponent e, so that would be about the size of the bank's modulus n, say 1024 bits or 128 bytes. Probably there would be some control information as well. So the total size of an electronic banknote would be 128 + 64 + a few, or about 200 bytes, maybe a little more. To print this you'd have to Ascii-encode it, which generally expands things by 1/3, so you'd get about 270 to 300 characters per bill/coin. This would be around four or five lines of text, comparable to a PGP key (and looking about as interesting - totally jumbled letters and numbers). "Forgery" is in one sense hard and in one sense easy. It's hard because to create new dollar bills because you have to forge a signature using the bank's public key (n, e). This is equivalent to breaking at least some uses of RSA. But it's easy to reproduce existing electronic dollars, and you don't even need a Xerox machine. Just "copy dollar1 dollar2" on your PC, and repeat the process. Presto, plenty of dollars, all exactly the same. Send one to the butcher, one to the baker, and you've still got plenty more where those came from. Keeping this kind of re-use from occurring is one of the things that makes electronic cash tricky. Chaum's simple scheme has the receiver of cash calling the bank or sending the cash there right away. The bank has a list of "serial numbers" for all the cash that's ever been deposited, which it compares against to see if this is a re-use. The first person to deposit a dollar with a given serial number gets credit for it; the others are told that it's worthless. Another area that people seem a little unclear about is the difference between electronic cash and electronic checking accounts. A checking account could be managed by simple RSA-signed messages (e.g. created with PGP) saying, please transfer $X.00 to account number XYZ. If you wanted to buy something from someone, you'd find out what his account number is with the bank, write up a little note like this, sign it using your public key with PGP, and email it to the person that you wanted to buy from. He'd send it on to the bank and his account would get credited. Again, you'd want to put a serial number on your check so that the guy couldn't send it again tomorrow and get another $X.00. Or, you could just send it directly to the bank and request the bank to notify the seller that the funds had been transferred. This would seem to avoid the re-use problem. The difference between this system and electronic cash is that the bank knows exactly what is going on. It sees all transactions, so it knows which accounts are making payments to which other accounts. This is true of ordinary paper checking accounts as well, of course. Electronic cash is designed so that not even the bank can tell who is paying whom. I withdraw some cash, say, $100.00, and I pay you $35.00 by mailing you the electronic bills. You deposit them. The bank has no way of determining which particular withdrawal produced those bills which you are depositing. This is, more or less, how real cash works. Hal 74076.1041(a)compuserve.com

1 0

summary of remailers
by Karl L. Barrus 02 Dec '92

02 Dec '92

Here is a summary of the currently available anonymous remailers: hal(a)alumni.caltech.edu -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- remailer(a)rebma.mn.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ== =/qHx -----END PGP PUBLIC KEY BLOCK----- elee7h5(a)rosebud.ee.uh.edu -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg== =9mBX -----END PGP PUBLIC KEY BLOCK----- /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0