December 2003 - cypherpunks-legacy

PRIVACY 101
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Duncan and I are now accepting registrations for our on-line Privacy Seminar. If you would like to participate, you can subscribe by sending a message to: majordomo(a)c2.org In the body of your message, you should have the command: subscribe privacy101 [<address>] Where [<address>] is the e-mail address you wish to use for the Seminar. (If you do not specify an address, the address from which you subscribed will be used.) Send a message to majordomo(a)c2.org with the word "help" in the body of the message to get majordomo help info. Here is some more list info: Majordomo address: Majordomo(a)c2.org Majordomo-Owner address: Majordomo-Owner(a)c2.org List Name: privacy101 List posting address: privacy101(a)c2.org List request address: privacy101-request(a)c2.org The Seminar will be archived. To participate from the beginning, however, you should sign up immediately. The Seminar will begin September 1st. The Seminar will be a series of lectures that alternate with a moderated list for questions and comments. As the Seminar progresses, we may alter or add lectures, but the tentative list of lectures is as follows: Privacy 101 Lectures: 1. Introduction to Privacy Theory and Philosophy 2. Threat Level Management--The Calculus of Risk 3. Identity Information Risks 4. Locational Information Risks 5. Financial Information Risks 6. Health Information Risks 7. Lifestyle Information Risks 8. Political/Philosophical Information Risks 9. Misc. Information Risks 10. Identity Privacy Techniques 11. Locational Privacy Techniques 12. Financial Privacy Techniques 13. Health Privacy Techniques 14. Lifestyle Privacy Techniques 15. Political/Philosophical Privacy Techniques 15. Misc. Privacy Techniques If you have any specific questions or areas of interest which you would like to have addressed during the Seminar, please let us know as soon as possible. We will try to work them into our presentation. Regards, S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Spoofing Weapons 2
by John Young 17 Dec '03

17 Dec '03

Forwarding mail by: misra(a)gardener.lanl.gov ("Raymond H. Misra") on Fri, 26 Aug 10:28 AM ------------------- On Aug 26, 2:11am, MEINKING(a)delphi.com wrote: > Subject: > > Each message pounds another nail into my silent coffin. Inside it is dirty, > dank and pathetic. I have received every post. I have read every post, and > each time, I have had what seems like everything to say. But I don't say > it. > > Yet I do know where I want to go, where I want to reach. I want to reach > those that have pounded the nails into my coffin, that have participated in > luring me into the apeiron, trapping me in the coffin, and discarding me > forever. > > To them I can only say this: > > "The fire is burning me. It is erupting from the inside, from the > pit of my gut and bursting forth. The flames it releases want > victims to claim for their own giddy disgust and restoration is no > longer possible." > > >From the depths of the apeiron, at a distance deeper than hell itself a > bright light expands devouring each bit of darkness in its wake. If you > listen, you can hear it speak the sound - the sound of creation. >-- End of excerpt from MEINKING(a)delphi.com You wouldn't be desribing the weapons discussion on "cypherpunks" list for the past few days, would you? -- Raymond H. Misra

2 1

