- cypherpunks-legacy - lists.cpunks.org

State Governments Cash In On Illegal Taxes
by Apache 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Following the the ruling of the High Court of Australia finding that billions of dollars in taxation revenue collected by the states was illegal and unconstitutional the Premiers of Victoria and NSW have made statements that their respective governments will not be refunding the unlawfully collected taxes paid in advance by certain hoteliers. To do so would be an unjust windfall the Premiers said. The governments continue to act unlawfully collecting 'taxes' with no lawful or constitutional basis. The government of Queensland today in a press statement advised it would be returning any unlawfully imposed taxes paid in advance. No mention was made of any intention to refund taxes previously collected but not paid in advance. - -- .////. .// Charles Senescall apache(a)bear.apana.org.au o:::::::::/// >::::::::::\\\ PGP mail preferred Brisbane AUSTRALIA '\\\\\' \\ Apache -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBM+x7cHawhvoxf0r9AQHmlwf+PGKn7C8MK1O/JaVwAwXNxkTHjpY1aTU1 CqYQXnuA4mhGNonTjMjsfjE9+M6rVgBq2o28EwtVm++yGR/DmNWjzCgv2pgzwqld wpDsFaLQBUN60lh2XrXVYNXTf3ipaO3F9f68t/sFJCOquui0NAjapO254ZPyHt9b +kjk1DRnG1V7mVpVRcL3hd1RBWkNTBCa/1bucvrEUPsav+17jgfnje3yDPoPf6KC o5e33YZoY3JoamGrejnEoWDXBrAucGJfGeqDjfG+6Ymz4RNSL2EKe7KtTgrtbXHo mN+i3uwVDBPjZsF/iiEoCQ5kwUSead5SkuZu/uUFSk52C5L+544Cgg== =AFmN -----END PGP SIGNATURE-----

1 0

REPOST : Un-forgeable Cancels
by jbaber＠mi.leeds.ac.uk 17 Dec '03

17 Dec '03

I don't think this got through the first time so I am resending it...... -------------------------------------------------------------------------- OK so this has probably been thought of before or has some horrible problem that I have missed but how's about this as a method of verifying that cancels have actually come from the author of a message. I have seen a number of solutions that use various signature algorythms to check that the cancel has been sent by the original author of the message. However these require that the news program has access to the public key of the author in order to verify the signature before honouring the cancel. Since there are millions of authors on usenet I believe that this is impractical and, not suprisingly, key management again turns out to be a major problem which I believe can be solved using one way hash functions. 1 When any message is sent a hash X is calculated as : X = HASH(Mid,S) where Mid is the Message ID S is a secret controlled by the author (eg a pass phrase) 2 The hash value Y is then calculated such that: Y = HASH(X) = HASH(HASH(Mid,S)) 3 The value calculated for Y is then included with the message as X-Cancel-Ref: Y This does assume that message IDs are available by the news program and are not allocated after sending. If this is not the case then it would be necessary to use other header information to calculate the hash such as the date/time and subject, or to store some kind of key at the authors end in order to reference the message (although in this case X may as well just be generated randomly and stored). If the user later decided that the message should be canceled he must re-calculate X using the message ID and his pass phrase and include this value in the cancel : X-Cancel-Key: X News programs can then be set to check that a valid value of X such that HASH(X)=Y has been received before honouring the cancel. Note - I realise that this does not stop anyone who can change the X-Cancel-Ref header from canceling the message but if they can do that they can probably just delete the message anyway. Any comments/glareing weaknesses that I have missed? Jon http://chem.leeds.ac.uk/ICAMS/people/jon/

4 4

HIP
by ant＠replay.xs4all.nl 17 Dec '03

17 Dec '03

