- cypherpunks-legacy@lists.ogf.org

CHATTER Re: Broadcast/Filter vs. "Fetching"
by fnerd＠smds.com 07 Dec '92

07 Dec '92

(I put "CHATTER" in the subject line as a clue that this is general talk off the subject of directly implementing crypto stuff.) Yanek Martinson <yanek(a)novavax.nova.edu> sent an interesting message to me--I think he meant to post it--in response to my gripe: >> (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews, >> CD ROMs, and cable TV. I want things available for me to go fetch.) > >But if you have the disk space and bandwidth to spare, it really does >make sense to receive everything and then decide what you want. Perhaps our company could make room for a couple days worth of the complete netnews. But, o That's hardly all the information there is. o I could never read it all, and I don't trust computer filters much. o I don't want to be a slave to the newsfeed/use-it-or-lose-it deal; I want to follow threads into the past, at my leisure. I want to let some discussions cook and then come back to them. >In your "fetch" scenario, what if I don't like (strongly) what Joe wrote. >So I can nuke Joe (or his archive) and no-one can "Fetch" the article. This is what I found interesting. You would really like the network (some network) to support distributed redundant archives, preferably with cross- checking. It would be even nicer if information could be stored, with storage cost charged to the owner and/or readers, and yet not have it knowable where the information was. Somehow a backwards mix setup. Put on your crypto thinking caps, kids. >On the other hand with the current set-up, it has already propagated >to hundreds of thousands of sites and it's impossible to stop. Yes. But, say, tens of untraceable sites would be okay. The flip side of 100K x redundancy is the little emily postnews handslap--"ARE YOU SURE?"-- and the rigamarole over creating new groups, and whether all the machines between you and the center of the universe get all the groups, etc. Plus the fact that most sites delete the stuff after a week or two, and all the effects on people's writing that has. >Also, if you want to filter stuff, then you should pay for the CPU >that does the filtering for you. My brain filters my mail! Boy do I pay for it! >Why would you expect someone else >to run your filter on their machine just so you would know if you >wanted to fetch their article. ?? I don't want machine filtering at all. Mostly I want references I can follow up easily. That's what fetching means. >Maybe I did not understand what you meant by "fetching". Hope it's clearer. >Could you describe your idea in more detail? >I absolutely agree that most of what comes in over my >newsfeed is junk, I just don't see a good way of >fixing this problem while retaining the robustness >and widespread communications capability. > >> -fnerd >> quote me...within *reason* of course > >(I guess 4 lines (including the sig) is well within reason) -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

yet another remailer
by nobody＠ocf.Berkeley.EDU 07 Dec '92

07 Dec '92

I've set up another remailer, this one on my ocf account. It's also based on Hal's (very easy to use and useful) script and does not yet have encryption because pgp201 is not the most portable thing around. To use, just do the standard thing: send mail to hh(a)ocf.berkeley.edu with the line: Anon-To: or Request-Remailing-To: and it will do the rest. Have fun! e

1 0

No Subject
by nobody＠soda.berkeley.edu 06 Dec '92

06 Dec '92

