December 2003 - cypherpunks-legacy

Re: Using Hotmail as an exit remailer
by last deliverer 17 Dec '03

17 Dec '03

Congratulations to Ian Goldberg on his great script for sending via Hotmail! This is sent using the script, with the following info. The proxy comes from the web page Ian supplied: $login is "ldeliverer"; $passwd is "xxxx"; $proxyhost is 'secure.escape.ca'; $proxyport is 80; (Warning: sometimes hotmail eats equals signs.) The only problem is you need to install several extra modules into Perl. I had to add these packages: Data-Dumper-2.07 IO-1.15 MD5-1.7 MIME-Base64-2.03 libnet-1.0505 libwww-perl-5.10 Now let's modify it to work with rocketmail, usa.net, etc. Be nice to see an account-creation script, too. Good job, Ian. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

GOST ??
by Jim Prickett 17 Dec '03

17 Dec '03

Does anyone know what the legal status of the Russian cypher "GOST" is ? Is it public domain, patented, proprietary or what ? It looks like it would be more efficient than DES when implemented on a microprocessor or microcontroller. Also the DDJ article mentioned that like DES, there are good and bad S-boxes for GOST. Does anyone know how to choose a strong S-box for GOST ? Jim Prickett

1 0

Re: SSL trouble
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

David Conrad wrote, quite well: > > Patrick Horgan <patrick(a)Verity.COM> writes: > >I did a distributed scheme for something else that had two levels, a master > >and a group of slaves. Only the slaves talked to the master. For this > >effort I think a variation of the idea would be better. Have all of the > >brutes contact the master, who will, in the first transaction assign them > >to the next slave in a round-robin fashion. > > Why not just have the brutes pick a slave at random? Of course, you need > to give them a complete list of slaves to choose from. But then the only > difference between the master and the slaves will be that the master > doesn't get any keyspace (it's got it all to begin with) and doesn't > report any results upward. > I think that this is a quite good idea with one caveat. That we use a good random algorithm. As people on this list are quite aware, many algorithms that ship in libraries of commercial OSs are flawed in one way or another. Perhaps a combination of the two: give the whole list rotated in a round-robin fashion, and let the client do with it as they will. There are enough coders on this list that we'll soon see independently developed versions of the client software, (although a published protocol for talking with the slaves would be nice), and some might like to draw the first from the list, another randomly choose one, etc... Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: SSL trouble
by Will French 17 Dec '03

17 Dec '03

>> Please don't do anything like this. This will prevent >> people like me who prefer the "random" method from >> participating. > You can't use the random method if the CRACK is using a > sequential search. It just doesn't fit! Hehe... I've always been a bit of a misfit. > You can't ACK something which has not been allocated to you. But I could announce it on the list. > However, if a CRACK were to be using random, the above would > be useful as a "progress report" as the rate of reports > indicates how well the search is going. I don't want to make progress reports. > It would also allow more equal sharing out of the prize money, > as on average 2**15 "possible" keys would be found, and the > first finder of each would receive a fraction of the prize. Well, if someone starts talking real money, I might change my tune. Will French <wfrench(a)interport.net>

3 2

Re: bulk postage fine (was Re: non-censorous spam control)
by sar 17 Dec '03

17 Dec '03

At 02:28 PM 8/3/97 +0100, you wrote: > >sar <sar(a)cynicism.com> writes: >> At 06:32 AM 8/3/97 +1000, ? the Platypus {aka David Formosa} wrote: >> >> >-----BEGIN PGP SIGNED MESSAGE----- >> > >> >On Sat, 2 Aug 1997, Adam Back wrote: >> > >> >> Next we choose a threshold say 1000 posts per day. Seems hard to >> >> imagine anyone generating manually over 1000 emails per day. That's >> >> more than 1 per minute for a 10 hour day. >> >> Take bugtraq which has over 12,000 subscribers. Each post to bugtraq would >> send out 12,000 emails so it would cost aleph one 1200$ per post to his >> list. I dont think anyone would want to run a mailing list under these >> sorts of conditions. > >The way such pay for email systems as I see them would interface with >your existing email system is that you would have a list of addresses >which you would be happy to receive email from for free. > How about spam via trusted addresses, 1 out of 10 posts to this list seem to be ads for something or other. Also what if I decide to subscribe to a high volume list with a few email accounts and talk my friends into doing the same. We also decide no to recieve mail from them for free. If we got over 1000 mails in one day would they have to pay up 100$? and if so who would they pay it to. People running mailing lists whould have to get subscribers to verify that they added the list to their trusted address list.

1 0

Re: SSL trouble
by Bill Stewart 17 Dec '03

17 Dec '03