Hi, See https://cypherpunks.campsite.hip97.nl Also watch TV and the newspapers next week. We have been promoting the education mission..... Scanned paper PGP source code proofreading is nearing completion (by non-US people of course), and we hope to finish this weekend. Whitespace is the most hassle, even in places where it doesn't affect the code's meaning. Another time publish a paper version w/o comments and tabs. Our meeting is postponed to Sunday 16:00 local time to avoid a clash w/ Bruce Schneier. Some CPs had difficulty leaving the US to get here. It's not very clear how purposeful that was, but they'll tell you the details if they want to. :) :) :) Antonomasia normally ant(a)notatla.demon.co.uk till Monday morning ant(a)replay.com

1 0

JOB_les
by John Young 17 Dec '03

17 Dec '03

8-28-95. NYPaper, Page One lead: "Skilled Workers Watch Their Jobs Migrate Overseas. College Educated Foreigners Are Doing High-Technology Tasks for Far Less Pay." The new tools of the information age were supposed to help the United States regain an edge in international competition. And while that has happened in many advanced-technology industries, the combination of powerful personal computers and high-capacity undersea telephone cables is also subjecting millions of white-collar Americans to the same global wage pressures that their blue-collar counterparts have long faced. As with steel and garment workers, the white-collar workers' positions and salaries increasingly depend on whether they can justify their higher pay with higher productivity. Many fear that the growing tendency of corporations to farm out tasks to developing countries is widening the gap even further between the rich and everybody else in American society by eliminating some categories of high-skill, high-wage jobs that make up the heart of the middle class. "Dissecting the information revolution (in advance): With a look at one of Newt's Laws and at 'friction-free capitalism.' " [Expands on last week's Aspen article] The Aspen conference provided some people with their first exposure to Newtonion economics -- which appears to be the information-age equivalent of Ronald Reagan's trickle-down economics. It is called "friction-free capitalism." Nathan Myhrvold noted that one can now order custom-fit blue jeans directly from the manufacturer. Double trouble: JOB_les (17kb)

1 0

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

17 Dec '03

>From: Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> >We were using ALPHA code when we started .... I didn't realise that. >(4) is still applicable isn't it ? >What tells people to stop, or do they go on for ever ? A message in a newsgroup, a mailing list, or a web page. Even if you can mount a denial-of-service against this, it will only make people continue the search uselessly. It won't prevent you from finding the key. >>The main drawback of the random search is that the expected running "time" >where "expected" is some loose average ..... Nope. It's what I get when I do the math (basic probability theory) to find the expected running time. But I could be wrong. I'll try to write it in TeX and put it on my web page. >>I suspect that sequential searching from a random starting point would be >>much worse in the case of many independent searchers. >Convince me (please) .... That would be hard because I've been thinking about it, and I'm less and less convinced myself. >> In conclusion, I think random searching is the way to go. >It has its advantages -- yes. Did you use it for Hal1 ? :-)) No, but I had few machines and fast connections (and even then, I did have some network problems). But if you think sequential searching can work, let's do it. I don't think we have to worry about deliberate attacks for the moment, and the factor of two is significant. My previous message was based on the assumption that it would be hard to get rid of the server overload. Maybe we should use random searching as a fallback mode in case of network problems. It cannot hurt, except that it makes the programs more complex. -- Damien

1 0

Re: random coincidences
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Scott Brickner writes: > If NetScape uses such a PRNG to select 40bit keys for SSL, then > the work to be done in brute-force search going on right now might > be *significantly* reduced by knowing the planes on which the > numbers lie. If the constants are particularly poor, there might > be as little as ten or twelve bits of real key. So who here knows 80x86 assembler, is handy with a debugger, and has a few hours of spare time to figure out the PRNG? andrew

1 0

Bet e$ on how long it will take for PGPFone to make it overseas!
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To loosen up the often so serious discussions on the list, I propose a little game. PGPFone's release is about a week away. PRZ is trying his hardest to keep it from being exported. Still, I have the feeling that some irresponsible cyphercriminal will break US law and export PGPFone anyway. Let us bet cyberbucks on how long it will take for this crime to happen. Here is my initial offer: I bet e$50 that PGPFone will have been exported 24 hours after its final release has been announced to this list. Who is willing to take the bet? Perhaps someone is willing to bet at less time? Have fun, - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMC6k0CoZzwIn1bdtAQExpwF+JN52E31iW2XIepF1eINcDLJIrxsyY+4Y Dkc8HTBQdKZch6RAah+MT8/Q2ALSIwgO =TpOg -----END PGP SIGNATURE-----

