December 2003 - cypherpunks-legacy

Cypherpunks are a bunch of happy people
by nobody＠replay.com 17 Dec '03

17 Dec '03

Cypherpunks are a bunch of happy people basr Discussed were, amongst many other subjects, PGP encryption, building personal anonymous remailers, encryption of IP packets, and a kind of anonymous remailing system for IP packets (http, ftp, ...) using 'onion' servers. These guys promised us some nice stuff for our homes and schools in the near future like your own nice 'n' small anonymous remailer. If many people put these up and a system of anonymous remailers who give messages to each other before delivering it to the addressee is established, you can always say that *your* remailer was just one of the middlemen, receiving stuff from other anonymous remailers. Next, we are going to get cheap (under US $1.000) linux routerboxes that encrypt all traffic you send out to the network. Specially designed for the school and the home. This makes surfing in the childrens bedroom perfectly safe again! On the anonymous remailing of IP packets project the cypherpunks are workng together with the naval security of the USA. Why? These naval security people are working on the same thing, and they need other traffic using the same protocols to hide their own traffic in. Otherwise everyone can see they are transmitting from A to B. However, the cypherpunks had to explain the naval security first that if they want this technique more widespread, they have to make it available for cheaper machines and morre widely used operating systems... something they had not thought of themselves. You might think: "Is all this not illegal?" No it's not (yet, in most countries), and making up laws costs more time than writing good encryption software, so say the cypherpunks. That is... if they can find enough people to write the software. Yes, you guessed right, they are hiring! http://magazine.dds.nl

1 0

Re: R.I.P. John Brunner
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:03 PM 8/28/95, Alan Bostick wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Science fiction writer John Brunner died last Friday, August 25, from >a massive stroke, while attending the World Science Fiction Convention >in Glasgow, Scotland. > >Among several other notable works, Brunner was the author of THE SHOCKWAVE >RIDER, a groundbreaking vision of the information age that inspired and >forsaw much that was pertinent to the Internet in general and the >Cypherpunks in particular. > >Let us pause a moment to note his passing and honor his life and >contributions. I am saddened to learn this. And, yes, this has a lot to do with Cypherpunks. I read "Stand on Zanzibar" with rapt attention in 1969 or so, and it had a big influence on me. Ditto for "The Shockwave Rider," one of the very first explications of how identities would be changed, how the State would insist on computerized identities. (Indeed, "1984" came first, and is an even more important work, by any standards, but Brunner still nailed the effects of computers in a way that Orwell could not possibly have.) Christ, what an imagination he had! --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

Searchnet
by The Gate 17 Dec '03

17 Dec '03

Some time ago, I posted a reply to an allegation that the Spotlight was a Klan paper. Of course, it is more Liberty Lobby/CIA, with Bo Gritz on the Board. The point of this post is that those who want to know what is up with the Spotlight need to subscribe to Searchnet, which covers all the information of like sort. There was also a wonderful post recently hailing hackers as the ones who are most likely to prevent government sponsored crypto-terror censorship. Those who would like the post, speak up. Those who want to subscribe to Searchnet, likewise. Hope this does not get in the way of PGP implementation. Onwards, Lee ____________________________|||||||||||||||||||||______________________________ R. Leland Lehrman@The Gate, New Haven, CT. http://id.wing.net/~gate/gate.html God, Art, Technology and Ecology Research and Development >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Do you love the Mother?>>>>>>>>>>>>>>>>>>>>>>>>

2 1

Correction: List of crypto-related courses
by Avi Rubin 17 Dec '03

17 Dec '03

Oops, I got the URL a bit wrong in my last posting. Here it is again with the corrected URL. For the last year or so, I have built and maintained a list of graduate level courses on cryptography and security. The current list can be found at http://www.cs.nyu.edu/~rubin/courses.html I would like to keep this list as current as possible, so if you have any additions/corrections, etc, please let me know. I am only interested in full-semester courses at universities. Thank you, Avi ********************************************************************* Aviel D. Rubin rubin(a)research.att.com Secure Systems Research Dept. Adjunct Professor at NYU AT&T Labs - Research 180 Park Avenue http://www.research.att.com/~rubin/ Florham Park, NJ 07932-0971 Voice: +1 973 360-8356 USA FAX: +1 973 360-8809 --> Check out http://www.clark.net/pub/mjr/websec/ for a new book on web security (The Web Security Sourcebook). *********************************************************************

1 0

Re: Florida Drivers Permits and a Hello
by Alan Olsen 17 Dec '03

17 Dec '03