Several people have suggested random keyspace selection instead of servers. The problem is that there's a high probability that the search will fail to find the correct key. If you split the keyspace into n segments, and randomly select k of them, the probability of failure p = ((n-1)/n)**k ; for k=n, p approaches 1/e (.367) as n becomes large, and 10 is close enough to large that you don't gain much by having independent groups that agree not to overlap in their own 10% of the keyspace. For k=2n (random-searching the space about twice), the probability of failure is still e**-2, about 13%. You need a coordinated search. >Why not just have the brutes pick a slave at random? >Of course, you need to give them a complete list of slaves to choose from. That more or less works, assuming you can distribute the list of slaves along with the code; you still hit the slaves' DNS servers unless you also distribute IP addresses for the slaves to use (which is probably fine as long as people get the addresses beforehand.) You could get fancy and have a DNS server hand out slave addresses round-robin for a dummy address slave.cracker.org. The main failure mode seems to have been misconfigured clients grabbing the single-threaded server for a long time; it may be worth using a multi-threaded server, or alternatively a single-threaded server that has a fast timeout for how long it will talk to a client. I gather there was some protection in the code against dishonest clients, but a malicious attack would be to falsely ACK large portions of the search space (especially the portion containing the real answer, if the attacker knows it). #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: improving the distributed computation
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:43 AM 8/25/95 -0400, you wrote: >1) Abandon the central command way of doing things. Little if any >communication is required for this computation, it should be >self-distributing to and between volenteer sites. That makes it ideal >for implementation as a safe virus. Doling out keyspace _does_ require central coordination, though the job can be delegated to _trusted_ volunteers, or delegated with redundancy to semi-trusted ones. As far as safe viruses go, I've had more free lunches than safe viruses, though I've been offered both out of "charity". Some of the lunches were good, and charitable; the viruses have been, at best, mostly harmless. Perhaps under Safe-Tele-Java-Script it will be possible to send self-modifying self-reproducing scripts around a network to unsuspecting machines, but I doubt it. >2) Give these computations a defined and limited lifetime. The problem >you have with old versions is because they don't die automatically or >even check to see if they are up-to-date and update themselves. Yeah. In this case, the lifetime of the versions was less than the expected lifetime of some of the searches. Automated version-checking would help, but the version changes made it difficult to communicate even simple requests like "Give me a number". Perhaps it would make sense for version upgrading to include changing the server's TCP port so the old versions don't hose the servers for the new versions. >3) Use randomness to break up the search space and redundantly perform >the computation. This should eliminate the problems with malicious >key-space requests, etc. Randomness doesn't help much, since it's hard to be sure you sweep the whole keyspace. Redundancy does help, but it's still tough to protect against sufficiently malicious attackers. >4) Use feedback in the form of selective survival/replication to >optimize the search and allocate search space. If a processor goes >quickly, give it more to do - if it goes slowly, give it less. This >will produce an overall system that adapts with time to the cahges in >network and system usage so as to optimize overall performance as a >function of time. You could do that. But simply asking for more numbers after you've finished the previous batch accomplishes much the same thing; special tuning may be more useful for folks with MasPars than 486s, where redundantly giving out unacked search space can do more. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