6 5

Re: SSL trouble
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Piete Brooks writes: > Let's not get implementations confused with algorithms ... We were > using ALPHA code when we started .... Pardon me here, as I don't mean to belittle your considerable efforts, but I think it was a mistake to make such loud announcements (posted to sci.crypt for instance) when the software was alpha! The software should have been tested and stable before the general public was invited to participate and "see how fast we can break SSL" As expected, lots of people tried to participate and the software just couldn't handle it. How many patched versions of the client software were distributed after the effort had started? If you want to do it as fast as possible, you can't be constantly updating your client software. > With BETA clients, a hierarchy and select/poll loops, I reckon a > server would stand a chance. I think protocol issues are a Red Herring. If your server had been able to handle more than one client at a time it would have stood a chance. Why didn't it fork? Sure, forking isn't the most efficient way to handle multiple clients, but HTTP servers (as well as SMTP and FTP) manage to handle hundreds of thousands of requests each day that way. One client at a time with a 30-second timeout was just plain dumb... I would recommend thorough testing of the software on many platforms and with realistic loads before the next public effort (there are plenty of willing testers on the cypherpunks list). I tried to join in the effort and after discovering that the client software was firing off multiple brutessl processes, I decided to wait until the client stabilized. I attempted to reject the keyspace I allocated through the WWW interface, but that didn't even work!! andrew

1 0

Server congestion
by Christian Wettergren 17 Dec '03

17 Dec '03

I talked about acks of acks in a previous message, and I guess is was somewhat vague there. What happened, according to my uninformed view, during the SSL2 challenge was that the server got congested, and had problems with both answering to key allocation requests and ack replies. I guess that the load of the machine was so high that it lost packets in the input queues. Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack ------------------> ?? One problem was that the client believed that the ACK had arrived at the server if it had sent it off, not counting with the possibility of the ACK being lost on the way. I instead propose that the Server sends a acknowledgement back to the client once it has received an ACK from a client. | working... | Client ------- UDP/ack ------------------> Server -+ | Client <------ UDP/Server-ack ------------ Server -+ And then the client knows the server actually received the ACK and has incorporated it into its table. The client has to handle the case that either the Ack or the Server-ack is lost. I propose it doesn't retransmit immediately, but rather waits until next time it has to ack something, and piggybacks the old ack onto the new one. Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack1 ------------------> ?? | "oops, oh well, lets try later." | Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack2/ack1 ------------> Server -+ | Client <------ UDP/Server-ack {1,2} ------ Server -+ | There are countermeasures if either part doesn't get messages for some reason. If the server doesn't see the ACK for a block, it might give that block out to someone else. If the client is unable to retrieve a block from the server, I suggest it just picks a random block and starts working on it. I may very well not be allocated to someone else, and then the client was able to do something good in the meantime even though it didn't get a proper key alloc. /Christian

2 2

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Christian Wettergren <cwe(a)Csli.Stanford.EDU> writes: >If the client is unable to retrieve a block from the server, I suggest >it just picks a random block and starts working on it. I may very >well not be allocated to someone else, and then the client was able >to do something good in the meantime even though it didn't get a >proper key alloc. Not only that, but the client ought to allocate some keyspace before it needs it, as I think one other cpunk suggested. 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. 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. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCUAwUBMEHCiREcrOJethBVAQHqfwP4xfVbdkyR19WA5k4oC0GjW80s3nNrLkXZ mYspBE8e01waJ+6NYkeyvE4lPzW4OwkKTAtZV64GWovpjsyYh4bb7/mkpkdOktAZ J9DkHXouQ5M23FImbIcfkVUqQdR5tmSdHQqOpUNYPVqT3JZR6IC9vzwYoqcnQWyY WIIGs8DTUA== =9Y8g -----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