At 01:47 PM 8/29/95 -0500, you wrote: >Alan Olsen writes >>They would not have to include an entire thumbprint. The actual code used >>to verify fingerprints is not very large. All that would be needed is >>enough information to ID into the "official" records and enough checksum >>type information to prevent alteration/counterfitting. Using magnetic media >>for this is a bit foolish as it can be changed/destroyed with the stroke of >>a magnet. I will not say by what means I would think should suit as a >>better encoding scheme because: 1) They are not using it and 2) I do not >>want to give them any ideas. > >What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. I was pointing out that it was possible. I was not trying to make the point that there was any *USE* for such a thing. (Evidently some ID cards now carry such prints. California does, if memory serves me correctly.) Just because something is silly does not mean it will not be tried by someone in law enforcement. In fact, there seems to be a corelation between silly acts and law enforcement... (Or at least those making the rules about law enforcement.) And if you think it cannot get any worse, Pete "I want to seal the borders" Wilson has announced he is running for president. We will be getting a large number of silly laws and pronouncements if the American people are stupid enough to elect him to high office. > > | Visualize whirled keys! | alano(a)teleport.com | |"The moral PGP Diffie taught Zimmerman unites | Disclaimer: | |all mankind free in one-key-stenography-privacy!"| Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

2 1

Re: Florida Drivers Permits and a Hello
by d-jones＠ix.netcom.com 17 Dec '03

17 Dec '03

>What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. There are device that will electronicly read fingerprints available now. So with such a device, the LEO would know instantly if you were who you said that you were.

4 3

Why the government should protect our privacy
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 12 Aug 1997 20:15:33 -0400 From: Marc Rotenberg <rotenberg(a)epic.org> To: declan(a)well.com, Michael Sims <jellicle(a)inch.com> Cc: fight-censorship(a)vorlon.mit.edu Subject: Re: trustee, shmustee At 7:46 PM -0400 8/12/97, Declan McCullagh wrote: >On Tue, 12 Aug 1997, Michael Sims wrote: >> >> What groups want for privacy of individuals: >> >> Government: Lots > >Michael, thank you for reminding us of the Clinton administration's >valiant efforts to protect individual privacy. > >I agree that we should blissfully ignore that we're talking about the >Clipper Chip president, the Digital Telephony guy, the same fellow who >will veto any pro-privacy crypto bill. We should try to forget last >year's anti-terrorism bill, push for roving and multipoint wiretaps, and >FBI desires to ban nonescrowed domestic crypto. No longer should I be >concerned about the administration's quest for enormous voracious >databanks that will be tied together -- airport security, travel records, >national id cards. And of course ACLU legislative counsel Don Haines is a >fool when he speaks of "the Clinton-Gore effort to hardwire Big Brother >into the information age. > >Silly me. > Declan is absolutely right. Good thing there are no real privacy officials in the federal government and no privacy laws for the Internet to get in the way of these efforts. Has anyone else noticed that the most sweeping proposals for surveillance are coming from the administration that has backed the fewest privacy laws of any administration in 30 years? Mere coincidence? I don't think so. Marc. ================================================================== Marc Rotenberg, director * +1 202 544 9240 (tel) Electronic Privacy Information Center * +1 202 547 5482 (fax) 666 Pennsylvania Ave., SE Suite 301 * rotenberg(a)epic.org Washington, DC 20003 USA + http://www.epic.org ==================================================================

2 1

SSL keyspace etc.
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

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

Re: Guy Polis (fwd)
by Rabid Wombat 17 Dec '03

17 Dec '03