North American Crypto Archive status
by Michael Paul Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- WHAT HAPPENED TO THE NORTH AMERICAN CRYPTO ARCHIVE? The North American Crypto Archive at http://www.sni.net/~mpj/crypto.htm is rather limited right now. I have deleted everything except the few files that I contributed to the site. This was to save money, since I suddenly lost some sponsors (who wish to remain anonymous, but I appreciate them greatly) who were paying for the costs associated with the site. I am still planning to resurrect the North American Crypto Archive, but this will likely take a while. I think that almost all of the files were successfully rescued before the site went down by at least one person. Note that much of what was there can be found by following the links at http://www.sni.net/~mpj/freecrypt.htm or by using appropriate search utilities. WHY RESURRECT THE NORTH AMERICAN CRYPTO ARCHIVE? 1. To provide a place for U. S. and Canadian citizens to freely and openly exchange cryptographic information, papers, programs, etc., without fear of government reprisals. 2. To provide a friendly central repository for cryptographic libraries, code, and papers, thus making it easy to find and use such information. 3. To provide a reasonably high bandwith connection for North Americans. 4. To exercise "freedom of the press" and press towards a constitutional EAR. HOW MUCH SPACE WILL THIS TAKE? My total archive space was at about 125 megabytes, but it had been trimmed from what I would like to have. For example, downlevel versions of software were generally deleted, and some things that are historically and cryptographically interesting were not carried. I forsee usage of around 500 megabytes or more in the near future if we can make room for it. The storage need not all be at the same site, however. HOW MUCH BANDWIDTH WOULD IT TAKE? I'd like to see at least ISDN connectivity. I've seen as many as 425 files downloaded in a day from the current archive. Again, the storage and loading need not all be at the same site. WHAT DO YOU MEAN BY NOT HAVING ALL THE STORAGE AT ONE SITE? I envision a new plan for running the archive such that one master index page (like the "export controlled" one at http://www.sni.net/~mpj/na) points to hidden directories all over the continent, wherever free space can be gleaned. The only requirements on the remote sites to maintain the "export controlled" status would be to maintain a cron job that changed the name of the hidden ftp directory containing the files on the same schedule and using the same key as used at the index site. For now, http://www.sni.net/~mpj/na can remain as the password-controlled index site. This does require a slight change to the architecture of the "export control" system in that the directory name would be a function of the current time (UTC) and a secret key, instead of being truly random like it is, now. The relative loss of security in this change is inisgnificant relative to the (obvious) weak links of the system. (Yes, I know that it can be defeated, but I also believe that the system complies with the EAR as well as most do, anyway.) The gain in this approach, of course, is that the index and ftp site need not reside on the same server, as long as the system clocks are reasonably well synchronized (within a few minutes). One other advantage of having several sites is that popular files can be placed on several different servers to lower the average traffic from any one server and to make the system more robust against failures and overloads. The archive would still have a single point of failure (at least initially) in the index site, but that could also be replicated fairly easily as long as users don't mind obtaining a separate password from each index site. WHAT REMOTE SITES DO YOU PLAN TO USE? I've had several people make inquiries or make offers, some of which sound better than others. I hope that this one open letter answers all of the questions that I got. I am looking for sites that: 1. Are *nix-based (at least for now). 2. Have some free disk space and bandwidth that can be used for this cause. 3. Have GNU C++ installed (or at least are identical to a host that I have access to that does). 4. Grant me access to a shell account and an ftp account to maintain the site. 5. Grant me access to cron so that I can have the hidden-directory renaming program run at the right schedule. 6. Are likely to be available for a reasonably long term. 7. Are in the USA or Canada and controlled by a U. S. or Canadian citizen. WHAT MAKES PEOPLE THINK THAT YOU WILL GET ALL OF THESE FREE RESOURCES? The same thing that makes me think that people will donate otherwise idle CPU resources for the fun of cracking a DES key or factoring very large numbers. HOW DOES THE "EXPORT CONTROL" SOFTWARE WORK? Ahh... here is the meat of the message that keeps it on topic for coderpunks and sci.crypt: First of all, it is important to understand the design restraints. The EAR states that mere posting of cryptographic software on the internet is not an export if guests must affirm a couple of things (see the regulations) and if there is some kind of check that the "address of the receiving computer is verified to be in the USA." Strict compliance with the latter is impossible, but if the guest's email address is in a domain not commonly used in the USA and Canada (.gov, .com, .org, .edu, .mil, .net, .us, or .ca), then I suspect the guest of lying and deny access. Naturally, this is imperfect, but it is honestly the best I could figure out how to do on a normal ISP shell account that gives me no CGI script access. This really boils down to the honor system. That is OK with me if it is OK with the U. S. Government, and the way I interpret the law, it is. Given that, here is the process: 1. http://www.sni.net/~mpj/usa is an html form that asks 3 "magic" questions to verify eligibility to legally access the strong cryptographic software, as well as the guest's email address. The 3 questions all default such that the user must change each answer to be granted access. The email address must be correct, because the user name and password are sent back via email, not as a web page. The "submit" button sends this data to cgiemail, an application that Colorado SuperNet does allow me to use. This form also invites nonqualified guests to explore most of the same data via http://www.sni.net/~mpj/freecryp.htm (links to crypto sites outside of North America). 2. When cgiemail gets the data from the above form, it simply formats the data using a template I supplied and mails it to me at mpj(a)csn.net. 3. I have an incoming mail filter that checks for any automated messages from cgiemail (which all have a rather long fixed hexadecimal number for a subject line), and processes them. If the guest answered all 3 questions properly, and the email address given doesn't "look foreign," then a form letter is filled in with a valid user name and password and mailed to the given email address. (There are some other checks, like limiting the email address to one destination, etc.) Noncompliant requests are simply discarded (since the "thank you" message from the submission form really already answered them). I thought about a courteous denial letter, but most of the bogus submissions also have bogus email addresses, so I decided not to do that. 4. If our guest can spell his or her email address right (among other things), then the email message directs him or her to http://www.sni.net/~mpj/na with a valid user name and password. 5. http://www.sni.net/~mpj/na is password protected using the security features of the Apache web server (as slightly tweaked by Colorado SuperNet). This is the index of the files in the archive, which are in a subdirectory of a hidden directory with a non-obvious name. 6. The hidden directory names are changed periodically to discourage the use or posting of a copy of the page at http://www.sni.net/~mpj/na without password protection. The idea is that by the time the cheater posted it and anyone found it, the hidden directory names would have changed again, invalidating the renegade index. The index is altered on the same schedule to the same new names by a companion program. (Right now the same program does both tasks, using a truly random number based on the arrival times and CRCs of all of my mail, but this would have to change in the new distributed archive model). IS THAT REALLY GOOD ENOUGH? I think so. It is the best export control model that I have seen that doesn't lock out U. S. and Canadian citizens in the U. S. A. and Canada. I saw a little more elaborate system on a Microsoft web site for distributing some 128-bit RC2 software, but it locked me out because it didn't like the way Colorado SuperNet registered their "whois" information. It also locked me out from work, since SSL connections can't get past our firewall. My model is much less likely to lock out a duly qualified guest, and it is much better than my old "warning message only" model that I used before crypto export regulations passed from the ITAR to the EAR. WHAT ABOUT CRYPTO SITES OUTSIDE OF NORTH AMERICA? Please keep them up, and be ready to mirror any information that might suddenly become legal to export from the USA on short notice. I say this because the EAR is being challenged in court, and it is likely that cryptographic software export regulations may be struck down. It is also likely that the U. S. Government may quickly move to replace those regulations with others in a very short amount of time after the EAR is struck down. I don't want to encourage anyone to violate currently active regulations, however. If you have a good cryptographic software site outside of North America, and it isn't on my list at http://www.sni.net/~mpj/freecrypt.htm, please let me know. WHAT IS YOUR PGP KEY? RSA key for PGP 2.6.x: ftp://ftp.csn.net/mpj/mpjkey.asc (mpjA) DH/DSS key for PGP 5.0: ftp://ftp.csn.net/mpj/mpjdhkey.asc (mpj(a)ebible.org) (Note that my RSA key uses mpj(a)csn.net for an address. That old address still works.) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBM+6USm+Iqt/O4EnZAQFVFgf+IQq7oZavZxgMwT2530w7LWPkNLqlbG5z BSi1QGasmZrumAuMOG7M28prFZVg2hzExKUejlSXao7ywa3fnzLb0BF8WlDlFsS/ ysSQTB1NLzgjm3L8pqImdNGrP6ECFSFsTm3KOGxuu/NAVfEyBaoV5VEwxlUJmWBu ifsmv7aBOOfY4g2xa9XQay4+rIx4QTr6k6OJenJ0f+eLnC/JjG7Dz3n3Mh0vbu6p Vc9ib9jjkv+eawKv5+BnFUNc/hILsnw1yPQuomc7/G/YMJwbd7Ps/+LVRqmg0oxD ECLfAI/BI6KxUh8EDGH91SnSXNHAYwtA1puIrQka1zkPPTr/psA/fw== =9Zof -----END PGP SIGNATURE----- Michael Paul Johnson mailto:mpj@ebible.org (aka mpj(a)csn.net) PO Box 1151 http://www.ebible.org/bible <- Holy Bible Longmont CO 80502-1151 http://www.sni.net/~mpj/crypto.htm <- Crypto archive USA PGP RSA key fingerprint (mpjA): 3E67 A580 0DFB D16A 6D52 D3A9 1C07 4E41 PGP DSS/DH fingerprint: 28AE B775 DD65 62C7 0717 ECDA 448F E0C7 17D7 47BB

