December 2003 - cypherpunks-legacy

Re: uncensorable net based payment system?
by Steve Schear 17 Dec '03

17 Dec '03

At 10:14 AM -0400 7/31/97, Vincent Cate wrote: >Adam Back <aba(a)dcs.ex.ac.uk> said: >But you are right that it is an asset continually dropping in value, so >it is an odd thing to back a currency with. Would only want to keep >enough money in it to do what you currently wanted to do, not as a long >term investment. > >I could imaging just gradually increasing it so that $0.25 for 1 megabyte >today became $0.25 for 1.1 megabytes in 3 months, or something like that. Not very different from how one might handle a gold-denominated and backed ecash coin. Real gold must be stored in a repository which charges a storage and handling fee. This can integrated with the coin value by applying a negative interest rate to the coin based on the epoch in which the coin is issued. So coins are redeemed at a lower than initial value (assuming no change in the gold value figured in whatever unit it is being exchanged). --Steve

2 1

Re: SSL trouble
by Damien.Doligez＠inria.fr 17 Dec '03

17 Dec '03

>From: Christian Wettergren <cwe(a)Csli.Stanford.EDU> >What I wonder is wheter the server congestion really showed that >the protocol is flawed. I never meant to say that the protocol was flawed in any way. I'm sorry if I gave this impression. (I used pretty much the same protocol on Hal1) Since I'm not the one who's writing the code, I will not try to tell you how it should be written, of course. My point was only that the central server approach does not scale. When we reach its limit (and it seems we have not reached it yet), we can use a hierarchical approach, and it is faster than the random one. But the random algorithm does have its strong points and we should not dismiss it out of hand. Maybe I got a little carried away in my advocating of the random algorithm. (another topic:) As for the updates to the client software, let me point out that I did 10 different versions of my own client when working on Hal1. Some machines worked for one week with version 1, while others needed many updates, due to different network and OS conditions. This is the main advantage of a well-defined (and stateless) protocol: it allows the server and clients to be all updated independently while the computation is running. -- Damien

1 0

Re: SSL trouble
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- 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. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEIKkhEcrOJethBVAQHjVQP/RGGxRkUp2WB1/yWngAIrGG3m7Xo6CG17 2sODkkDDGJYmGV+wDBLWObc7VS30MHrPfMLT7Cp7yI/AgYgDJrZ/1SRKw2OuVFqI kgL8hICRxqe76IvmlFAa/pFXVgYiu+WHsMlSEKYlpLa7T424HUdAD21Rc2Dvqioi zMqmhgdn22I= =QAi2 -----END PGP SIGNATURE----- -- David R. Conrad, ab411(a)detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.

2 1

BEAT THIS !!!!!
by theserve＠msn.com 17 Dec '03

17 Dec '03

////////////////////////////////////////// 45,000,000 + E-MAIL NAMES \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 45,000,000+ Yes that's right, FORTY FIVE MILLION PLUS E-Mail addresses on CD's. Your Cost $119.00 plus $5.00 for shipping and handling. Unlike some other name sellers who give you part of what they promise and tell you they will send the rest later and then disappear, we send you ALL 45,000,000 + names immediately. Want them overnight add $15.00 These are brand new names, with no duplicates, in text format for easy use with your Bulk E-mail software programs. Order now - will not last long at this price only taking limited orders as we do not want to saturate the market with these names. Send Check or Money Order Only - (No Cash) to: HPC 2887 North Green Valley Parkway Suite # 298 Henderson , Nevada 89014 (702) 454-2563 Name ___________________________________________________ Address_________________________________________________ City _____________________ State _______ Zip ___________ Email Address __________________________________________ _____ Send me the 45,000,000 E-mail addresses for $119.00 plus $5.00 shipping and handling (total $124.00) _____ Send me the 45,000,000 E-mail addresses for $119.00 plus $5.00 for shipping and handling and $15.00 for overnight service (total $139.00) Make all checks and Money Orders payable to : "HPC" (Checks held 5 business days) (please print this order form) Hpc/897

1 0

