- cypherpunks-legacy@lists.ogf.org

Key swap in Vancouver, BC, Canada, anyone?
by andrew_derry＠sfu.ca 10 Dec '92

10 Dec '92

Is anybody in, or comming to, Vancouver, BC that I could swap public keys with? Thanks. --- Andrew Derry | ACS@HCC - Simon Fraser University | Internet: derry(a)sfu.ca |

1 0

No Subject
by hughes 10 Dec '92

10 Dec '92

Fourth Meeting When: Saturday, Dec 12, 1992, 12:00 noon Where: Cygnus Support offices Schedule: Noon Schmooze, key exchange 1:00 Business 5:00 Adjourn Agenda: 1. Media coverage. Do we want to deal with the press? If so, how? 2. Reputation Systems. Dean Tribble presenting. 3. Authenticated Diffie-Hellman (STS). Arthur Abraham presenting. 4. Reports Notes: 1. Please be prompt. We will begin the business section at 1:00 sharp. 2. Bring a portable computer and your key rings for PGP key exchange and signing.

1 0

'token exchange' market in Arizona
by Edward Vielmetti 10 Dec '92

10 Dec '92

For you all. Interesting because it would appear to be a real live marketplace, with real live money, tho no crypto per se in there. --Ed ------- Forwarded Message From: rkeca04(a)uts.manchester-computing-centre.ac.uk (Thomas Krichel) Subject: Arizona token exchange To: cti-econ(a)mailbase.ac.uk Date: Thu, 10 Dec 92 11:55:03 GMT Greetings, this is an item from corryfee. Apologies to those who have already seen it. I thought it was sufficiently interesting to pass it on. BTW, the some of the results of the Santa Fe experiment, to which the text refers, will be published in a forthcomming book by John Rust and Dan Friedman "Double Auction Markets: Theory, Institutions, Evidence". Publisher is Addison-Wesley (Santa Fe Institute series On Studies in the Science of Complexity). Cheers, ______ / / Department of Economics / /_ ________ __. _ University of Keele / / /_(_) / / <_(_/|_/_) ST5 5BG _ , _ Great Britain ' ) / / // Tel.: 44 - 782 - 714847 /-< __ o _. /_ _ // Fax: 44 - 782 - 717577 ./ )/ (_<_(__/ /_</_</_ E-mail: Krichel(a)uts.mcc.ac.uk > > > > > ANNOUNCING THE OPENING OF THE > > ARIZONA TOKEN EXCHANGE (AZTE) > > January 1, 1993 > > Earn cash profits by competing against computerized program traders > > THE CHALLENGE > > Is "artificial intelligence" superior to human intelligence? In > some domains such as chess, computer programs now outperform all > but the very best human players. However in other domains such as > speech, handwriting, and other kinds of pattern recognition, > computers lag far behind human beings. On Wall Street computer > "program traders" are becoming increasingly common, yet there is > substantial controversy over their performance -- they have even > been blamed as a factor in the October 1987 stock market crash. > The purpose of this study, co-sponsored by the University of > Arizona's Economic Science Laboratory and the Santa Fe Institute, > is to compare the performance of human and program traders to see > whether humans can learn to exploit the limitations and > idiosyncracies of computers in repeated interactions. > > THE ARIZONA TOKEN EXCHANGE > > To compare the performance of human and program traders we have > created a computerized market, the Arizona Token Exchange (AZTE), > in which a fictional commodity, "tokens", are traded. The market > is a simplified version of commodity exchanges such as the Chicago > Board of Trade where buyers and sellers are able to call out bids > and asks to buy or sell units of the commodity. In each trading > session on AZTE traders are assigned the role of buyer or seller > and are given an allocation of tokens. A seller's objective is to > sell their tokens for as much as possible above the token cost and > a buyer's objective is to buy tokens as cheaply as possible below > their redemption value. > > By ranking the token costs and redemption values, well-defined > supply and demand curves can be constructed. The intersection of > these curves defines the so-called competitive equilibrium (CE) > price and quantity, at which neoclassical economic theory predicts > all trading will occur. The complication is that in the AZTE, > each trader's token costs and redemption values are private > information and differ from trader to trader. Thus traders in the > AZTE face a complex sequential decision problem: how much should > they bid or ask for their own tokens, how soon should they place a > bid or ask, and under what circumstances should they accept an > outstanding bid or ask of some other trader? An additional > complication is that each trading session runs for a fixed amount > of time. This creates a difficult trade-off, for if traders spend > too much time looking for a good deal, they may find themselves > locked out of the market without trading anything. > > HOW IS TRADER PERFORMANCE EVALUATED? > > In the AZTE there is a well-defined performance measure: trading > efficiency, EFF. This is the ratio of profits a trader actually > earns divided by the profits it would have made if all trades took > place at the competitive equilibrium level. Thus, if a trader's > EFF is greater than 100% they are earning more than their "fair" > share of the profits. The use of EFF is more desirable > performance measure than simply using trading profits, since > profits depend on the token allocations which are allocated at > random from a known distribution. > > After each trading session, participants will earn cash profits > equal to the following linear function of their efficiency: > > $ payments = a + b(EFF-100) > > The term a represents a fixed fee paid for participating in the > trading session and the term b(EFF-100) represents a bonus > (penalty) for trading above (or below) 100% efficiency. Thus, it > is possible to lose money in any particular trading session. > Dollar earnings are cumulated over successive trading sessions and > subjects are eligible to "cash out" at any time after participating > in a minimum number of trading sessions (provided cumulative > earnings are positive). > > THE OPPONENTS: COMPUTER PROGRAM TRADERS > > Unlike real commodities markets where most traders are humans, in > the AZTE all of your opponents will be computer programs. The > opponent programs will be selected from a field of over 30 > different trading strategies including winners of the Santa Fe > Institute's Double Auction Tournament held in March, 1990. The > program traders range in sophistication from simple rules of thumb > (such as Gode-Sunder "Zero-Intelligence" strategy) to sophisticated > optimizing/learning algorithms (such as neural nets and genetic > algorithms) developed from the recent literature on artificial > intelligence. The identities of your opponents will (usually) be > revealed to you at the start of each trading session. You will > also be informed about other market characteristics such as the > number of buyers and sellers, the number of tokens, and the joint > distribution from which token values are drawn. > > SETTING UP AN ACCOUNT > > To trade on the AZTE you will need a Unix or PC-compatible computer > linked to the Internet computer network. We provide the trading > interface software that allows you to log on and trade at any time > you like and for as long as you like (subject to general > restrictions). To qualify for an AZTE trading account you need to > file an application providing information on your address, phone, > and email address, and a release form stating whether or not you > want to remain anonymous in published analyses of the outcome of > this experiment. Upon receipt of the application we will set up a > trading account and access password. Your dollar earnings will > cumulate in your account until you decide to cash out, at which > time we will close your account and mail you a check for the total > amount of your earnings. > > The software and ASCII traders' manual (including the application > form) is available via anonymous ftp on "fido.econ.arizona.edu", in > the azte sub-directory. The manual (azte.man) explains how the > software works and what is required to use it. We suggest you ftp > this first and read through it, then get the appropriate trading > interface for your system. The DOS interface requires VGA graphics > resolution and the use of Clarkson packet drivers for the network > interface card. The Clarkson drivers are also available via ftp on > "fido.econ.arizona.edu". > > If you don't have access to anonymous ftp, we will mail you a > diskette containing the software and trader's manual. To cover the > costs of a diskette and surface mail, send $5.00 to: > > Shawn LaMaster > Manager, Economic Science Systems Development > Economic Science Laboratory > McClelland Hall, Room #116 > University of Arizona > Tucson, Arizona 85719 > (602) 621-6218 > > Internet: lamaster(a)ziggy.econ.arizona.edu > > We will assist in ftp and setting up the Clarkson packet drivers, > just give us a call. > > > The AZTE software was co-developed by: > > Sean Coates Economic Science Laboratory, University of Arizona > Shawn LaMaster Economic Science Laboratory, University of Arizona > Richard G. Palmer Duke University > John Rust University of Wisconsin > Vernon L. Smith Economic Science Laboratory, University of > Arizona > ------- End of Forwarded Message

