- cypherpunks-legacy - lists.cpunks.org

Unsubcribe
by George Leerhuber 17 Dec '03

17 Dec '03

Unsubcribe <lerhuber(a)joshuanet.com>

1 0

Re: Recommendation: Creation of "alt.cypherpunks"
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Dr.Dimitri Vulis KOTM wrote: > ichudov(a)algebra.com writes: > > > 1. A newsgroup like comp.privacy.cypherpunks will be carried on a lot of > > > corprate news servers that don't carry alt.* (or even soc.*). Note that > > > soc.org.cypherpunks is inappropriate since cp is *not* an organization. :-) > > > Another possibility is sci.crypto.cypherpunks. (True, people whose corporat > > > newsservers don't carry soc.* and talk.* can use dejanews - provided their > > > firewall lets them.) > > > > > 2. It takes more work to create a comp.* newsgroup than an alt newsgroup. > > > It takes a vote. I'm willing to be one of the proponents and generally help > > > with the process. (Both I and Igor have been co-proponents of major Usenet > > > newsgroups - don't know about other people onthis list. :-) > > > > Not only it takes a vote. What is more important is what a vote gives: > > a good discussion of the newsgroup and the formal RFD/RFD/CFV process > > ensures that, on average, a good balance is found between various groups > > of readers. > > > > I am not concerned as to what the name of the group will be, it is > > not important. What is important is that it should be in a more or > > less flame-free zone. > > I'm concerned about smart people stuck behind corporate firewalls > and able to see comp.* and sci.*. Nearly every big Wall St firm > is that way. Did I ever relate to you the story how I had to > break through the firwall at GS to accomplish mywork? Would be interesting. > > It is too late to stop alt.cypherpunks, but if I had to make a > > prediction again, I would predict that soon posters will BEG to help > > them create comp.*.cypherpunks, because of spam and alt.flamage. > > Timmy has a valid point: the reason why a comp.* newsgroup might have less > cross-posted and "off-topic" crap is because net.cops would be more > likely to complain to posters' sysadmins. Having a charter state that > cypherpunks have technical means to ignore traffic they don't like, > and don't need anyone forging cancels or complaining to sysadmins > or otherwise getting silenced, is a good idea. It is not only because of that. There are two categories of people who simply do not visit com.* groups: sex spammers and trollers (who post articles like I RAPED A NIGGER CHILD to tens of newsgroups). If the group is created in a space that is isolated from them, that is already good. As for net.cops, check out what Scott Nudds does in comp.lang.c++ > What's going to happen when (not if) someone posts something in > alt.cypherpunks that Chris Lewis (spit) judges to be "spam" > and forges a cancel? Or someone posts a binary and Richard > "little dick" Depew forges a cancel? Chris Lewis can exclude newsgroups from his spam watch. I think that if cypherpunks put something forbidding third party cancels into the charter, he will not cancel stuff posted there. > > > 3. An unmoderated Usenet newsgroup would have even ore crap than this maili > > > list. I've been thinking of how to deal with crap, and with the obvious des > > > by some people to delegate their decision what to read and what not to read > > > to other people. > > > > It is alt.* and soc.* that has most crap, sci and comp are way better. > > There's a bunch of net.cops in e.g. comp.lang.eiffel that complain to > sysadmins of anyone posting to that newsgroup who's in a member of the > "in" crowd". It may or may not cut down on the crap, but is it worth it? Yes, there is a notorious net.cop The Right Reverend Colin James III (spit). A sample of his stukachestvo is attached at the bottom of this letter. >From ares.csd.net!cjames Fri Dec 8 00:00:29 1995 Return-Path: <cjames(a)ares.csd.net> Received: from ares.csd.net by espcbw.stat.ncsu.edu.stat.ncsu.edu with smtp (Smail3.1.29.1 #5) id m0tNxjG-000EDPC; Fri, 8 Dec 95 00:00 PST Received: by ares.csd.net (5.65/DEC-Ultrix/4.3) id AA08055; Thu, 7 Dec 1995 22:02:44 -0700 Message-Id: <9512080502.AA08055(a)ares.csd.net> From: cjames(a)ares.csd.net (Colin James III (The Rt Rev'd)) To: ichudov(a)espcbw.stat.ncsu.edu (Igor Chudov), postmaster(a)espcbw.stat.ncsu.edu, postmaster(a)stat.ncsu.edu, postmaster(a)ncsu.edu Subject: Re: Nauseating typedefs -- pros and cons Date: Fri, 08 Dec 1995 03:13:53 GMT Organization: CEC Services Reply-To: cjames(a)ares.csd.net References: <461dph$ske(a)saba.info.ucla.edu> <48np3j$1b4(a)solutions.solon.com> <4a 7rpv$fj(a)taco.cc.ncsu.edu> X-Mailer: Forte Agent .99b.112 Status: RO On 7 Dec 1995 23:02:23 GMT, ichudov(a)espcbw.stat.ncsu.edu (Igor Chudov) wrote with possible deletions: | Douglas Evan Cook (cookd(a)bert.cs.byu.edu) wrote: | * The real question comes down to: when do you need to | * use INT32 or INT16? Usually, you only need it when you are saving info | * to a disk or when you need to make sure that your numbers won't | * overflow. A little bit of hardware control is also given. But when you | * don't get those advantages, a plain int is just great. | | It is NOT great at all. Each variable is associated with a range of | values. This range of values comes from the requirements of external world. | Say, some program _must_ be required by business rules to store | $$ amount as an integer value, and it may be specified in the | requirements that $$amount cannot be more than $1,000,000. If I, | as a careless programmer, program variable dollar_amount as int | just because my RS6000 has 32-bit ints, this program will NOT be | portable to 16-bit computers. | | You can invent an untold amount of such situations. If I defined | DollarAmount_t as UINT32, I would effectively avoid this trouble. | | * So for your scanf | * vars, just use ints. Then do range checking and then assign them into | * the UINT16 type or whatever only if you need to. | | The solution is very simple and cool (IMHO). | | In the same file where you define INT16, UINT32, etc, add the following: | | #ifdef AIX | typedef long INT32; | #define F_INT32 "ld" | | typedef unsigned short UINT16; | #define F_UINT16 "u" | #endif | | #ifdef YOUR_FAVORITE_MACHINE | typedef short INT32; // Maybe for 64-bit machines, never worked with them | #define F_INT32 "d" | ... etc etc ... | | Then you define your user types: | | typedef INT32 DollarAmount_t; | #define DollarAmount_f INT32_F // You make it a rule to define | // formats right along with types | | Usually, in scanf (and printf) people write things like this: | | printf( "%ld is the dollar amount for customer %4.4d\n", | amount, cust ); | | Instead, you write | | printf( "%" DollarAmount_f " is the dollar amount for customer " | "%4.4" Cust_f, | amount, cust ); | | It is a totally portable code. All you need to port primitive types | is to recompile it. | | -- | - Igor. (My opinions only) http://www.algebra.com/~ichudov/index.html | For public PGP key, finger me or send email with Subject "send pgp key" | | You know you have achieved perfection in design, not when you have nothing | more to add, but when you have nothing more to take away. | - Antoine de Saint Exupery. Kindly remove comp.lang.eiffel from distribution of this thread. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames(a)csd.net CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438; Data: .231.9434 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ - Igor.