MATH: Brands cash, Hal's posts
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, or maybe that's Atompunks, Earlier, Hal posted several excellent messages concerning Brands' cash, and some introductory material. I always find it useful to work through various protocols by hand (well, with Mathematica), working with real numbers to help understand the protocol and how it works. So like I did a long time ago when Hal posted a description of Chaumian cash, I will give an example of the protocols described. I intend to follow along Hal's posts and work math as it comes up (and try to keep the notation consistent!). I'll not be using numbers large enough to give actual security. For folks with Mathematica, the functions of interest are PowerMod[a,b,c] to calculate a^b mod c, and Mod[a,b] to calculate a mod b. Hal's first post was introductory material on discrete logs: * Generators > Discrete-log based cryptosystems generally work with a modulus n which is > prime, along with a "generator" g < n such that the series g^0, g^1, g^2, > ... , includes all values from 1 to n-1. It is pretty straightforward to > find such n's and g's. It is easy to compute g^x for any x, but > intractable to calculate x given just g^x. Finding a generator g is easy if you know the factorization of n-1. You just need to calculate g^((n-1)/q) mod n for all values of q, the prime factors of n. If any of the results are 1, then g is not a generator. So say you want to see if 5 is a generator mod 2047. The prime factors of n - 1 = 2046 are { 2, 3, 11, 31 }, so you calculate: 5 ^ (2046/2) mod 2047 = 1034 5 ^ (2046/3) mod 2047 = 622 5 ^ (2046/11) mod 2047 = 1435 5 ^ (2046/31) mod 2047 = 622 None of these turned out to equal 1, so 5 is a generator mod 2047. * Diffie-Hellman key exchange > 1. Alice chooses a random x and sends GX = g^x to Bob. Bob chooses a > random y and sends GY = g^y to Alice. Let's use g = 10, and pick p = 17389. 10 is indeed a generator mod 17389. Alice chooses x = 53, and calculates g^x mod p = 10^53 mod 17389 = 9059 Bob chooses y = 4321 and calculates g^y mod p = 10^4321 mod 17389 = 16077 They exchange, so Alice receives GY = 16077 and Bob receives GX = 9059 > 2. Alice calculates GY^x, which is g^(y*x). Bob calculates GX^y, which > is g^(x*y). Alice calculates 16077^53 mod 17389 = 11643 Bob calculates 9059^4321 mod 17389 = 11643 > 3. These are equal, so they use them as their shared secret value. Alice and Bob agree to the shared secret 11643. > An observer sees only GX and GY, and without knowledge of x and y is > unable to calculate g^(x*y). * DH-based identification protocol For this example, suppose we use g = 10, p = 17389 as above. Also, Paul chooses x = 555 to be his private key, therefore 10^555 mod 17389 = 11106 is his public key. > 1. Vicki chooses a random y and sends GY = g^y to Paul. Vicki randomly chooses y = 1994, so she sends 10^1994 mod 17389 = 13848. > 2. Paul calculates GYX = GY^x = g^(y*x) and sends that back to Vicki. Paul calculates 13848^555 mod 17389 = 8324, and sends it back. > 3. Vicki confirms that GYX = GX^y; both should be g^(x*y). Vicki checks 11106^1994 mod 17389 = 8324. This matches what Paul sent back. * Schnorr identification protocol > 1. Paul chooses a random w and sends GW = g^w to Vicki. Paul chooses w = 200, and sends 10^200 mod 17389 = 14097 to Vicki. > 2. Vicki chooses a random c and sends it to Paul. Vicki chooses c = 561 and sends this to Paul. > 3. Paul calculates r = cx+w and sends that to Vicki. Paul calculates r = 561 * 555 + 200 = 311555. > 4. Vicki confirms that g^r = (GX^c)*GW. Both should be g^(cx+w). Vicki checks: 10^315555 mod 17389 = 4594 (11106^561) 14097 mod 17389 = ((11106^561 mod 17389) * 14097) mod 17389 = 4594 * Chaum discrete log interactive signature protocol Here, we'll pick m = 1040. Thus, Paul can calculate MX = 1040^555 mod 17389 = 8608 > 1. Paul chooses a random w and sends GW = g^w and MW = m^w to Vicki. As above, Paul chooses w = 200, so he sends GW = 14097 and MW = m^w mod p = 1040^200 mod 17389 = 472 to Vicki. > 2. Vicki chooses a random c and sends it to Paul. She chooses 561 again. > 3. Paul calculates r = cx+w and sends that to Vicki. He calculates 311555 again. > 4. Vicki confirms that g^r = (GX^c)*GW. Both should be g^(cx+w). She > also confirms that m^r = (MX^c)*MW. Both should be m^(cx+w). Vicki checks g^r as above. Now she also checks: m^r mod p = 1040^311555 mod 17389 = 13723 (MX^c)*MW = (8608^561)*472 mod 17389 = 13723 * Chaum discrete log signature protocol Well, this is similar to the above protocol except a hash function is used. I'll do something similar for Hal's other posts as time permits. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLl5uPsSF/V8IjI8hAQE4/AP/VNauuo2nIWvF7xukbh6zNXK/pTnD7vGM 7jQeD9Hk7z9a/GXD2OTjlKUf1HAtFRkPB95X3HS/u5TzO1RdUIoxuiUok38At8vX UUBaRXaF6JJUI8xkvgOt9qCrSnZNKhjh4wZ2JxxOUY/0rB/1TBRzPe/MIIzyy0Ee bKaCRv+gJLA= =esaf -----END PGP SIGNATURE-----

