- cypherpunks-legacy - lists.cpunks.org

Re: remailer spam throttle
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:40 PM 3/30/97 -0800, Lucky Green <shamrock(a)netcom.com> wrote: >Reply blocks are unreliable anyway. Yeah, but they're a moderately useful kluge in that they let you separate the information about how to find an anonymous recipient into at least two places, which is far more secure than just one. They're relatively annoying to use, but the nymserver approach makes it possible to use them without the average user messing with the details. >The current piggy backing of recipient anonymity >on systems designed to provide sender anonymity can not work reliably and >must therefore be replaced by a separate design. Is this a distributed-commercial-remailer-boxes approach, or something different? It's a hard problem to do right. In a large-scale system, one good design is to have a Pipenet or equivalent that's used to pick up POP-mail. It needs enough traffic/users/bandwidth to achieve Obscurity, but if you could convince people to carry their Usenet feeds as cover traffic, that'd be more than enough :-) Store-and-forward variants are less reliable, but may do a good enough job, or I suppose you could cook up some sort of distributed message pools. # 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

[ANNOUNCE] hash cash postage implementation
by Adam Back 17 Dec '03

17 Dec '03

A partial hash collision based postage scheme I've been talking about a partial hash collision based postage scheme on the crypto lists for the last few days. The idea of using partial hashes is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly. A first cut implementation of these ideas can be fetched from here: * hashcash.tgz * PGP signature of hashcash.tgz I will describe what the implementation allows by example, using the program so you can follow along if you wish. There is an integrated partial hash collision generator (hashcash mint) and remailer plug-in. The remailer plug-in should be easy to hook into typeI remailers. typeII or nymserver would require modifying the mixmaster client/remailer, the code has been designed to make this relatively easy to do, and link directly into mixmaster, or alpha or newnym. Compiling % gcc -O6 -c *.c % gcc -o hashcash hashcash.o sha1.o % gcc -o sha1 sha1file.o sha1.o % gcc -o sha1test sha1test.o sha1.o % The functions provided by the program are Run with no arguments and it prints a list of flags and terse usage instructions. Speed test: % hashcash -t speed: 7218 hashes per sec % This tells you the number of hashes it can search per second. (Note, the implementation of sha1 it is using is not optimised, it is my reference implementation. I have another speed freak sha1 implementation which needs 1/2 hrs work, and has the same interface, so I'll plug it in later. It's commented in sha1.c). Estimate time required to find 17-bit partial hash collision: % hashcash -t -17 speed: 7274 hashes per sec find: 17 bit partial sha1 collision estimate: 9 seconds % (varies quite widely from estimated time) Calculate a 17 bit collision on string "flame" (flame is a now dead remailer): % hashcash -17 flame speed: 7274 hashes per sec find: 17 bit partial sha1 collision collision: 09948flame356018443 tries: 57450 % The collision is actually found on the hash of the date since Jan 1 1970 in days (5 digit leading zero filled) and string given. So the collision is found on: % echo -n 09948flame | sha1 fbbea210abafe3e72afe7849eaea2052e309e017 % The collision that was found can be seen manually as the collision is constrained to be the MSbits of the digest: % echo -n 09948flame356018443 | sha1 fbbead76da651cf856f7466fed9624d3ada061d9 % You can manually see that the first 20 bits match. (Note we asked for a 17 bit hash, but it generates a 17 bit or larger hash. We just got lucky and got an extra 3 bits, which would happen about 1 time in 8). The hashcash client can also report on a collision: % hashcash flame 09948flame356018443 collision: 20 bits % You can check on the validity period as compared to todays date: % hashcash flame 09948flame356018443 28 validity: 28 days remaining collision: 20 bits % You can check that a hash has a requested number of bits: % hashcash -25 flame 09948flame356018443 collision: 20 bits required: 25 bits rejected: too few bits % The exit status is set to failure if any of the tests fail: ie if there are too few bits, or if you do a validity check and the hash has expired, or isn't yet in it's validity period. Double spending protection You can also ask the hashcash client to remember collisions within a selected validity period. % hashcash -d -25 flame 09948flame356018443 28 validity: 28 days remaining collision: 20 bits required: 20 bits database: not double spent adding: 28 09948flame356018443 % The collision will only be added if all the tests pass (in validity period, required number of bits). The exit status also tells you if the hash was ok. The database would grow indefinately as the mailer accepted new payments, so the validity period is stored in the database, and at the next use of the database after the validity period expires, the collision will be discarded. There is no need to keep expired collisions around because we wouldn't accetp it anyway because it's out of date, so who cares if we've previously accepted it. A validity period of 0 means valid forever, and it will never be discarded from the database. An example of double spending A new test now is whether a hash has been presented before, so we the above command and expect it to be rejected as already spent, because it is in the database: % hashcash -d -25 flame 09948flame356018443 28 validity: 28 days remaining collision: 20 bits required: 25 bits rejected: too few bits database: double spent % (exit status is set to failure, due to double spent cash) That's it It's very lightly tested, so if anything breaks let me know. It's got some inefficiencies in places, but working code comes first, efficiency later. (Also I have not tested my SHA1 implementation on a big endian machine, it auto-detects byte endian-ness, theoretically). Remailer applications discussed so far * exit remailer postage per post * spam filter on mail you receive, if it hasn't got a 20 bit hash, or 1c digicash you have a program which bounces it with a notice explaining the required postage, and where to obtain software from. This would put spammers out of business overnight, as 1,000,000 x 20 = 100 MIP years which is going to be more compute than they've got, and 1,000,000 x 1c = $10,000 is going to be more than they are likely to make through sales interest from the spam. * good behaviour bond for nymserver users. The nymserver user pays the nymserver (in a largish hash collision, or $25 digicash) for a replyable nymserver account. They agree an contract with the penalty clause that breaking the contract means the nymserver keeps the digicash/collision, and disables the account. They user's identity isn't known, but to join in again they have to pay up another large hash collision or more digicash. * there are lots of other ideas to play with. How does this fit in with digicash Digicash postage on remailers, and mail would be useful, however there are a number of problems with digicash: * It is more onerous to set up an account (form filling etc) * Not many people have accounts * It's only anonymous for the payer anonymous (and not anonymous for the seller) So my suggestion is that we have remailers which accept either hash collision postage, or digicash postage. The advantages of this approach are: * Hashcash may provide a stop gap measure until digicash becomes more widely used * Hashcash is free, all you've got to do is burn some cycles on your PC. It is in keeping with net culture of free discourse, where the financially challenged can duke it out with millionaires, retired government officials, etc on equal terms. * Hashcash may provide us with a fall back method for controling spam if digicash goes sour (gets outlawed or required to escrow user identities). Any comments, code, etc gratefully received. A couple of remailers alpha testing it would be nice also. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