1 0

Re: subscribe
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Sean Roach wrote: > ... > Something to consider. If anyone of the distributed remailers is removed > from a ring, the messages that need to travel across that ring can no longer > do that. This makes the loop only as strong as its most at risk remailer. > The star approach has already been seen in action, the trouble here is a > single choke point. > Full interconnectability is only feasible in a small net, but I would advise > this at first. Check for the x-loop to see if another one got it first. If > none, add one and send it on down the line. > A disjointed mess, if the remailers are given first access to the list, > could work quite well as long as that x-loop remained to point to who sent > the message, and the x-loop contained an unalterable message number, and the > remailers could eliminate duplications, probably based on message number. > This should work as the net grows and would only be as weak as the strongest > two connected remailers. > Sounds like the internet. > I'd suggest a simplier solution: to connect each server with a couple, or maybe three, other servers. This scheme is rather robust, does not consume too much CPU time and bandwidth, and is easy to implement. - Igor.

3 2

Re: anonymity and e-cash
by Sean Roach 17 Dec '03

17 Dec '03

At 04:59 PM 2/12/97 -0800, Hal Finney wrote: >From: tcmay(a)got.net (Tim May) >> You missed a very good talk by Ian Goldberg of UC Berkeley at the Saturday >> Cypherpunks meeting at Stanford, where Ian talked for more than an hour on >> just this issue. (He also talked for an hour on his crack of the RSA >> challenge using 250 workstations...this was also a good talk.) > >I wish I could have heard that, it sounds good... > >A simple idea we have discussed for full anonymity uses the idea of >exchanging coins at the bank. You make an anonymous connection to >the bank, supply some ecash you have received along with some blinded >new ecash. The bank verifies that the ecash is good and signs your >blinded ecash, sending it back to you. You unblind it and have good, >fresh smelling ecash which you can keep, spend, or later deposit in >your account. > >If the merchant performs this exchange operation on-line as soon as >he receives ecash, then his anonynmity is protected. The customer is >protected too, by the blinding he used when he withdrew the ecash earlier. >So both sides remain anonymous. > >It sounds like Ian may have worked out details of a system where third >parties do these exchanges. Banks may be reluctant to allow them for >liability reasons, and the market, abhoring the vacuum, will supply >intermediaries who perform exchanges for a fee. > >Resolving the various forms of cheating is the hard part. When Lee asks >about a signed receipt, it is hard to understand what is the point if the >seller is fully anonymous! A signed receipt from a freshly-minted key >is not of much use to anyone. > >If the participants are using persistant pseudonyms then whatever >reputation capital they have can be put on the line when cheating happens, >although it still may be hard to tell who cheated whom. Did the customer >pass bad cash and claim it was good, or did the merchant deposit good >cash and claim it was bad? > >The same thing could happen every day at the supermarket, of course. >A customer insists they paid $20 but got change for a $10. If dozens of >customers say the same thing has happened to them, we start to mistrust >the market, while if several businesses say this particular customer >has made the same claim to them, we blame the customer. Here is another idea. The merchant and customer agree on a price, with the merchant knowing that the "bank" will take a cut for their services. The merchant and customer both LOG IN to the bank seperately, each type in their agreed upon price and cut & paste in the services rendered information. If they match, the bank makes the necessary transaction between the accounts, e-cash stash, etc. The bank also supplies both parties with a clear signed receipt. The bank can now no longer alter the receipt, as the merchant and customer both have a copy. And the customer and merchant can not alter the receipt, because then it would fail the test on the signature. If a receipt for a transaction number were used, then the only threat would be the same one that exists for remailer operators. This could be negated by daisy-chaining banks in a similair manner. If each bank took a cut of non-customers of $.0002 or .02% of the transaction, whichever was greater, then a suitable system could be set up. Another idea that has been festering. If we could get a CPA involved in this forum, I would be willing to have h[im/er] sign my key, (which is seldom used, mostly because this is the only place I use e-mail), for that reasonable fee that CPA's can charge. I know that it is not a standard, or even legally recognized, post for CPA's, but I think that enough people would trust them. This would take care of some of the "newly minted" key problems. Since getting someone who is trusted to sign your key is a recognized method of getting people to believe you are who you say you are. Just an idea. Actually two, one half thought out, one that has been bugging me.