Cypherpunks! Like several people (I guess), I am working on an implementation of digital cash. Because of the possible legal repurcussions, I'd prefer to remain anonymous at this time. Thanks to the efforts of the people on this list, this is now possible. My implementation is pretty far along. It uses PGP modules for the arithmetic, so the speed is good. It works on Unix and I should be able to get it working on MSDOS in a day or two. Sorry, I don't have the ability to work on a Mac version. Here are some of the features. The basic cash algorithm is the Chaum system which was posted here. Multiple denominations are supported, using different exponents for each denomination. The program is presented in the context of a package to be used for an email based game like Monopoly where the program would be used to allow cash transfers. One player is the "banker", and he uses a different execution module than the other players. The banker program keeps a database of used note numbers which is used to detect money reuse. The database is maintained using a freeware version of the "dbm" package, so it should be fast even for large note number databases. The mapping between exponents and values is as follows: exponent value 17 1 19 2 23 5 29 10 31 20 37 50 41 100 43 200 47 500 53 1000 59 2000 61 5000 67 10000 and so on, up to a value of 2e9. The exponents are ascending primes starting with 17. This was chosen because you want them to be smallish for fast note checking, but it was too slow to find primes p and q for the bank key such that (p-1)(q-1) was not divisible by any small primes. The program chooses random p and then tests p-1 to make sure it passes the divisibility test, and rejects it if not. Too many were being rejected when I started with an exponent of 3. Starting with 17 rejects about 1/2 the exponents, compared to something like 80% when I started with 3. The "value" fields are presumed to be cents, but could be whatever you like. The code I've written does not do anything other than the basic electronic cash algorithms. It does not do bank account maintenance. It doesn't do PGP encryption. It doesn't send mail. (It does have some functions to scan and check the files created by the program.) Cash generation is a 3 step process. First, the user creates what I call a "withdrawal request" packet. This is a set of triplets of the form (e, s, refx), where e is the exponent from the table above, s is a 16-byte "unique identifier" used solely to link these withdrawal requests with the returned messages from the bank, and refx is r^e * f(x). f(x) is MD5 of x, padded to the size of the bank's modulus n using the PGP routine which pads MD5 signatures. This padding helps make sure the arithmetic is more "mixing". x is the random input to MD5, which I've chosen as 64 bytes since that is the block size MD5 works on. (The output of MD5 is 16 bytes.) r is the blinding factor. This is now 128 bits long; longer r's take too long to calculate r^-1 in the third step, below. (It takes longer for PGP to calculate r^-1 than to do an RSA decryption, for r = n = 1024 bits!) Second, the bank program converts the withdrawal request packet into what I call a "withdrawal" packet, by just RSA-decrypting the third entry using the inverse exponent "d" for the value exponent "e". (These "d" values are calculated at keygen time and stored with the bank's key information in a private file.) I call the return triplet (e, s, rfxd), where e is the value exponent again, s is the same unique identifier, and rfxd is r * f(x)^d. (As I said above, the code I've written does not try to maintain account balances or do any other banking functions. It just does the cash algorithms. There is a routine to scan a withdrawal request and return the total value being requested for withdrawal. The idea was that this could be used as input to a banking program to decide whether to allow the withdrawal.) Third, the "player" (e.g. user) program transforms the withdrawal packet into a "money" packet, by un-blinding it. To do this, it has to recover the x and r which correspond with each triplet. This is done by the use of a dbm database of "pending withdrawal requests" which is written during step 1, above. The database entries are keyed by (e, s) and return the corresponding (x, r) which were generated during step 1. Using x and r, the user transforms (e, s, rfxd) into (e, x, fxd), the digital cash. e is the value exponent, x is the random 64-byte number, and fxd is f(x)^d, the signed version of the MD5'd and padded x. There are also player functions to scan and check a money file (comparing a calculated f(x) to fxd^e), merge money files, and extract some items from a money file into another money file (this last is what is to be used for payment). There are banker functions to check incoming money and compare against the used-note database, and to add incoming money to that database. (The database consists of the 16-byte f(x) values for each note.) I am pretty happy with the basic routines, but the user interface needs work. There are three kinds of files floating around (withdrawal requests, withdrawals, and money files) and I'm worried that this will be confusing to the user. If he accidentally deletes one at the wrong time he could lose money permanently. Or if he accidentally reuses one he could be accused of fraud. I'm not sure what the best model is for the user. The specific issues of creating withdrawal messages and extracting "bills" from a money file are areas where the user interface should be made nice. We want to make it easy for the user to specify exactly what denominations he wants to work with. One possibility is to simply have him input the amount (e.g. $10.55) and the program calculates that that's a 1000, a 50, and a 5, but this isn't really flexible enough. A nice system would be to give him a list of options and let him fill out a form on-screen, but that's hard to do portably. Another idea I've had is that there should be a special money file called the user's "wallet" which is the default place where incoming money from the bank should go. This might help organize things. He still needs to be able to create other money files for paying other people, and remembering to delete them after he sends them. Any suggestions or thoughts on these interface issues, or comments about how this program could or should be integrated into a larger system, would be appreciated. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq -----END PGP PUBLIC KEY BLOCK-----

1 0

this is a test
by nobody＠soda.berkeley.edu 06 Dec '92

06 Dec '92

igonore this message... e

1 0

subscribe me
by habs＠acf3.NYU.EDU 06 Dec '92

06 Dec '92

subscribe me -- habs(a)acf3.NYU.EDU habs(a)gnu.ai.mit.edu habs(a)well.sf.ca.us habs(a)panix.com

1 0

remailers
by nobody＠soda.berkeley.edu 06 Dec '92

06 Dec '92

Remailers are proliferating! Several more will be coming on line soon! Two thoughts: Remailers should keep a directory of other remailers, along with their keys. They should, at random intervals, send messages to other remailers, selected at random. They should have a field like Purpose: traffic-analysis If a remailer on this "ring" sees this field, it will have, say, a 90% chance of remailing to another remailer in the ring, again, encrypted and with the traffic-analsysis field. This will cause a certain amount of random traffic between remailers. A traffic-analysis message could bounce around many times before finally ending up in the great /dev/null. We need two other things: overseas remailers (for those of us who live under US law). Domestic (US) remailers could have their archives searched with a searchwarant. However, if your mail has gone accross the oceans a few times, it would be pretty much impossible to get the neccessary warrants and cooperation in all the countries its been through. I'll set up a European remailer if someone else will. The other thing we need to do is make a list of remailers and their keys and put it up for ftp on soda.berkeley.edu in ~ftp/pub/cypherpunks. In fact, there could be an automatic service, whereby remailers automatically send mail to a remailer at soda, listed their keys and protocols, and the soda remailer automatically updates a remailer directory. e

