December 2003 - cypherpunks-legacy

Re: Florida Drivers Permits
by Gerstein＠scsud.ctstateu.edu 17 Dec '03

17 Dec '03

At 1:54 AM on 8/29/95, Jonathan Zamick is believed to have said: >>>>Better would be to figure out the encoding scheme and post it here. >>> >>>I like this, myself. It'd be nice to be able to have the picture of my >>>choosing instead of a digitized thumbprint... >> >>I think the officer arresting you would frown if your license dumped a nudie >>picture of Cindy Crawford instead of your identification details. >> >>Sounds like a great way to smuggle nuclear secrets out of a country tho :) > >What is the capacity of the mag strips. Do they carry much more than some >ID code for computer reference? It seems unlikely that there is enough >storage >for a thumbprint. Some vitals perhaps, but again it would most likely simply >be a speedier way of referencing the card holder's supposed True Name. (After >all they'd have to be checking driving record information as well.) Still >decrypting the cards would be amusing, just to aggravate those who become to >used to the convienience. 'Oh.. sorry Governor Wilson... my but you look >different up close'. Back in CT they have mag strips and holograms on the drivers license, but they aren't taking full advantage last I checked (about 8 months ago, when I was last in CT). Anyway, once an enterprising c'punk cracks the code, whats to stop people from putting more interesting info on the strips? Or possibly a virus? Is it conceivable? And if there is enough room on there for personal info, why not wipe the data that's there and put your PGPKey there. And when Officer Opie asks "What happened to your info and why's it all scrambled?" an innocent "I dunno" would have to suffice.... Just my 0.02¢... adam "Practice safe HEX - always use a keyboard condom" - anon PGP Key available by finger or mail with the sub: PGPKEY +-------------------------------------------------------+ |(e)Mail me: | MacGeek(a)eWorld.com | | Gerstein(a)scsu.ctstateu.edu | AGerstein(a)aol.com | +-------------------------------+-----------------------+ EWWWWW! - Betsy Shop smart! Shop S-Mart! - Ash

1 0

Re: SSL trouble
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Bill Stewart writes: > 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. Single-user is just plain silly. With a fast timeout you still have problems with misconfigured clients hogging the server and legitimate clients that are running a little slow will also have problems. The server in the second challenge did have a fast timeout (it was too fast to easily query the server by hand, for instance) and it still wasn't adequate. I can't imagine making the timeout smaller. multi-user is the only way to go... andrew

1 0

Dr. McVeigh / Re: A peculiar notion
by TruthMailer 17 Dec '03

17 Dec '03

David D.W. Downey wrote: > Steve Schear wrote: > > In short, the Constitution itself was a casualty of >Lincoln's war. A Pyrrhic victory indeed. > > > For the first time in a long time, I've read a post that actually make > me seriously consider rethinking what I have been taught. I've studied > quite a bit in regards to US law and the Consitution, (made necessary by > my being Pro-PGP), and never looked in that direction. Your post adds a > very different light to things. > Thank you for the push. I also thought that it was one of the more thought-provoking posts in a while, but I would certainly never send a polite, thankful post to the list, saying so. My "CypherPissing" mail folder turned out to be genetically related to the plant in "Little Shop of Horrors" and, the larger it gets, the more it demands to be fed. In order to provide it with enough of the sewage-supplement it needs to keep from eating my "cat" command, I may have to send a post to the list praising Sandy Sandfort, Chris Lewis, and blessing Armenians everywhere. (I have tried remailing old ASCII-art spams to myself, but it refuses to eat left-overs.) (Perhaps I can get my "CypherPissing" folder a few snacks to munch on, in the meantime, by seeing if praising Tim McVeigh is still good enough bait to get a few nibbles. "Suckers" taste pretty good, if you "smoke" 'em.) Anyway... There are some concepts and arguments that "chip away" at an assumed belief or a train of logic, and there are those that knock down a load- bearing support column. The Joseph Sobran piece which Steve posted to the list could, with a proper "primer," do the kind of damage to our view of Civil War history as the OKC bomb did to the Murrah Federal Building. Come to think of it, maybe McVeigh _was_ the primer for explosive new views of why Federalism is quickly becoming indistinguishable from Fascism. The advantage that literature has over black powder is that it is reusable and doesn't leave as big a mess to clean up. The advantage that black powder has over literature is that it makes enough noise to get the message to the blind, as well, and sometimes even restores the sight of the blind. {Warning: Since the side-effects of Black Powder can be substantial, it should only be used in cases where the physician has determined that the benefits of "treatment" outweigh the risks. Dr. McVeigh's surgery in OKC falls into the category of private research (even if he did receive some government funding). However, follow-up research by others may lead to McVeigh's technique being improved and perhaps gaining enough recognition to make it standard paramedical procedure.} TruthMonger

3 2

Probability calculations
by Damien.Doligez＠inria.fr 17 Dec '03

17 Dec '03

>From: Scott Brickner <sjb(a)austin.ibm.com> >% k-space random sequential percent >searched method method difference [...] >99.9 115892899 16760439 591 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-1 = 1/n > > (1 - 1/n) /__ /__ i = 1..oo j = 1..i ___ \ i-1 = 1/n > (1 - 1/n) /__ {(i,j) | 1 <= j <= i} ___ ___ \ \ i-1 = 1/n > > (1 - 1/n) /__ /__ j = 1..oo i = j..oo ___ ___ \ j-1 \ i = 1/n > (1 - 1/n) . > (1 - 1/n) /__ /__ j = 1..oo i = 0..oo \_______________/ \_______________/ n n e = n This means that if you do many random searches (with a good RNG), the average cost of one search must be n. Any errors in the above ? -- Damien