2 1

Re: DSPs
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408262009.NAA17046(a)unix.ka9q.ampr.org> Phil Karn writes: > > Yes, but even scalar multiplication is so much faster on a DSP than on > most general purpose CPUs that it seems like a definite win. The 486 > takes from 13-42 clock cycles to perform a multiply, depending on the > operand sizes and number of significant bits in the multiplier. The Motorola DSP96002 does an integer multiply in 2 or 3 clocks, so a 33 MHz device does 11 million multiplies (and moves) a second. The chip costs about $50. The newer TI C40 does a 32-bit integer multipy in 1 clock, so a 50 MHz device can output 200 MB/s of results. It can read in a single clock cycle but writes take two cycles (sometimes more). So although it can theoretically read 200 MB/s, it can only write 100 MB/s. However, it has six serial links, each one of which has a 20 MB/s bandwidth, so in theory it can pump out 100+120 = 220 MB/s. However, in practice you would expect the chip to be I/O bound. It costs something like $200 a chip. The real advantage of the C40 is that C40s can be connected together using their serial links. This allows them to be arranged in interesting 3D topologies. In this respect the C40 is intended to be an upgrade on the transputer, which has only four links, and tends to die when connected into large 2D meshes, because the transputers spend too much of their time passing messages. If C40s are connected in pipelines, with three links used as input from the preceding stage and three links used to drive the next stage, you can run them comfortably at 60MB/s. You might choose to do three multiplies on each 32-bit operand at this rate, giving you effectively multiplications at 45 MHz at each stage of the pipeline. > Even > if you couldn't keep the pipeline full on a chip like the PowerPC, you'd > still be well ahead. Ahead of the 486 maybe, but the C40 makes the PowerPC a dog. > But then I hear people say that it's not the multiplication that slows > down modular exponentiation, it's the modular reduction. Can you elaborate? -- Jim Dixon

2 1

No Subject
by Anonymous 17 Dec '03

17 Dec '03

I thank Hal Finney for his thoughtful reply, and Tim May for his excellent essay. It looks like we can start to draw a stronger conclusion: there are serious holes in the assumptions made by offline digital cash protocols when applied to computer networks rather than manually operated smart cards. Hal's comparison of coin theft to digital signature protection and repudiation is apt, but usually Irving only has one or a few keys to protect, while he might have thousands of coins, issued by various banks. I doubt digital signatures will ever be used alone much for signing expensive contracts. A digital signature on an expensive contract, in addition to being repudiable, will be suspicious, since if few people accept such signatures as strongly binding (the initial state), they will not be widely used on expensive contracts, and thus their existance on an expensive contract will be suspicous. I predict it will become common practice, or even law, that digitally signed contracts over a certain amount are automatically invalid unless further precuations have been taken (signatures of notary witnesses, or perhaps some better crypto protocol designed for this purpose). The trouble with offline cash in a network environment is that the upper limit for fraud liability can be incredibly high. If there are hundreds of thousands of vendors on the net, a situation CommerceNet predicts before the end of the decade, and they are using this offline protocol, then even with small transactions the fraud could run into the millions of dollars. There's plenty of incentive for Irving to steal Jane's coins, run off to some place on the net that has no extradition treaty, and pump good change out of the vendors and into his Lichtenstein account to his heart's content. We may yet find protocols to mitigate or limit this kind of fraud -- make change traceable if linked to double spending, do random online checks as a cypherpunks poster suggested last year, or similar precautions layered on top of the basic protocol. But so far these problems haven't been put on the front burner of digital cash design, and already we have people out there selling offline cash on the network as a superior solution! Reliance on law enforcement flies in the face of cypherpunk goals, and indeed against the goals of good cops as well -- one of their most vocal complaints is about people setting up systems that are vulnerable to crime, putting them in unecessary danger. It also goes against political reality to think that a startup operation can lobby governments all across the globe to protect a system that is ideal for money laundering and tax evasion. Ain't gonna happen -- they'll let those "dirty money banks and money laundering net sites" rot; they may even give Irving a helping hand. I disagree that "there is no excuse" for double spending. If the software is implemented badly (no fault of the user), it might get mixed up with systems programs in such a way as to cause double spending. For example, if the system crashes and one must recover from a month old backup, one has to go through that old purse and determine which coins have been spent. If the software and/or user makes a mistake in this process, we get double spending. If a network burps and sends a vendor two coins where there should have been one, we get double spending. The possibilities for accident are legion and cannot all be foreseen. "Shit happens". A protocol that treats common accident the same as criminal fraud, when the stakes are so high, is pathological. In the online system the consequences of double spending (or million spending) are far more benign. At worst one customer is out stolen coins. In a networked offline system those same few coins are a potential loss for every vendor on the net. As Tim May noted, we may not even need to recongize fraud in online cash -- just treat all online double spending as accident. No bonding, secured accounts, investigators, ID badges or cops with guns busting down Janes's door after Iriving has million-spent her coins. Here we both have a simple liability system and much less chance of fraud. Tim May also suggested that most offline protocols are intended for manually used smart cards. This makes sense -- unlike an network environment with automated spending agents, the scope of multi spending for manually used pruchases in small amounts is quite limited. On the network even fraud of a few cents per transaction can quickly add up to big $$$ across thousands of vendors. What are the communications costs of online clearing, anyway? Don't credit card clearings cost about two cents per transaction these days? If clearing costs are less than plausible offline cash fraud and fraud prevention costs, online cash is a winner, both now and increasingly in the future as bandwidth becomes even cheaper. sincerely, -- An Unauthenticated Agent with no credentials: WYSIWYG