1 0

remailers, the prime user of bandwidth in the US (well, not yet)
by nobody＠soda.berkeley.edu 10 Dec '92

10 Dec '92

Could all remailer operators please mail me (hh(a)soda.berkeley.edu) the following information so that I can set up a remailer directory? There are so many remailers right now that this needs to be done: 1) address to mail to. for instance, hh(a)soda.berkeley.edu 2) how it works. what lines to put in the header, how to give it a pgp block, etc. 3) pgp key (if used) 4) how to contact the owner. this may be anonymous. you can easily set up your mail delivery file to have a Purpose: field and check it for "contact-owner" which would then forward the mail to the owner. 4) owner's name and email address (optional). I will compile all of this information and put it up for ftp on soda. e

2 1

Experiments in Digital cash
by Alan Hunter 09 Dec '92

09 Dec '92

On Wed, 9 Dec 92 02:25:49 -0800, "John Draper" <crunch(a)netcom.com> wrote: > Cm'on Alan, give us unemployed folks a break. Life's a bitch already > for us unemployed folks. To have to pay to get Cypherpunks mail > would not go very good. Just in case... I meant as an experiment in the use of digital cash and banks. I'm sure that DigiBank Inc would give us all an overdraft facility for starters. Alan

1 0

Re Anonymous address problems etc
by Alan Hunter 08 Dec '92

08 Dec '92

On Mon, 7 Dec 92 16:59:12 PST, (Hal Finney) ghsvax!hal(a)uunet.uu.net wrote: > > On the digital cash issue - I think we should get some kind of > implementation of digicash (oops, "electronic money") out for people > on the list to play with. Then, we should think of some kind of > experimental email-based game to play which would use the special > characteristics of anonymous cash. Maybe we could use the remailers, > too. Players would send cash back and forth to each other as part of > the game. Even if the tools are sort of rough at first, this could > show where the most work is needed. > > Can anyone think of a good kind of game that we could play? How about making cypherpunks a subscription mailing list, and paying contributors? Alan