1 0

Hardware RNGs
by Joe Thomas 05 Dec '92

05 Dec '92

I just joined the list (rather loudly, I'm afraid), but I've already seen several writers complain about the quality of RNGs and PRNGs for the purposes of cryptography. PGP stores up keystroke-derived random bits in a file, which has been pointed out as a possible security hole. But requiring random keystrokes every time one wishes to send a message seems an inconvenient tradeoff, to say the least. Someone posted a plan for a Zener diode-based hard RNG on sci.crypt a few weeks ago. I'm not much of a solderer normally, but this seems like a good idea if anyone out there has tried it out and tested the output for nonrandomness. (Of course, ideally we'll have alpha-decay-based RNGs --guaranteed random by the laws of physics-- but I'll settle for thermal noise on the cheap for the moment). Anyone tried these yet? More to the point, does anyone have some code patches for PGP to use a hard RNG preferentially over other random bitstreams? (Yeah, it would be pretty easy, but there's no sense in duplicating effort if we could get something standardized, pretty and portable agreed on.) Joe P.S. Sorry about the wasted bandwidth last week. My fingers were moving faster than my brain, but I should have recognized this address as a probable mailing list. Thanks to all who politely directed me to the -request address.

1 0

First digital money?
by edgar＠spectrx.Saigon.COM 05 Dec '92

05 Dec '92

Following cross-posted from Extropians: To: gnu.ai.mit.edu!Extropians Date: 02 Dec 92 11:31:59 EST From: Duncan Frissell <szebra!CompuServe.COM!76630.3577> Subject: If I only had $100K Bankers Trust has started a Global Settlement Fund to allow securities traders to make free funds transfers 24 hours a day. The Chicago Mercantile Exchange now accepts GSF shares in addition to cash and T-bills for settlement purposes. GSF shares will pay interest and there are no transactions charges for transfers. For now, the account minimum is $100,000 and participating institutions must have a link to Bankers Trust's New York operations center. The company plans to open similar funds denominated in Yen and Pounds Sterling. It also plans a BBS system which will allow traders to arrange forex exchanges with the holders of other currency shares 24 hours a day. Bankers Trust has targeted the Fed Wire that does 60 million transactions worth $200 billion a year but is slow and expensive. Now once such a system reaches the *retail* level we'll really have something. Duncan Frissell ******************************************************************************* * DUNCAN FRISSELL Attorney at Law, Writer, and Privacy * * CIS 76630,3577 Consultant since the Nixon * * Internet 76630.3577(a)compuserve.com Administration * * Easylink 62853962 * * Attmail !dfrissell * * TLX: 402231 FRISSELL NYK * * * * * Clinton Inaugural Sale - Any Question Answered for $9.99 * * * * ******************************************************************************* -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

test
by nobody＠soda.berkeley.edu 05 Dec '92

05 Dec '92

This is a test of my new anon-remailer based on Hal's code. It does not yet feature pgp (pgp is having a hard time compiling on soda, but that will change soon...) To use it, just use the Anon-To: field in the header and mail to hh(a)soda.berkeley.edu There will soon be an even fancier remailer at soda (and not running out of my account). Details as they become available. sincerely, nobody

1 0

getting .hqx files with ftpmail
by fnerd＠smds.com 05 Dec '92

05 Dec '92

A note for fools like me trying to get Mac .hqx files through "ftpmail"... USE ASCII MODE! Otherwise it defaults to adding an extra layer of "btoa" encoding on the file (or you can switch it to uuencode, but why uuencode an .hqx file--it's already plain text). "btoa" files start like this: xbtoa begin wef9a87eg8a9wery8s7arg87gae8g7waeo87rwe8r(garbage)... as opposed to uuencoded files like: begin fred.txt aewhgp9ergu90ser890syuer98gse98r(garbage)... or .hqx files (this is from memory): (This file has to be decoded with BinHex 2.0) k9wegesz9p8rgy89serg9oser98ser98(garbage)... I don't know where to find "btoa," and ftpmail's help message just says to ask my local wizard. He never heard of it. --- Example request to ftpmail --- connect mac.archive.umich.edu cd mac/util/encryption ascii get macpgp2.0.sit.hqx -fnerd fnerd(a)smds.com (FutureNerd Steve Witham)

1 0