3 2

Re: DSPs
by Phil Karn 17 Dec '03

17 Dec '03

>This is somewhat different than the kind of fast multiplication you are >looking for. Yes, but even scalar multiplication is so much faster on a DSP than on most general purpose CPUs that it seems like a definite win. The 486 takes from 13-42 clock cycles to perform a multiply, depending on the operand sizes and number of significant bits in the multiplier. Even if you couldn't keep the pipeline full on a chip like the PowerPC, you'd still be well ahead. But then I hear people say that it's not the multiplication that slows down modular exponentiation, it's the modular reduction. Phil

3 2

Re: DigiCash ???
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408281521.AA13945(a)ua.MIT.EDU> Jason W Solinsky writes: > > I would like somebody to explain how I would go about using an anonymous > > digicash system to buy a automobile? > > > > Just for arguments sake lets say I want to buy a new Ford Mustang GT from > > the local dealer and desire that nobody at the dealer has any idea who I > > am or where I come from. > > You hire an anonymous reshiper... no different from an anonymous remailer > only you can't use an automated program (yet :) and its damn difficult to > avoid traffic analysis. Do we care that you can't get it on the road without insurance in most states, and that the registration must be in someone's name? -- Jim Dixon

2 1

FCC and Crypto
by John Young 17 Dec '03

17 Dec '03

Keep it up. Literate writing is ur-code. Crypto-tech entrepreneurs will smell the coffee. John

1 0

Re: DSPs
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 13:09 1994/08/26 -0700, Phil Karn wrote: .... >But then I hear people say that it's not the multiplication that slows >down modular exponentiation, it's the modular reduction. .... Modular reduction is scarcely worse than the multiplication. If I have a 60 word multi precision number N to be reduced by a 30 word number M, I compute a guess by dividing the 32 bit most significant bits N by the most significant 32 bits of M. I then multiply this quotient by M and subtract that from N. That reduces N by some multiple of M leaving N mod M unchanged. The error in the guess might mean that N is less than 32 bits shorter than it was before the operation but this method gets nearly 32 bits per pass. The inner loop of the is the same as in multiplication. For all of this using the floating point unit wins on most modern CPUs.

1 0

Golbal Econ.
by Rick H. Wesson 17 Dec '03

17 Dec '03

With topics like buying a car with digital cash make me think some may be missing my point. I don't want to replace all currencies world wide with some implementation of digital cash, be it an on or off-line system. I would like to help get an internet economny going! For the internet to become a source of greater revenue I'd like to see a system that can securely make business transactions that we are all happy with. The amounts should be small transactions compaired with selling a car, I'd like to know how I can pay for some online information without having to have an account based with the information supplier. For starters how can I pay for some HTML page or purchase a physical product via CURRENT technologies on the internet. Lets first start an internet cash system before you go off and let our ego's make all other forms of hard currency obsolette. -Rick

1 0