Re: Pre-allocating key segments
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> writes: >I wrote: >> Not only that, but the client ought to allocate some keyspace before it >> needs it, as I think one other cpunk suggested. > >I'd prefer to keep the number of segments "lost" if a brloop ceases. Keep down, I guess you meant. Regarding the local farm software: >... if any keys were allocated to machines which failed to ask for another >segment -- you should assume that that segment was not searched. I agree that is the best policy -- it fails safe -- but I still think the prefetching of some more segments would be useful. The goal is to suck up as many idle cycles as is practical. >> For instance, if it has >> four segments allocated and it's done three of them, it should fork a >> process to begin requesting four more segments *while* it is scanning >> the last segment, rather than waiting until after it is done and leaving >> the machine idle until it can alloc more keys. > >That means that if it crashes, 8 segments are left unACKed :-( And if it had grabbed 8 segments to begin with and crashed, it still would have been 8 segments left unACKed. Plus, it's only 8 segments unACKed if it crashes before it finished that last segment, since it will start trying to ACK the first four segments when it finishes the fourth -- at the same time starting on the next four segments. Would you see it any differently if I had said, "For instance, if it has two segments allocated and it is halfway through the second segment, it should request two more segments *while* it is scanning the last segment"? Keeping in mind that it will still ACK the first bunch of segments when it finishes them. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEIOnBEcrOJethBVAQHUfQP+OUA+iC7sTp2CVCZ5YqtM7ouNykhyx7Nm agcTHN6FFZUOxDmAogiY/Op/SLBZbgtmACC3RSG0cEHwzCQJZ6jeUrTe9g3qU/Vm jHRn8PurOUYE188QnZSGEj0qcZbeoYJoLE4qOcrd7SbizIcZoWk/WVA4STZwEHuH wHHusza6Un4= =UOqi -----END PGP SIGNATURE----- -- David R. Conrad, ab411(a)detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.

2 1

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

17 Dec '03

> From: Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> > > One of the things that the latest brloop does is make a call to the master > server asking for a list of servers to contact :-)) > > Note that it is a list, and it tries them in order (all A RRs). Wouldn't this result in the slaves higher in the list being hammered? Perhaps you want to do something simular to what the later releases of bind do with machines with multiple names, and round robin the list. If you had a list with hosts A, B, and C, the first request would get ABC, the next BCA, the next CAB, and the next back to ABC. That would distrubute the work between the slaves a bit better. > > > Then all of the transactions from that point would take place between the > > brute and the slave:) > > Currently just all the "allocate" transactions -- I haven't written my > ACK reflector yet, so all ACKs go direct th the ACK master. > > > The slaves would each be delegated large chunks of the keyspace, > > No -- the slaves will not "be delegated" (as in pre-assigned address space), > they will just ask the master for it as they need it. > Sure, the'll do it in reasonable sized chunks, but not (2**16)/16 .... Actually this is what I meant, that they would ask for it. My idea would be that when a slave is asked for keyspace, if they don't have enough they'd ask for the next large chunk. That way the central server doesn't ever have to deal with small requests. > > > but not keyspace/numslaves. Maybe 1/16th or something like that, and could > > ask for more when their space was depleted. Periodically, perhaps when > > requesting more key space, and/or when a timer pops, the slaves could report > > results. > > Nah - results still go direct pro tem. You might consider it:) > > > What I mean is that every so often they'd report even if they didn't need > > more keyspace yet, iff they had any new stats to report. > > Sure. > > > The nice thing here is that the work of the master and of the slaves is > > almost the same.i > > You got it ! > > > The slaves don't have to do the initial assignment of slave, > (slave -> slaves I assume) > > > and the master doesn't have to report results, but everything else > > is the same. > > Yup -- code sharing ! > > > With careful design you could use the same daemon for both > > with a command line argument to tell it if it was the master (-m) or the > > slave (-s). > > Well, not even that ! > > The slaves don't have the config file with the key info in it ... > > > Of course I'm sure you see that this allows you to add as > > many levels as you want to the hierarchy. > > Indeed. > > BUT .... > > These cache servers are asking for non trivial amounts of keyspace. > As such there should not be *too* many, and then need to be "managed" ... > If one crashes, the logs need to be scanned to see how to restart it (so that > it starts by doling out the segments that it had no sub-doled to its clients). Quite right. I'd assume that the first level list of slaves would be controlled by you. If you're careful enough a slave should be able to go down and come back up without losing any state at all. All brutes/slaves talking to it should be able to continue on with no loss of information. I would put an exponential backoff on the time between retries for the brutes talking to the slaves as well as the slaves talking to the master. (With a limit for the amount of backoff of course.) If you can't talk to someone you might sleep for 8 seconds and retry, if you still couldn't back off to 16, the 32, then 64, then 128, etc...the maximum might be somewhere around ten or fifteen minutes, so that within ten or fifteen minutes of crashing and being restarted everything would be humming along with no manual intervention required on any of the lower levels. > > > A slave doesn't care whether a slave or a brute talks to it. > > Indeed -- that's how it was designed ... > > However, note that with big cache servers (as opposed to Local CPU Farm servers > where all clients are the same "ID") reports of sub-allocation have to be > passed back to the root :-( That's a good point. If you want to keep track of who has what, it all has to get back to the root eventually. If you use my idea of having the slaves cache the information until the next time they'd be contacting the root anyway, (or whenever the timer elapses,) then you greatly cut down on the number of small packets seen by the root, (and each level of slaves when their's a hierarchy). > > > You could make the slave software available as well, and a site with many > > machines could have only the slave contact the master to get assigned a > > slave to talk to, and could configure all of their brutes to talk to > > their own slave. > > Indeed -- the Local CPU Farm cache server is just about ready for ALPHA testers > > > Software like this is easy to write, (and fun), and we should go for it:) > > Done ... > > > Of course I do everything like this in C++, but I suppose perl would be the > > most portable. It's a shame it's so aethestically displeasing to the eye. > > Yeah -- but being based on C, C++ didn't stand much chance ... > > > perl's never a pleasant read. > > ... but better than C++ -- sure. <snicker;> Sound like we could have a religious war if we wanted, but this isn't the right list for it:) (sigh;) Maybe we should move this portion of the discussion to alt.my.favorite.language.rules.and.yours.of.course.sucks. I'm not really a snob about it...I still think cobol's great for some purposes, I just prefer coding in C++. 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 | \___________________________________________________________\)__________/

2 1

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