December 2003 - cypherpunks-legacy

Please send me SSL problems...
by Jeff Weinstein 17 Dec '03

17 Dec '03

I'd just like to let all cypherpunks know that I'm really interested in getting any feedback you might have about security problems with Netscape products. I'm particularly interested in bugs in the our implementation of SSL, and problems in the protocol that are not addressed in SSL 3.0. We have been collecting comments on SSL 3.0, and have started incorporating that feedback into our spec. Please don't assume that our lack of response means that we are ignoring your comments. Between Navigator 2.0 and things like the SSL challenge and the RNG fire drill, we just have not had the time to get a new rev of the spec out. Hopefully soon... I should also warn folks that Navigator 2.0 will not include SSL 3.0. We just don't have time to do it. It will become a high priority for us after 2.0 goes out, or maybe sooner depending on hiring. --Jeff Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

2 1

The future of Digital (Ouch!) Implants
by TruthMonger 17 Dec '03

17 Dec '03

NotW: * An April issue of New Scientist magazine reported that Australia's national research organization CSIRO has already made three sales of its "phalloblaster" device (at about $3,500 [U.S.]) that inflates the genitalia of dead insects to make it easier to classify them. Its official name is the "vesica everter," and it will work on genitalia as small as those of moths with wingspans of 2 millimeters.

2 1

Re: RSA Prevails In Arbitration Against Cylink
by jordan＠Heuristicrat.COM 17 Dec '03

17 Dec '03

From baldwin(a)RSA.COM Wed Sep 20 09:09:30 1995 Here's an article on the RSA-Cylink arbitration from the business wire. [ ... elided -JMH ] Just a note for those who aren't aware, Business Wire is a pay-per-use "news release" service. That is, RSA wrote the contents of what Bob (Hi!) posted. The clue is at the bottom of the "story": CONTACT: RSA Kurt Stammberger, 415/595-8782 kurt(a)rsa.com This is not to say anything pro or con about the content of the press release; just that it wasn't written by a third party. /jordan

1 0

Texas CypherPunks Take Up Arms!
by TruthMonger 17 Dec '03

17 Dec '03

We need to thank Jim Choate for his tireless efforts in this regard. * According to USA Today in May, a bill pending in the Texas legislature would allow anyone with a record of mental illness nonetheless to obtain a concealed weapon permit if approved by a doctor. http://www.nine.org/notw/notw.html

1 0

SCIENCE magazine on computers
by cjl 17 Dec '03

17 Dec '03

The Sept * issue of SCIENCE magazine has a special section on computers of particular C-punk interest are articles on the rise of symmetric multiprocessor solutions to supercomputer needs and a piece on the future of computing discussing quantum dots, quantum computing, holographic association, optical computers, and DNA computers. SCIENCE vol. 269 pages 1354-1385 C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl(a)welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )

1 0

Oxygen Escrow (Government Regulations soon to be announced!)
by TruthMonger 17 Dec '03

17 Dec '03

>From NotW: * Bangkok's largest English-language newspaper, The Nation, reported in February on a raging war by coffin sellers in the southern Thailand city of Nakhon Si Thammarat. Eight shops are located across the street from the city's largest hospital, and bribes of hospital personnel for clients are common. A television station reported that one shop's agent sneaked into several hospital rooms to disconnect oxygen to terminal patients whose relatives were already known to the shop and thus might have given that shop their business.

1 0

CLAIMING CHUNKS OF KEYSPACE...
by tcmay＠got.net 17 Dec '03

17 Dec '03