1 0

Getting ecash without an MTB account
by Mike 17 Dec '03

17 Dec '03

Suppose I want to give ecash to somebody who don't have an account with Mark Twain Bank, and I want the receiver of the coins to know that the coins are genuine. I would have two accounts at MTB, one for savings and one for transactions. I want to give away a million bucks, so I deposit that amount in the transactions account. Then I give the account password to the receiver, he withdraws the money, and I change the password so he can't get any more money from me. I trust the receiver not to change my password, but if he does change it, then I can simply ask MTB to change it back, explaining that I lost my password. Would this work? Mike.

5 5

Claiming chunks of keyspace...
by tcmay＠got.net 17 Dec '03

17 Dec '03

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

Feds Seek PKI Bids
by John Young 17 Dec '03

17 Dec '03

USG published a solicitation today in the CBD for a Public Key Infrastructure which outlines the system requirements: http://jya.com/pkicbd.htm

1 0

Comments on PGP5.0 OCR (was Re: fyi, pgp source now available , internationally)
by Mark Grant 17 Dec '03

17 Dec '03

Charlie Root (root(a)cypherpunks.campsite.hip.nl) wrote: >http://cypherpunks.campsite.hip97.nl/pgp/ >and >http://www.pgpi.com/ (The former no longer seems to work, presumably because the machine is packed up and on its way home.) I just wanted to make a few comments on the proofreading, in case anyone feels like releasing software in a similar manner in future: The original printed and OCR-ed source gave a single checksum for each page, with four bits per line. It also ignored whitespace except in strings and comments. This meant that people could rapidly process the majority of the code to produce something which wasn't terribly pretty but functioned correctly. However, because there were only four bits per line an incorrect line could pass the checksum; this would still be detected because the checksums were chained, but it could mean that when an error was detected you had to check several lines to find the invalid one. Presumably because of this the OCR-ed pages at HIP included a per-line checksum. This was good... but... it also checksummed the whitespace. This wasn't a problem in theory, because tabs were indicated by a special character. However, most lines had both tabs *and* spaces and there was no way to see where the spaces were because they were overrriden by the tab (e.g. "mov<sp><tab>ax,23<sp><sp><tab><sp><tab>; Stuff"). As a consequence the proofreading went very slowly until some valiant folks (who may or may not wish to be identified, so I won't) worked overnight to put together a program to brute-force the checksum by trying all possible combinations of tabs and spaces until it found the right one. So for a future effort could we please have the per-line checksums but ignore the whitespace unless it's important (e.g. comments and strings again)? Or if you want to ensure that the whitespace is identical between versions, please either strip out unneccesary spaces or use a special character for them so we can see precisely where they are. If all we want is functioning code, then it doesn't have to look pretty; we can feed it through a code prettifier like indent when it's functionally correct. Mark

10 12

Forged headers
by travel23＠juno.com 17 Dec '03

17 Dec '03

Does anyone know of a URL where you can get information on how to forge headers and email addresses? The Traveler ----------------------------- "Sometimes you're the bug, sometimes you're the windshield."

4 3

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- "Daniel R. Oelke" <droelke(a)rdxsunhost.aud.alcatel.com> writes: >someone, probably either patrick(a)Verity.COM or hallam(a)w3.org, writes: >>Piete.Brooks(a)cl.cam.ac.uk, stripes(a)va.pubnix.com writes: >> >>> 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. >> > >That doesn't work under SunOS 4.1.x, but this does: > > date "+%S %M 60 * + %H 3600 * + %j 86400 * + %y 31536000 * + p" | dc > >This assumes 365 days/year, so if you jump from a leap year to a non-leap >year it won't work right. Hey - a 1/1460 failure rate is better >than most Windoze programs I've used ;-) > >It also isn't the "absolute" time, (as given by time()), but >gives a number of seconds that constantly increases. > >With a little more work you should be able to adjust this to be close >to time() functionality. This was, of course, originally one long line: date +"%S %M 60 * + %H 3600 * + %j 1 - 86400 * + %y 70 - 31536000 * + %y 69 - 4 / 86400 * + 3600 4 * + p" |dc Differences: %j 1 -, because days of the year are numbered from 1, not zero, and we don't want to count 86400 seconds for today before today has finished. %y 70 -, because 1970 is the epoch, of course. %y 69 - 4 / 86400 * +, takes into account all leap days in all leap years up through last year. Why? Left as an exercise for the reader. ;-) 3600 4 * +, this is a bit of ugliness. date +%s returns GMT for me. I'm in EDT, so that's four hours away from GMT. So this is necessary to make this return the same number as date +%s. But if you're in another time zone, you need to change that 4 above appropriately. If this whole section is deleted we are left with: date +"%S %M 60 * + %H 3600 * + %j 1 - 86400 * + %y 70 - 31536000 * + %y 69 - 4 / 86400 * + p" |dc which returns local time, which is probably what you wanted anyway. By the way, date --version, on my system, returns "GNU shellutils 1.9.4", just in case you were wondering what date I'm using. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEKT+REcrOJethBVAQEXgAQAx9HLiR+LPvclEYRFrliqOugj9cbzGwLD HCWOC8/MfrXuS3MPLQj1HugA18LH/LGy3BTp7cSnSNXDoL2/7UkLeAspGejRrEG4 WgQ8HIC2weVDP66PqioFD6lAELatRWk4Xl/mLgVrxluBrKtRnADtCX/VdHPw1ZiU YDfiWBtKRGU= =i1Di -----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.

1 0