Lame forgery. -r.w. ---------- Forwarded message ---------- Received: from sirius.infonex.com (sirius.infonex.com [206.170.114.2]) by mcfeely.bsfs.org (8.6.12/8.6.12) with ESMTP id AAA19634 for <wombat(a)mcfeely.bsfs.org>; Tue, 12 Aug 1997 00:48:20 -0400 Received: (from majordom@localhost) by sirius.infonex.com (8.8.5/8.7.3) id SAA11251 for cypherpunks-outgoing; Mon, 11 Aug 1997 18:52:35 -0700 (PDT) Received: (from cpunks@localhost) by sirius.infonex.com (8.8.5/8.7.3) id SAA11069 for cypherpunks(a)infonex.com; Mon, 11 Aug 1997 18:51:57 -0700 (PDT) Received: from rigel.cyberpass.net (root(a)rigel.infonex.com [206.170.114.3]) by sirius.infonex.com (8.8.5/8.7.3) with ESMTP id SAA11040 for <cpunks(a)sirius.infonex.com>; Mon, 11 Aug 1997 18:51:47 -0700 (PDT) Received: from toad.com (toad.com [140.174.2.1]) by rigel.cyberpass.net (8.8.5/8.7.3) with ESMTP id SAA16287 for <cypherpunks(a)cyberpass.net>; Mon, 11 Aug 1997 18:49:20 -0700 (PDT) Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id SAA24951 for cypherpunks-unedited-outgoing; Mon, 11 Aug 1997 18:31:39 -0700 (PDT) Received: from wombat.sk.sympatico.ca (wombat.sk.sympatico.ca [142.165.5.136]) by toad.com (8.7.5/8.7.3) with ESMTP id SAA24939 for <cypherpunks(a)toad.com>; Mon, 11 Aug 1997 18:31:33 -0700 (PDT) Received: from default (lohner24.sk.sympatico.ca [142.165.98.24]) by wombat.sk.sympatico.ca with SMTP (8.7.1/8.7.1) id TAA03761 for <cypherpunks(a)toad.com>; Mon, 11 Aug 1997 19:27:46 -0600 (CST) Message-ID: <33EFBCAD.5D8(a)mcfeely.bsfs.org> Date: Mon, 11 Aug 1997 19:30:21 -0600 From: Rabid Wombat <wombat(a)mcfeely.bsfs.org> Organization: Electronic Forgery Foundation X-Mailer: Mozilla 3.01C-SYMPA (Win95; U) MIME-Version: 1.0 To: cypherpunks(a)toad.com Subject: Re: Guy Polis References: <g6maBe1w165w(a)bwalk.dm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cypherpunks(a)cyberpass.net Precedence: bulk Reply-To: Rabid Wombat <wombat(a)mcfeely.bsfs.org> X-List: cypherpunks(a)cyberpass.net X-Loop: cypherpunks(a)cyberpass.net Dr.Dimitri Vulis KOTM wrote: > There's a crackpot by the name of Guy Polis (guy(a)panix.com, polis_guy@ > jpmorgan.com) who posts a crackpot "cryptographic manifesto" and sounds > like a bad troll intended to make the folks who promote the use of crypto > look like, well, crackpots. Be warned. Tim May wrote: > Yeah, and like we're gun-nuts, too! The mammalian jackass is also claiming that all crypto promoters are marsupials. -rw

1 0

Poisson numbers for random keyspace assignment
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:03 PM 8/29/95, Damien Doligez wrote: ... >But you fail to take into account the probability that the search will >have to go that far. > > >This is how I compute the expected cost of the random search. > >The probability of finding the key upon searching the k-th segment is: > > k-1 > p(k) = (1 - 1/n) . 1/n > >The expected cost is the sum of all possible costs, weighted by their >probability: > ___ ___ > \ \ i-1 >e = > i p(i) = 1/n > i (1 - 1/n) > /__ /__ > i = 1..oo i = 1..oo ... I haven't checked Damien's notation and confirmed the results, but I have another way of looking at it, which I think produces the same results. Last night (but it didn't arrive at my site until moments ago, for some reason) I wrote: >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.) Here's what I meant, in more detail: Imagine the overall keyspace to be searched as a line segment of some length: [------------------------------------------------] Now imagine various people randomly picking starting points and doing some segment, depending on their compute power: [---] [--] [--------] [------] [-] [--------] ...and so on, with the various line segments scattered randomly. Some will overlap, meaning the same keyspace segment is being searched by two or more people. If the total length (summation) of these line segments is the same as the "brute force exhaustion" of the keyspace, we can do some interesting calculations. For example, the "expected" number of hits per point is "1". But some points will be hit 0 times, others will be once, twice, three times, etc. (This is in the nature of random processes, as each line segment is random and "independent" of what other people may have independently picked.) The Poisson distribution fits this situation exactly, with the _actual_ number of hits computed by: P(s;m) = (e ^ -m) (m ^ s) / s! where s is the actual number of hits and m is the expected number. P(s;m) is the probability of seeing s hits when m are expected. s m P(s;m) 0 1 1/e, or .368 1 1 1/e, or .368 2 1 .184 etc. That is, with the "total exhaustion" amount of computation there will be 36.8% of the keyspace left unsearched, simply because nobody's random segments landed on this fraction of the overall segment. If twice, three times, four times, etc. as much effort is put into it (enough to brute force the search space twice, using nonrandom assignment), then s m P(s;m) 0 2 .135 0 3 .0498 0 4 .0183 For s = 0, P(s;m) = e ^ -m Several conclusions can be drawn. Here's what I conclude: * For opportunistic attacks on keys in challenges, the odds are 95% that a key will be found with only twice the total effort (or time) using a totally random method of picking up keyspace to search. * This is probably good enough. (And if one only wants to be 90% sure of finding the key, even less effort is needed.) * And this affects several of the "denial of service" attacks mentioned here by others, including finding the key but not reporting it (for whatever reasons), claiming too much keyspace, etc. This is because some of the same regions are actually being searched two or more times. * This of course gets rid of the assignment problems. * If the intent is to show that keys can opportunistically be found, the random assignment method works pretty well and is "good enough." If, for some reason, a key _had_ to found, then a more careful, nonrandom assignment method would be best. As assignment methods get better, a crossover will occur, and the random assignment method will lose its advantages. --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