2 2

Accounts payable
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Tim C[reep] May has been a source of endless embarassments to his sympathizers on and off the net. o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ Tim C[reep] May / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \

2 1

RE: Hard to Tax Scenario
by Lucky Green 17 Dec '03

17 Dec '03

At 10:24 PM 3/29/97 -0500, Robert Hettinga wrote: >(By the way, I'm going to embarass Doug Barnes now by naming a law after >him. He said a thing of beauty at FC97: "Any transaction protocol which >has, as one of it's steps, '...and then you call the cops', isn't a real >good idea on the internet." Shall we call it Barnes' Law, anyone? Sure, >lots have said it before, but no one's said it better...) Actually, I think it was "...and then you punish them". I second the motion. :-) -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred "I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi

2 1

Re: Microsoft ammunition (fwd)
by Hallam-Baker 17 Dec '03

17 Dec '03

Jim Choate wrote: > > Forwarded message: > > > Date: Thu, 27 Mar 1997 16:11:50 -0600 > > From: Toto <toto(a)sk.sympatico.ca> > > Subject: Microsoft ammunition > > > But, if you're tired of the repetition, here's a > > reason you should sit through another sermon: > > RandomNoise's Coda. Coda lets you design entire > > Web pages in Java rather than use a mixture of > > HTML content, tags, and Java applets. > > > > A Java-based Web page removes the distinction > > between application and data. It presents data > > just as an HTML page would, but every element on > > the screen has the potential to be an interactive > > part of a sophisticated application. > > Mix this with the distributed processing model of Plan 9 and you may just > have tomorrows computer environment. I very much hope not. We designed HTML with very specific goals in mind, above all that the source be declarative and machine readable. That is why HTML can be edited by the recipient, fed into a voice synth or index by Alta-Vista. The Java based web pages will be opaque, just like postscript. Try to cut and paste from ghostview to emacs. Merging the distinction between applet and code will give lots of techno-geeks a nice orgasm but its the style of computing the Web has replaced. I have yet to see a single Java applet that has the slightest functional utility. I like Java as a language, particularly because it has killed C++ stone dead just as everyone thought it had taken over the world. I don't see that anyone has done anything with mobile code that is of interest however. If all you want is a better user interface add some more tags into HTML, implement Dave Raggets '94 draft perhaps. I think the idea of using Java to move an applet from the client to a server is very exciting but thats not in the Sun/Oracle game plan. The hypertext community had been beating the coda type model for decades before the Web. I was skeptical then and I'm more skeptical now. I turned Javascript, Active-X and Java off about 9 months back because I had little confidence in their security. I soon realised I was much happier when the page did not dance about in front of my eyes. I very rarely come to a site I can't access without them. If I could turn off animated Gifs as well I would be even happier. I think the future of computing is much more likely to lie in returning to simple but powerfull ideas. Presentation types, parallel languages and genuine process oriented object systems interest me much more. Phill

2 1

ZDNet Special Report: Web Tragedy
by announce＠lists.zdnet.com 17 Dec '03

17 Dec '03

------------------------------------------------------------------ ZDNET ANNOUNCEMENT 3/28/97 ------------------------------------------------------------------ Join us today for our latest ZDNN news special report,"Web Tragedy". Once again, we see how the Web affects us and our culture, in ways never foreseen. Shades of Jonestown. A mass suicide. Bizarre enough. But even more so. Reason: Even this could be tied to the Internet. ___"Heavens Gate" Web Site Now Accessible Via Yahoo! Internet Life___ As the Heaven's Gate Web site continues to experience overload, Yahoo! Internet Life has mirrored a major portion of the site for Internet surfers looking for more information on the cult. Heaven's Gate Web site: http://www.zdnet.com/yil/higher/higher.html ___ ZDNet News Special Report___ Visit ZDNet News for a comprehensive news package on the suicide of the 39 Web designers, including: video reports, insight from inside the Net subculture itself, perspective from cult experts, a discussion forum and the latest news as it happens. ZDNet News Special Report: http://www.zdnet.com/zdnn/heavensgate ___ Yahoo! Internet Life Offers Report from Cult Experts___ Yahoo! Internet Life also offers an exclusive column by noted cult experts Robert Siegelman and Flo Conway, who try to make sense of the tragedy. Cults on the Web: http://www5.zdnet.com/yil/higher/cultcol1.html We'll be updating these sites continually as this story unfolds. ________________________________________________________ ZDNet Announcements are periodic notices of new features, special events and free offers available to members of ZDNet. --To subscribe to ZDNet Announcements, please send mail to: announce-on(a)lists.zdnet.com You can leave the subject and body blank. --To unsubscribe to ZDNet Announcements, please send mail to: announce-off(a)lists.zdnet.com You must leave the subject and body blank. _________________________________________________________ Powered by Mercury Mail: http://www.merc.com

1 0

WebWorld 20
by Bubba Rom Dos 17 Dec '03

17 Dec '03

1 0

Hello
by winsock＠rigel.cyberpass.net 17 Dec '03

17 Dec '03

Hi, anyone know if the Cyphernomicon is still available? --Chipjunkie --Tim May Just say "No" to "Big Brother Inside" We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Dilbert on Smartcards
by Bill Stewart 17 Dec '03

17 Dec '03

The March 21 Dilbert is on http://www.unitedmedia.com/comics/dilbert/ Friday; to see it later, look in http://www.unitedmedia.com/comics/dilbert/archive/ # 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

SSL weakness affecting links from pages with GET forms
by Bill Stewart 17 Dec '03

17 Dec '03

http://www.zdnet.com:80/intweek/daily/970327x.html has an article about an SSL problem that affects both Netscape and MicrosoftIE browsers, leaking "secure" data such as credit card numbers from web pages with GET-based SSL forms on it. It was discovered by Dan Klein. There isn't specific detail about how the flaw works, but it says that it affects GET forms but not POST. Commentary from NS, MS, Gene Spafford, and Steve Bellovin. "It's like you've gone to the restaurant with your lover," Klein said. "The restaurant is there, it's private, yet when you leave the restaurant you have the menu in your hand and there's food all over your shirt." # 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.)

2 1