Date: Mon, 28 Aug 1995 23:02:01 -0700 To: cypherpunks(a)toad.com From: tcmay(a)got.net (Timothy C. May) Subject: Claiming chunks of keyspace... Looking at it from the outside, I thought the latest SSL challenge experiences were highly instructive. Nothing to be ashamed of. An interesting question: Is it a valid approach for J. Random User to "claim" some chunk of keyspace to search? If the "reward" of finding the gold buried in the keyspace (a key that meets the challenge) is high and the cost of claiming the keyspace is low (or nil), then game theory tells us that some folks will be tempted to claim a bigger chunk of keyspace than they can possibly process. What can be done to reduce this effect? On the negative side, ostracize or punish those who bite off more than they can chew. This approach is fraught with dangers. On the positive side, let everyone simply attack the keyspace as they see fit, picking random parts to attack. This should not be "worse" than a factor of several from a "perfectly coordinated" attack. (I haven't spent time calculating this, but my intuition is that a random attack, with overlapping keyspace, is not a lot less efficiently attacked than attempting to arrange for no overlaps...just based on my mental picture of dropping line segments randomly on some interval and figuring coverage of the line segment.) In between, market systems where itermediate agents subcontract out chunks of keyspace. Mechanisms for this are lacking. -Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

"CITIZEN-UNIT IDENTIFICATION" A RED HERRING
by tcmay＠got.net 17 Dec '03

17 Dec '03

Date: Mon, 28 Aug 1995 21:44:12 -0700 To: cypherpunks(a)toad.com From: tcmay(a)got.net (Timothy C. May) Subject: "Citizen-Unit Identification" a Red Herring All this paranoid talk about the dangers of thumbprints on ID cards, about driver's licenses, and about magstripes got me to thinking. So, I accessed my NLETS (National Law Enforcement Telecommunications System) and downloaded my own record: Citizen-Unit ASCII Name: "Timothy Christopher May" NLETS Actual Name: G0Yj34C1qm92H7u Known Aliases: "Klaus! von Future Prime," "Lance," "Nick Szabo" Residence: 427 Allan Lane, Corralitos, CA 95075 Driver's License: N4197484 SSN: 227-80-5823 Passport Number: H673qop90 Race: Aryan Origin: Europe Hair: Brown Eyes: Blue Weight: 210 pounds (10/94, recorded at SFO) Known associations: Anarchist Alliance, Young Students for Discordianism, Vernor Vinge Fan Club, Information Liberation Front Magazines Subscribed To: Newsweek, Playboy, The Economist, MacWeek, Anarchy Today, Liberty, FertilizerWorld, Reason, MacUser, NewtonGazette, Bay Aryan Events, Information Week Consumer Preferences: beer (+++), wine (+), cigarettes (-) Electricity Patterns: consistent with either marijuana cultivation or heavy Net usage, or both Threat level: Class 3 Security Threat I don't see what the big deal is. The NLETS record implies I'm some kind of security threat, but also correctly notes that I'm an Aryan, so I guess I'm safe. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

4 Horsemen - 1 Child Citizen - 0 / (Where are Lous Freeh and Janet Reno when you really need them?)
by TruthMonger 17 Dec '03

17 Dec '03

WEIRDNUZ.493 (News of the Weird, July 18, 1997) by Chuck Shepherd * In May, the Minnesota Court of Appeals reversed a $1 million award by a jury that had found parishioner Dale Scheffler, 30, to have been molested at age 14 by Catholic priest Robert Kapoun, finding that Scheffler's lawsuit was barred by the statute of limitations. Two weeks later, the Archdiocese of St. Paul and Minneapolis announced that it had filed with the court a claim of $4,937 against Scheffler to recover part of its legal expenses since the Archdiocese is now regarded as the winning party. Father Kapoun filed for $1,081.

1 0

SSL keyspace etc.
by vznuri＠netcom.com 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 95 12:40:08 -0700 From: "Vladimir Z. Nuri" <vznuri(a)netcom.com> regarding SSL challenge, I am not following this close enough to understand completely, but I thought I would offer a few suggestions for tweaking the code: -- the issue of grabbing keyspace has been raised. what if someone malicious just yanked huge areas of keyspace and didn't search them? it seems that the clients need to return to the server some evidence that they have searched their keyspace in question. the server could verify this evidence. for those that don't return the "evidence", that keyspace could be reallocated to other comers. the simple approach to all this, if you don't have "evidence", is to just have the server keep reallocating the same space over and over to different crackers. hopefully eventually every part of the keyspace would be allocated to a "legitimate" worker. -- the issue of efficiency is very fascinating for this project. essentially the server has no idea what the block size of key blocks it should dole out. obviously the server would want to try to dole out equal *processing chunks* such that the remote machine reports back in a certain amount of time, no matter what architecture. the problem of course is that remote machines all have different efficiency. two possibilities: a sort of "bogomip" calculation is done in the client, and its processor speed is reported to the server. the server uses this in a calculation to determine how much to dole out. it could try to derive a best fit linear relationship between space covered and processor spead, or build up a table of results and interpolate for new requests. note that the efficiency issue also ties into "what if people take keys they don't solve". if the server knows roughly how long a client should take to report back, and it never reports back, it could then reallocate that key space. -- another problem of efficiency is that the server is clearly a bottleneck for servicing requests. the question arises: suppose that the server could determine the precise interval between which machines would go back to it for new keys. what is the optimum interval over the whole project? in other words, give the number of machines participating, and their processor speeds, what size of key space should be parceled out to the next request so that the bottleneck at the server is minimized? this optimum interval must be very hard to derive, because it depends on the contention based on many incoming connections. it would involve some probabilistic approximations of the likelihood of collisions. to model it, you might consider a request as taking [n] seconds of time, and consider that if any two requests are in contention, a retry happens after [m] seconds. you could build up models that would try to minimize the time based on empirical simulations. however I would be exceedingly impressed if someone could derive a formula for this, or give it from some textbook. -- adaptive algorithms for all these situations are possible. the server could use a "hypothesis" in the sense of partitioning out a starting size of keyspace, and then watch how long it took the client machine to respond and then assume a linear relationship or something to compute the size of the next keyspace to hand out to the machine. the server could continually watch how closely its "hypothesis" (i.e. its estimations of how long a given machine will take) match the actual returns. -- more on the idea of evidence: we are working with a hashing algorithm, right? as evidence the client machines could return checksums of all the hashes of all the keyspace it searched. it could break up its own search space into blocks and return the checksums on the hashes for each block. the server, if it wanted to, could verify these blocks running its own computations. if it ever found a client was "unreliable", it could then diminish the keys sent to the unreliable client, or even send it areas of search space it didn't care about anymore (i.e. areas that have already been confirmed searched by a more "reliable" client). -- in fact all this reminds me of the process of intelligence gathering by an agency, which could be formalized as follows: suppose that the agency wishes to identify "quality information". it has a set of sources, A,B,C,D.... now, it can send questions out to these sources and get information from them. some of them however would be "unreliable". the agency must devise some means by which it can weed out the unreliable sources. note that this may even involve sending them bogus instructions to keep them busy so they do not themselves suspect they have been "discovered" and then change their defective plans. obviously, one of the most important intelligence tools in this matter is that of *correlation*. you have to determine "truth" (or "quality information") via the correlation between answers that the different sources give you. also important to correlation is *redundancy*. you sometimes have to ask more than one source the same question, and test the answer. in this model, if A and B give different answers, you know that one of A or B is "unreliable". what is very interesting in our case of cracking keys is that the server can verify the information on its own. in other words, it has a *control* that it knows is correct that it can judge against the answers "out there". unfortunately, in contrast, real intelligence agencies are not always privy to this kind of certain "control" and in fact have to determine "truth" entirely from a set of sources, any of which might be unreliable. in this case one has to have a hypothesis about what is the "truth" and test it to see if it holds up consistently with all information. the approaches of attackers are obvious. the most obvious is that of collusion and infiltration. but I will save the rest for some NSA spook to elaborate. there are certainly enough colluding and infiltrating on this list <g> -- one of the reasons all this interests me is that it really reminds me of some projects I have worked on in the past. in high school I wrote a network mandelbrot set program (client/host). the issue of contention arose and it appeared to me to look like an upside-down parabola after I plotted some points (curving up, that is). i.e. the optimum was at the pit of the parabola, and when too few or too many requests happened, the speed over the overall simulation was increased above the optimum. some very ingenious readers may actually be able to locate this code, which I put in the public domain over 5 years ago. -- another thing I worked on was trying to find the optimal block size of communications protocols such as Zmodem, which generally instead just pick arbitrary block sizes 2^n. I actually was able to attack this problem analytically through the observations of the properties of infinite series and calculus techniques. it is a similar problem but the idea of contention really complicates this issue. (for what I studied, there was only one client and one server, so to speak). I still have this paper in Latex format and if anyone is interested I would be happy to send it to you. it's a really nice example, IMHO, of how if you use your brain and some mathematics, you can really get a far more elegant approach than brute force, and know with much greater certainty that what you are doing makes sense mathematically. an awful lot of programmer just tend to bang on the keyboard with out thinking of the theoretical implications of their work. this is understandable given that the theoretical implications of even trivial programs (such as the SSL client/server interactions) can be mathematically extremely daunting, requiring even differential equations to model fairly simple pieces of code. -- well, that is my contribution of the moment into the cypherpunk annals. one never knows what a little combination of boredom and inspiration can lead to. --V.Z.Nuri

1 0