1 0

PGP key generation
by ghsvax!hal＠uunet.UU.NET 08 Dec '92

08 Dec '92

Steve Witham asks about PGP's "peasant_modmult" routine, how it can subtract the modulus on each addition. It doesn't, but the code is a little misleading (taken from mpilib.c, PGP 2.1): while (bits--) { mp_shift_left(prod); msub(prod,pmodulus); /* turns mult into modmult */ if (sniff_bit(multiplier,bitmask)) { mp_add(prod,multiplicand); msub(prod,pmodulus); /* turns mult into modmult */ } bump_bitsniffer(multiplier,bitmask); } What is confusing is that "msub" looks like "mp_sub". Actually, msub is a macro defined in mpilib.h: #define msub(r,m) if (mp_compare(r,m) >= 0) mp_sub(r,m) /* Prevents r from getting bigger than modulus m */ So, msub actually only subtracts if it's necessary, as would be expected. Jim McGrath asks: > When PGP generates keys doesn't it always pick d and e to have > the same number of bits, ie 446 for the strongest type? d and e are the decryption and encryption exponents. e is chosen to be small, typically the number 17 or slightly larger. d is then about the size of n, your key modulus. p and q, the two primes which are multiplied to get n, are about the same size, usually. PGP does have some code to make sure they aren't too close to the same size (taken from rsagen.c, PGP 2.1): /* See if p and q are far enough apart. Is q-p big enough? */ mp_move(u,q); /* use u as scratchpad */ mp_sub(u,p); /* compute q-p */ if (mp_tstminus(u)) /* p is bigger */ { mp_neg(u); too_close_together = (countbits(u) < (countbits(p)-7)); } else /* q is bigger */ too_close_together = (countbits(u) < (countbits(q)-7)); /* Keep trying q's until we get one far enough from p... */ } while (too_close_together); What this does is make sure that |p-q| is > 1/128 of the larger of p or q. This is designed to make sure that p and q are both very far from the square root of n. I.e. if n were 1024 bits, p and q could both be about 512 bits, but they would be at least about 2^505 from the square root of n, foiling the square root attacks. Hal 74076.1041(a)compuserve.com

1 0

No Subject
by McGrath, James 08 Dec '92

08 Dec '92

Karl said: > Also, p and q should differ in length by a few digits otherwise > an enemy may begin to try factoring n by starting near sqrt(n). When PGP generates keys doesn't it always pick d and e to have the same number of bits, ie 446 for the strongest type? Is this the same thing? I suppose that if you are allowed leading 0s it isn't a problem at all, but if the first couple of bits were ones in each key, (a 16:1 chance) wouldn't that significantly reduce the power required to factor the PK using this approach? Just a thought, Jim

1 0

Re: PGP questions
by fnerd＠smds.com 08 Dec '92

08 Dec '92

>It's probably good to discuss how PGP works here, for educational >purposes, but I would expect people to get the source code if they >really are interested. I can give some pointers here to answers to >some of the questions people have asked. Thanks for the answers, Hal. I have been digging into the original RSA paper and the PGP 2.0 sources. By the way, sorry if my response time is long; I've been traveling for work lately. I suggested leaving the minimum set of compute-intensive routines in C and implementing the higher-level stuff in some higher-level language ("HLL"), possibly interpreted. Hal pointed out some of the crunching jobs other than modmult. Using an HLL has cons as well as pros to it. The main advantage (for my purpose here) is that C code has a lot of noise that gets in the way of understanding. This could also be improved by some coding style changes--for instance, using some object-oriented stuff (data structures that handle more of their own details) and, ahem, fewer #ifdefs... Another advantage of an HLL is ease of trying out different, er, schemes. If I used an HLL, I think it would be one that had very C-like syntax. The main drawback of an HLL is that it's another program that you have to trust. Sometimes inner parts of interpreters and compilers are hard to write so that they are correct *and seem* correct when you look at them. A couple of things they can do are automatic space allocation, garbage collection and "burning" data that's no longer in use ("garbage burning?"). -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

peasant_multiply question
by fnerd＠smds.com 08 Dec '92

08 Dec '92

Folks-- I got out my copy of the original RSA paper, and I'm comparing it to the PGP 2.0 code. I have a question about the peasant_modmult routine (the simplest modmult in PGP). Here's pseudocode of what I think it's doing: /* Inputs: modulus, multiplier, multiplicand */ /* Output: prod */ prod = 0; set sniffer to most significant bit of multiplier; nbits = number of significant bits in multiplier; while( nbits-- ) { shift prod left 1; prod = prod - modulus; if( the bit of the multiplier being sniffed = 1 ) { prod = prod + multiplicand; prod = prod - modulus; } move the sniffer to the next bit of the multiplier; } My question is (assuming I'm understanding the code right), how can it work subtracting modulus unconditionally all the time? Won't it make prod negative sometimes, and then keep multiplying the negative number by two until it overflows? Isn't that a problem?? -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0