1 0

No Subject
by Black Unicorn 17 Dec '03

17 Dec '03

It's been far too long since I cleaned up the namespace clutter on alpha.c2.org. So I have deleted all reply blocks which point to remailer(a)jpunix.com, remailer(a)tower.techwood.org, usura(a)replay.com, myriad, wmono, desert, nately, and all the other dead remailers I could think of. I did this with a grep/awk script, so I hope it didn't maul any valid addresses. There are probably still a lot more dead addresses, but hopefully this cleans up the namespace somewhat. [...] THE FOLLOWING HAVE BEEN DELETED: abdul alexr alice an34267 anna avatar beaver blacknet ^^^^^^^^ bolt_thrower Uh oh! :) --- 00B9289C28DC0E55 nemo repente fuit turpissimus - potestas scientiae in usu est E16D5378B81E1C96 quaere verum ad infinitum, loquitur sub rosa - wichtig! *New Key Information* - Finger for key revocation and latest key update.

1 0

Re: SSL trouble
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > >PS3: I'd like to get the raw date in brloop (a sh script). In perl I'd just > > use "time", and I can't see a way to get "date +" to yield the raw time. > > I could use "date=`perl -e 'print time'`" but that seems OTT, and perl > > may not be on teh users PATH. Any suggestions ? > > "date '+%s'" does it under BSDI, but I'm not sure how portable it is. > This is what I got from SunOS 4.1.x $ date +%s date: bad format character - s Sounds like something my parents might have said ;-) Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0