1 0

Re: Transmission of Crypto material and ITAR
by Rick Hornbeck 17 Dec '03

17 Dec '03

Unless someone in the U.S. is willing to go to the effort of capturing all of the packets that comprise the crypto software package as they pass through various MCI, Sprint, etc. networks (which is probably illegal in itself, in most cases), on their way from the UK to your site in Australia and then reassembling them in the U.S. into something that is in violation of the export regulations, what difference does the path of the individual packets make? At 01:15 PM 2/13/97 -0800, you wrote: >Dear All, > >I have a question regarding the impossible enforcement of ITAR/EAR: >Naturally I cannot download crypto software from the US, but most of these >sites have mirrors in other countries, such as the UK for PGP, and sweden >and finland for lots of things. > >However, with the way that information is routed throughout the internet >from these sites, whenever I, in Australia, request packets containing this >data from the UK etc, it invariably passes through the US from coast to >coast! Therefore, if ITAR/EAR tries to govern that, aren't they really >trying to enforce something totally unenforcable? Surely they cannot expect >all gateways operated by, say, Sprint and MCI to packet sniff 'n' search? > >Can anyone tell me what the ruling is with regards to this? > >Yours Sincerely, > >Benjamin Grosman > >---------------------------------------------------------------- > Benjamin Grosman - Programmer, Magna Data Internet Solutions > Quidquid latine dictum sit, altum viditur. > [Whatever is said in Latin sounds profound.] >---------------------------------------------------------------- > > > >

1 0

Re: subscribe
by Sean Roach 17 Dec '03

17 Dec '03

At 08:48 PM 2/12/97 -0600, Igor Chudov wrote: >Jim Choate wrote: >> >> >> Hi Igor, >> >> > I will not impact me negatively. I do, however, suggest very strongly >> > that hosts should be subscribed to each other thgrough another mechanism >> > and not majordomo, in order to prevent mail loops, header rewriting and such. >> >> Suggestions? What I had in mind was that any messages that get sent on >> cpunks(a)ssz.com get sent over to algebra. One mechanism I would like to play >> with is a 'linked list' of remailers. Remailer A sends only to B and >> receives only from C... >> >> >> A >> ^ v >> C < B > >> Then to stop loops B deletes all outgoing mail from B. Since email can be >> forwarded from many sites the search must traverse the entire forward chain >> killing the message if B appears as a source. I suspect a simple procmail sort >> can accomplish this. My next step is to brush up on my procmail. I hope to >> have something in a couple of days that will allow you to subscribe >> cpunks@algebra to cpunks@ssz and both ends will be filtering. > >Here's how I do it (it is pretty close to your proposal): > >1) I delete duplicate messages (by looking up the database of >message-IDs) right away >2) I bounce all incoming messages to several other list servers >3) I pipe the article to majordomo for distribution. > >Note that majordomo changes headers and I wuold like to feed >other servers with UNCHANGED articles. ... >> Another nice advantage of this architecture is that 'rings' of remailers can >> be interconnected by simply sending output to more than one site. Might even >> be a good stability rule, "Never have a remailer send to more than 1 machine >> in its 'own' ring". I see no limit other than resources that would limit the >> number of rings an individual remailer might be in. > >A very good point. > ... Something to consider. If anyone of the distributed remailers is removed from a ring, the messages that need to travel across that ring can no longer do that. This makes the loop only as strong as its most at risk remailer. The star approach has already been seen in action, the trouble here is a single choke point. Full interconnectability is only feasible in a small net, but I would advise this at first. Check for the x-loop to see if another one got it first. If none, add one and send it on down the line. A disjointed mess, if the remailers are given first access to the list, could work quite well as long as that x-loop remained to point to who sent the message, and the x-loop contained an unalterable message number, and the remailers could eliminate duplications, probably based on message number. This should work as the net grows and would only be as weak as the strongest two connected remailers. Sounds like the internet.

1 0

Re: Excerpt on SPAM from Edupage, 11 February 1997
by jim bell 17 Dec '03

17 Dec '03

At 03:25 PM 2/12/97 -0800, Timothy C. May wrote: >Having said this, the flaw remains that "junk mail" is "free" to the >sender. This is a flaw in the ontology of e-mail, and needs to be fixed. >Digital postage is one approach. I decided long ago (okay, well, many months ago) that the "solution" is to invent a mechanism to allow spammers/advertisers to include a small amount of ecash as a gift with every spam. I figure that if USnail junk-mailers are willing to pay $0.32 for postage and probably $0.50 for production, printing, and labelling costs, all for no guarantees of results, they should even more happy to pay, say, 10 cents to each recipient. At that rate, an average person would probably receive enough "spam" to pay for his Internet account, quite analogous to the way advertiser-supported TV is presented to the public for no explicit charge. Jim Bell jimbell(a)pacifier.com

2 1

Re: Procmail during the transition, anyone?
by Anil Das 17 Dec '03

17 Dec '03

Michael Froomkin - U.Miami School of Law wrote: > > At various stages in the transition, we will be getting multiple copies of > the same messages as the are re- cross- whatever-posted to lists, > newsgroups and anything else handy. > > Anyone have a procmail script that will show me just ONE copy of messages, > even if the headers are not identical (e.g. one looped, another was > forwarded, etc.)? > # Remove duplicate messages :0 Wh: .msgid.lock | formail -D 8192 .msgid.cache It detects duplicates by Message-Id. -- Anil Das

1 0

Re: X.500
by nobody＠wazoo.com 17 Dec '03

17 Dec '03

Dinghy Villainous K>ocksucker< Of The Month's obsessive masturbation has lead to advanced degree of blindness and hairy palms. ,/ \, ((__,-"""-,__)) `--)~ ~(--` .-'( )`-, Dinghy Villainous K>ocksucker< Of The Month `~~`d\ /b`~~` | | (6___6) `---`

1 0

Cypherpunks-announce? Do we need to recreate this?
by Bill Stewart 17 Dec '03

17 Dec '03

Now that cypherpunks is moving, to both a newsgroup and one or more mailing lists, there's still a need for cypherpunks-announce or something like it. So far it's carried 1-2 announcements per month. Should we create it as a mailing list, moderated or unmoderated, or as a newsgroup? (It's been a moderated mailing list, run by John and Hugh.) Perhaps the right implementation is a mail exploder going to several moderators in parallel, any of whom can forward to the list, just to cut down delays? # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0