December 2003 - cypherpunks-legacy

Re: So PGP2.5 is becoming clearing...
by lefty＠apple.com 17 Dec '03

17 Dec '03

>> Given that to my knowledge no court, federal official, or other >> organization that counts recognises "freeman status" to my knowledge, >> it would seem to be a very small loss. > >What they certainly _do_ recognize, however, is that a person who _does_ >agree to the PGP 2.5 terms has affirmed that he _is_ a national person. >This could be used by a court to negate any subsequent denial by the >person that he is a subject of the United States of America or Canada. >The absence on one's record of such affirmations is a prerequisite for >freeman status. Given that this "freeman status" seems to exist only in your fevered imagination, who's to say what might or might not be a prerequisite for it? I'm finding this whole thread extremely silly. Are you actually attempting to suggest that if someone not currently a US citizen were to use PGP 2.5 he would somehow become a "subject" (whatever _that_ is) of the United States? This would undoubtedly come as exciting news to Haitian boat people and Chinese nationals jammed into the cargo holds of trawlers in San Francisco Bay. What, I wonder, do I have to do to qualify for "moonman status"? -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

dos app STACKER, passwd?
by steve willey 17 Dec '03

17 Dec '03

does anyone know how password protection for the dos compression utility stacker works? and more importantly how it can be cracked. i will pay 5 Ghost Marks for USEFUL info. thanks, steve

1 0

Re: Caller ID info...
by fnerd＠smds.com 17 Dec '03

17 Dec '03

In this report... > Report and Order And Notice of Proposed Rulemaking of > March 29th, 1994 (CC Docket No. 91-281) ...FCC apparently decides that per-line blocking should be prohibited since people might forget to unblock it when calling 911. John Levine says, > In other words, per-line blocking is a bad idea because subscribers > are too dumb to unblock calls when they want to unblock them, although > they're not [too] dumb to block calls when they want to block them. To me the question is, why can't the phone company provide options for blocking-on-all-but-911-calls, and unlisted-except-for-911? More precisely, why can't the FCC allow for this simple possibility? The reasoning seems to be, "since we can't understand why people want this, we must prohibit its even being an option:" > > ...For the > > foregoing reasons, we find that a federal per line blocking > > requirement for interstate CPN based services, including caller > > ID, is not the best policy choice of those available to recognize > > the privacy interests of callers. Thus, carriers may not offer > > per line blocking as a privacy protection mechanism on interstate > > calls. "...We find" it "is not the best... thus, carriers may not offer" it. What about what the customers and consumer groups have found and fought for? What is wrong with letting this be decided on a regional, if not provider, if not local, if not personal level? Why must FCC impose least- common-denominator reduction of services? > > ...with comments due by May 18th. That's today. I'm faxing this ill-prepared complaint to 202-632-6975. > > Comments must reference the docket number (CC Docket No. 91-281). > > Send ten copies (yes, 10) to: > > > > Office of the Secretary > > Federal Communications Commission > > Washington DC 20554 -fnerd quote me - - - - - - - - - - - - - - - and i dreamed i was flying high up above my eyes could clearly see the statue of liberty sailing away to sea --Paul Simon -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

PGP 2.6 announcement
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

Does anyone have a copy of the announcement stating the PGP 2.6 would not accept message from previous versions of PGP after September 1, 1994? If so please send it to me. Thanks, Reuben Halper

1 0

Re: Caller ID info...
by peb＠netcom.com 17 Dec '03

17 Dec '03

Strange reasoning. Why not use the "*70" style code that turns it off for one call, just as *70 disables call waiting for modem use? Paul E. Baclace peb(a)netcom.com

1 0

RESEND: PGP 2.5 mini-review
by schirado＠lab.cc.wmich.edu 17 Dec '03

17 Dec '03

[I sent this out before I learned of the Great List Crash, so I'm resending it now.] Having not seen any activity on the list for the last week or so (I hope everyone's busy writing code!), I figured I'd simultaneously check to see if the list still existed, and share some interesting excerpts from NEWFOR25.DOC, from the PGP 2.5 MIT-legit package. PGP 2.5 is apparently still written by Phil Zimmermann - at least, it purports to be - which in itself is a considerable relief to those of us who had no idea who was responsible. The source code is also available, as before, and I'm sure programmers the world over are even now poring through it in minute detail, looking for backdoors and such. I also expect we'll be hearing from them relatively soon, to tell us of the presence or absence of any suspicious code. Not being a programmer myself, I can only comment on a few aspects. First, there is this: [...] >[An] RSAREF limitation is that it cannot cope with keys longer than >1024 bits. PGP now prints a reasonably polite error message in such a >case. I recall someone mentioning at one point that increasing the size of a key beyond 1024 bits did not justify the increased computing time, but I do not recall the reason why. I believe the reasoning was not that it offered no additional security, but rather, that it was already difficult enough to crack 1K keys, and if you're really that worried about security, you should be tightening up in other areas, such as deciding who to trust and who not to, deciding what information to enter into the computer and what to keep in your head, or maybe making a homemade TEMPEST shield. :) I'd still like to see the math explained a little better, though. Also, has anyone found those references to elliptic-curve crypto? The original article is _An Implementation of Elliptic Curve Cryptosystems Over F-2-155_ , IEEE Journal on Selected Areas in Communications, Vol. 11, #5, June 1993 (page 804). (Schneier mentions that Next Computer's Fast Elliptic Encryption, FEE, uses elliptic curves, and is patented by R E Crandell, USP# 5,159,632,27 October 1992.) Also, look for works by Neal Koblitz. >Printed keyIDs have been incresed to 32 bits, as there were enough keys >out there that 24-bit keyIDs were no longer sufficiently unique. The >previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. >For example, what was printed as A966DD now appears as C7A966DD. So even though the keyservers only have 5,000 or so registered users, there are enough people out there using PGP and NOT registering their keys with the servers that this extra bit of coding was necessary? Hmm. 24 bits gives us 16,777,216 unique ID's. 32 bits gives us 4,294,967,296. Are there really over 17 million PGP'ers out there, or is my math-impaired brain missing something painfully obvious? >PGP now enables clearsig by default. If you sign and ascii-armor a >text file, and do not encrypt it, it is clearsigned unless you ask >for this not to be done. Which would seem to indicate that PGP is mainly being used for e-mail! Goody! >[...] > >PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random >data in an attempt to force disk compressors to overwrite as much data as >possible. > >[...] > >The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as >fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, >or <language>key.hlp. No file is provided by default; PGP will use >its one-page internal help by default, but you can create such a file >at your site. > >PGP used to get confused if you had a keyring containing signatures from >you, but not your public key. (PGP can't use the signatures in this case. >Only signatures from keys in the keyring are counted.) PGP still can't use >the signatures, but prints better warning messages. Also, adding a key on >your secret key ring to your public keyring now asks if the key should be >considered ultimately-trusted. Prviously, you had to run pgp -ke to force >this check, which was non-obvious. > >[...] > >On Unix, PGP now figures out the resolution of the system clock at run >time for the purpose of computing the amount of entropy in keystroke >timings. This means that on many Unix machines, less typing should be >required to generate keys. (SunOS and Linux especially.) > >The small prime table used in generating keys has been enlarged, which >should speed up key generation somewhat. > >There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) >when generating primes 2 bits over a multiple of the unit size (16 bits >on PC's, 32 bits on most larger computers), if the processor doesn't deal >with expressions like "1<<32" by producing a result of 1. In practice, >that corresponds to a key size of 64*x+4 bits. > >Code changes: > >At the request of Windows programmers, the PSTR() macro used to translate >string has been renamed to LANG(). > >The random-number code has been *thoroughly* cleaned up. So has the >IDEA code and the MD5 code. The MD5 code was developed from scratch and >is available for public use. So, all in all, PGP 2.5 would seem to be more than just a possible conspiracy by MIT/RSA/et. al., and more than just minor bug fixes that most people wouldn't care about. With the possible exceptions of the size limitations on keys, and whatever arcane pieces have been hacked out of the RSA code to comply with whatever demands they may have made, PGP 2.5 appears to be a legitimate upgrade, with more than a few bugfixes, both major and minor, as well as the all-important improved security (as far as can be seen). Comments? ** schirado(a)lab.cc.wmich.edu [O|o]bjectivist, Evil Capitalist(tm;-), s..O).... You hit the smurf! --More-- male, lesbian, polyamorous, @.../.".. You destroy the smurf! --More-- reader, atheist, Discordian, $$*...].. You feel cynical! free and natural sovereign individual the Frog Farm: e-mail frog-farm-request(a)blizzard.lcs.mit.edu (PGP available)

1 0

RE: Cryptosystems Journal
by Pat Farrell 17 Dec '03

17 Dec '03

> Does anyone know where one can read back issues > of CryptoSystems Journal? I was looking for > Volume 2 Number 2. I tried at several Univeristies > but they said only the Library of congress had it. Tony Patti is the publisher of Cryptosystems Journal. He is _not_ on the net, his old portal account has been closed. He is working hard on Volume 3. You can reach Tony via snail mail to: Tony Patti Editor, Cryptosystems Journal PO BOX 188 Newtown PA 18940-0188 USA Tony has been publishing the Journal for a while, complete with floppies. I know he has non-US subscribers. I wonder how he exports it. I have a copy of Volume 2 Number 1, and Volume 2 Number 2. But you'd have to be in the DC area to see it. If we get a DC-area meeting working in May, I can bring it for folks to look at. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

MotherJones MJ94: Pretty good hellraisin' (fwd)
by truher＠mojones.com 17 Dec '03

17 Dec '03

MotherJones MJ94: Pretty good hellraisin' -- by Ariel Sabar Philip Zimmermann, our February 1994 Hellraiser, is rushing to finish what he tentatively calls Voice PGP, named after his uncrackable computer encryption program, Pretty Good Privacy. His new creation turns a personal computer into a secure telephone--much to the consternation of the feds. Voice PGP uses a computer and high-speed modem to compress and encrypt the caller's voice before transmitting it onto ordinary phone lines. Only the called party can decode what the user is saying, in real time. Why Zimmermann's hurry? "We have a window of opportunity to fill this technology niche before the government acts," he says. Otherwise, once U.S. intelligence gets its hands on telephone surveillance technology, "it will be like putting a sticker on every phone that says, 'J. Edgar Hoover inside.'" Zimmermann and other cypherpunks are already disturbed by the government's decision to install the Clipper chip (an encryption device whose passwords are known to both the user and the feds) in computer communications software. His aim is to get Voice PGP out there (for free, like PGP) and widely in use by the end of the year. All rights reserved. Redistribution permitted with this notice attached. Redistribution for profit prohibited.

1 0

Anonymity is rude...
by Eric Johnson 17 Dec '03

17 Dec '03

According to Intel (via their acceptable use policy) anonymity is "bad form" which is monitored: Do not post any messages anonymously. This is viewed as bad form by the Usenet community and system managers are asked to track down offenders. This wastes Intel's time and resources. http://nearnet.gnn.com/gnn/news/feature/intel_guidelines.html Ahem, --Eric

1 0

PGP for voice... it's here :)
by lile＠netcom.com 17 Dec '03

17 Dec '03

almost... -lile

1 0

Re: FW: James Fallows on Clipper
by peb＠netcom.com 17 Dec '03

17 Dec '03

Re: The Atlantic, June 1994. The article is another "Nothing to Worry About". The article unfortunately occurs in the same issue that has a feature article about the possibility of Russian gangs obtaining nuclear weapons which also details how the coup attempt was observed by the NSA and Bush decided to let the good guys know so that the attempt could be thwarted. The NSA opposed letting them know since it would reveal their abilities, but Bush took the chance that this was not as bad as having a bunch of hardliners controllng the big bombs. This feature article will certainly give people the impression that crypto must be controlled or is at least a very important millitary matter. Now the NSA can't listen in, the article reported, but who knows what they've done since then. I hope to write a letter responding to Fallows' article, but right off I noticed some errors: he states that the millitary and intelligence services will use Clipper themselves when in fact, it would not be approved for secret information. (Recently someone noted that this is probably due to the key handling methods, but it could certainly be due to escrow itself as being risky.) Additionally, he brushes aside the accepted cryptographic methods (open inspection and testing) as being frivolous. (This seems to be a result of the NSA envy and pride runs through the article.) Paul E. Baclace peb(a)netcom.com

1 0

Lunch Tuesday at Atlanta COMDEX 5/24/94
by mlshew＠netcom.com 17 Dec '03

17 Dec '03

You may recall my earlier message with the same subject line last week, wherein I proposed that all interested Atlanta Comdex attendees meet at noon Tuesday for lunch, above the food court in the CNN Center. I also said that I would post an updated version of that earlier message today, with appropriate error corrections, or time/place updates depending upon the response. (And include a listing of people attending for anyone wanting to have their name on such a list.) Well, now it doesn't seem as if there's much point in reposting the long message at all, taking up the corresponding disk space for hundreds of subscribers as well, as no one has yet responded to say they were coming. (Although I did get mail in support of the endeavor--thanks!) So either this means that extropians/cypherpunks are extremely paranoid about such things, or that they tend to get behind in their mail, or the most likely that they are not interested in flying across the country to attend an MS-Windows convention in the first place. (A rather healthy attitude if I do say so myself--cypherpunks "write code", they don't "sell inferior products.") I still plan to be there, eating lunch in any event, so you can still come up and chat. Anyone who wants a copy of the original plan can read my .plan by fingering me at mlshew(a)netcom.com, or getting it from ftp as netcom.com:/pub/mlshew/plan Mark Shewmaker mlshew(a)netcom.com

2 1

Patent infringement (fwd)
by Brian Beker 17 Dec '03

17 Dec '03

Greetings C'punks: Normally I'm just a lurker here on cypherpunks, but I thought that the new net.cop mode might be of interest to us all. Here are the results of Mr. Sternlight's assiduous policing: ---------- Forwarded message ---------- Date: Wed, 18 May 1994 15:59:44 -0700 (PDT) From: David Sternlight <strnlght(a)netcom.com> To: Netcom Support <support(a)netcom.com>, Brian Beker <beker(a)netcom.com> Subject: Patent infringement In tracking down slow response on netcom8, I discovered that user beker was idle for over 16 minutes, and since the timeout was supposed to be 12, I fingered him to see if he was a netcom staffer. I found his .plan file contained a PGP 2.3a key. That infringes RSADSI's patents. That this is so has recently been confirmed by an independent inquiry by lawyers retained by MIT. The patent holder, RSADSI, has said that no only do versions of PGP except the soon-to-be-released 2.6 and the commercially sold Viacrypt version 2.4 infringe in the U.S., but posted keys and key servers constitute inducement to infringe and/or conspiracy to infringe. Given netcom's new user agreement, I'm user user beker will want to correct this. David Login name: beker In real life: Brian Beker Directory: /u1/beker Shell: /bin/tcsh On since May 17 18:25:24 on ttyq2 from NETCOM-la5.netco 16 hours Idle Time Mail last read Wed May 18 14:59:25 1994 Plan: "Buddy when he come back from up in the panhandle told me one time it quit blowin up there and all the chickens fell over." Cormac McCarthy "All the Pretty Horses" ____________________________________________________________ | | | "LINES OF FIRE," the only film about heroin trafficking | | and revolution in Burma, shot entirely on location in | | rebel-held jungles, is available on homevideo from | | First Run Features in New York | | (212) 243-0600 | |____________________________________________________________| -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiy02ncAAAEEAMa9iYhxd2q8BViv0bpX6ktixk/v+T5LIQ41Scut8PhPRQKo SEDlP2bkIi4Spb6Tf10m6txDKwntj+tIrTlfkZOKawUUakW4MtqB4l84XI3nUlrB SpxiaaiCNe1ETtUr6/AMqo0JFJxz5iTLAzVzijXTxCn1NQRSByJejrfgN5yJAAUR tB5CcmlhbiBCZWtlciA8YmVrZXJAbmV0Y29tLmNvbT6JAJUCBRAs6UaSYIKGuWzM Fm0BAVFUA/4uPA3oQ4LRp1hJFa90pasXgD+Y6NfUt7IO1O1O1b2Vn21n1uhk4UZ0 gSAhOdog0a5E2bPECamlYy8XJR0cOXVQfWTL4ErmcGr2zMQNpNzoOU9UortJRa+d Lw922IEOB1bLdsINtuQOIG9k7NcWrBiYzdnznbrOkxJoXBHahuPjn4kAlQIFECzn LHlzoW8TKQHagQEBfYcD/1aioxIk0Fn/Ta5YLzP6+gLESwxh0xB0WIHYKjyQMPev WqfNplaSJI5SFSIBfb/clpACDljXy3/mY3+AaoKj0vNxxG40YDSdiQK3xM88yYFq nf65ybeQ5cDbuR1H15YaqArEKduw8/udMftXLZKo0N9YOPJ3g3iBXGgi33/ZitPe =7hh4 -----END PGP PUBLIC KEY BLOCK-----

1 0

DEF CON II Convention Update #7
by The Dark Tangent 17 Dec '03

17 Dec '03

Updated Last : 5.13.1994 Only two months to go! --> Updated sections will have a "*" next to them for easier location. --> New Speaking Schedule XXXXXXXXXXXXXXXXXXXXXXXX XX DEF CON II Convention Update Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX XX DEF CON II Convention Update Announcement XXXXXXxxxxxxXXXXXX X X DEF CON II Convention Update Announcement XXXXXxxxxxxxxXXXXXXX X DEF CON II Convention Update Announcement XXXXxxxxxxxxxxXXXX XXXXXXXXX DEF CON II Convention Update Announcement XXXxxxxxxxxxxxxXXXXXXXXXX X DEF CON II Convention Update Announcement XXxxxxxxxxxxxxxxXXXXXX XX X DEF CON II Convention Update Announcement XXXxxxxxxxxxxxxXXXXXXXX DEF CON II Convention Update Announcement XXXXxxxxxxxxxxXXXXXXXX X XX DEF CON II Convention Update Announcement XXXXXxxxxxxxxXXXXXXXXXX XX X DEF CON II Convention Update Announcement XXXXXXxxxxxxXXXXXXXXX X DEF CON II Convention Update Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX DEF CON II Convention Update Announcement XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX DEF CON II Convention Update Announcement READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBU =========================================================================== What's this? This is an updated announcement and invitation to DEF CON II, a convention for the "underground" elements of the computer culture. We try to target the (Fill in your favorite word here): Hackers, Phreaks, Hammies, Virii Coders, Programmers, Crackers, Cyberpunk Wannabees, Civil Liberties Groups, CypherPunks, Futurists, Artists, Etc.. WHO: You know who you are, you shady characters. WHAT: A convention for you to meet, party, and listen to some speeches that you would normally never hear. WHEN: July 22, 23, 24 - 1994 (Speaking on the 23rd and 24th) WHERE: Las Vegas, Nevada @ The Sahara Hotel So you heard about DEF CON I, and want to hit part II? You heard about the parties, the info discussed, the bizarre atmosphere of Las Vegas and want to check it out in person? Load up your laptop muffy, we're heading to Vegas! Here is what Three out of Three people said about last years convention: "DEF CON I, last week in Las Vegas, was both the strangest and the best computer event I have attended in years." -- Robert X. Cringely, Info World "Toto, I don't think we're at COMDEX anymore." -- CodeRipper, Gray Areas "Soon we were at the hotel going through the spoils: fax sheets, catalogs, bits of torn paper, a few McDonald's Dino-Meals and lots of coffee grounds. The documents disappeared in seconds." -- Gillian Newson, New Media Magazine DESCRIPTION Last year we held DEF CON I, which went over great, and this year we are planning on being bigger and better. We have expanded the number of speakers to included midnight tech talks and additional speaking on Sunday. We attempt to bring the underground into contact with "legitimate" speakers. Sure it's great to meet and party with fellow hackers, but besides that we try to provide information and speakers in a forum that can't be found at other conferences. While there is an initial concern that this is just another excuse for the evil hackers to party and wreak havoc, it's just not the case. People come to DEF CON for information and for making contacts. We strive to distinguish this convention from others in that respect. WHAT'S NEW THIS YEAR This year will be much larger and more organized (hopefully) than last year. We have a much larger meeting area, and have better name recognition. Because of this we will have more speakers on broader topics. Expect speaking to run Saturday and Sunday, ending around 5 p.m. Some of the new things expected include: > An Internet connection with sixteen ports will be there, _BUT_ will only provide serial connections because terminals are too hard to ship. So bring a laptop with communications software if you want to connect to the network. Thanks to cyberlink communications for the connection. The connection will be at least a 28.8kbps slip, and we are working with the hotel to try and set up a 56k line for the weekend. > There will be door prizes, and someone has already donated a Cell Phone and a few "Forbidden Subjects" CD ROMs to give away, thanks to Dead Addict. * People have decided to bring all types of cool old and new stuff to give away from ancient 300 acoustic modems to an oki 900 cell phone. Crazy! > Torquie (Remember her from last year?) will try and present the World Premier Showing of her Documentary of the computer underground, as shot in the United States and Europe. Should be a great show.. who knows, you might see someone you know. Editing is being done on the project now. > Dr. Ludwig will present his virus creation awards on Sunday. > A bigger and better "Spot The Fed" contest, which means more shirts to give away. Plus this year we can expect a newer and greater variety of Federal agents in attendance. Should be acronym alphabet soup! > More room, we should have tables set up for information distribution. If you have anything you want distributed, feel free to leave it on the designated tables. Yes, this year there will be a true 24 hour convention space. * Talk about more room! The Sahara moved us into "Room #1" (See uuencoded .gif floorplan in the follow up file) which has an unbelievable amount of space.. we're talking 750 people to 900 people. Should be plenty of space. We might try and partition a section off and show the movies there instead of having people run up to a movie suite elsewhere. > A 24 hour movie / video suite where we will be playing all types of stuff. VHS Format. Mail me with suggested titles to show, or bring your own. We'll use a wall projector when not in use by speakers. > Midnight Tech Talks on Friday and Saturday night to cover the more technical topics and leave the days free for more general discussions. * Friday night will be conspiracy night, along with a video conference dealing with unix and Internet security and an assembly programming workshop on twenty ways to trash a PC. * Saturday night will be a radio and cellular workshop night. WHO IS SPEAKING:============================================================= This list represents almost all of the speakers verified to date. Some people do not want to be announced until the event for various reasons, or are waiting for approval from employers. A speaking schedule will go out in the next announcement. Speaker, Who they are, Topic to be covered Philip Zimmerman, Notorious Cryptographer & Author of PGP. Keynote Address. Dr. Ludwig, Author of "The Little Black Book of Computer Viruses," and "Computer Viruses, Artificial Life and Evolution" Loyd Blankenship (The Mentor), Net Running in the 90's and RPG. Padgett Peterson, Anti-Virus Programmer, "What it's like to clean up other peoples messes" The Jackal, A Radio Communications Overview, Digital Radio and the Hack Angle. Judi Clark, Computer Professionals for Social Responsibility. Gail Thackery, (Of Operation Sun Devil Fame), Topic to be Announced. To be Announced, The Software Publishers Association, Topic to be Announced. Toni Ames, Ex US West Cellular Fraud, Cellular Fraud Topics. Mark, Cellular Enthusiast, Hacking Cell Phones. Lorax, The Lighter Side of VMBs. (Peter Shipley, UNIX Stud, Q&A on UNIX Security) George Smith, Crypt Newsletter, Virus Topic to be Announced. Cathy Compton, Attorney, Q&A Surrounding Seizure Issues, Etc. John Littman, Reporter and Author, Conspiracy 'stuff' Red Five & Hellbender, Madmen With a Camcorder, Who Knows? Erik Bloodaxe, Phrack Editor, Weird Wireless Psycho Shit.. Stay Tuned.. Curtis Karnow, Attorney, Legal issues surrounding encryption systems. * Mystery, UNIX god, UNIX Security stuff. (Video conference) * Mystery, Mystery, Cool toys. Torquie, Independent film producer from London, The European scene. ============================================================================= WHERE THIS THING IS: It's in Las Vegas, the town that never sleeps. Really. There are no clocks anywhere in an attempt to lull you into believing the day never ends. Talk about virtual reality, this place fits the bill with no clunky hardware. If you have a buzz you may never know the difference. It will be at the Sahara Hotel. Intel is as follows: We will be in "Room #1" in the upper level meeting space off of the Reception Mezzanine. The Sahara Hotel: 1.800.634.6078 Room Rates: Single/Double $55, Triple $65, Suite $120 (Usually $200) + 8% tax Additional rollaway beds (2 Max.) for $10 each. Transportation: Shuttles from the airport for cheap. NOTE: Please make it clear you are registering for the "DEFCON" convention to get the room rates. Our convention space price is based on how many people register. Register under a false name if it makes you feel better, 'cuz the more that register the better for my pocket book. No one under 21 can rent a room by themselves, so get your buddy who is 21 to rent for you and crash out. Try to contact people on the Interactive Mailing List (More on that below) and hook up with people. Don't let the hotel people get their hands on your baggage, or there is a mandatory $3 group baggage fee. Vegas has killer unions. * -> I have noticed that sometimes the hotel gets confused with people registering rooms, make sure they find the conference because we do exist there. FINAL DATE FOR REGISTERING FOR A ROOM IS JUNE 22 They have told me that normal hotel rooms are totally book for this time period (I guess it is the height of tourist season?) so if you plan on finding a room try to do it before the deadline. OTHER STUFF I'll whip up a list of stuff that's cool to check out in town there so if for some reason you leave the awesome conference you can take in some unreal sites in the city of true capitalism. If anyone lives in Las Vegas, I would appreciate it if you could send a list of some cool places to check out or where to go to see the best shows and I'll post it in the next announcement or in the program -> I am asking for people to submit to me any artwork, pictures, drawings, logos, etc. that they want me to try and include in this years program. I am trying to not violate any copyright laws, but want cool shit. Send me your art or whatever and I'll try and use it in the program, giving you credit for the work, of course. Please send it in .TIFF format if it has more than eight bit color. The program will be eight bit black and white, -> in case you want to make adjustments on your side. * Work has started on the program, try to get your stuff to me in the next month! PLEASE DONATE "STUFF" FOR THE GIVEAWAY: We are trying to raffle off interesting and old functional items. If you have anything such as old computers, modems, weird radio stuff, books, magazines, etc. that you want to get rid of, please call or mail me with what it is, or bring it along. I don't want to waste peoples time giving away rubber bands or anything, but pretty much anything else will go. ** Mailing List Server is dead, kaput, exit -1. I'm working on getting ** a commercial place to handle it for me so I can get it done quick. MEDIA: Some of the places you can look for information from last year include: New Media Magazine, September 1993 InfoWorld, 7-12-1993 and also 7-19-1993 by Robert X. Cringely Gray Areas Magazine, Vol. 2, #3 (Fall 1993) UNIX World, ???, Phrack #44, #45 COST: Cost is whatever you pay for a hotel room split however many ways, plus $15 if you preregister, or $30 at the door. This gets you a nifty 24 bit color name tag (We're gonna make it niftier this year) and your foot in the door. There are fast food places all over, and there is alcohol all over the place but the trick is to get it during a happy hour for maximum cheapness. The convention program will include some places to check out as suggested by several people who have spent time in the sin city. ============================================================================= Current Speaking Schedule (This will change with time) Times are in 24 hour format. Roughly 1/2 hour talks with 15 minutes of Q&A, Maximum of 50 minutes per speaker. FRIDAY, July 22 Convention room opens 09 on Friday 22-23 El1te video conference, UNIX security 23-24 Twenty Ways to trash a PC, assembly programming 24-01 Conspiracy Fest, the Inslaw affair (read up on it in the EFF 01-02 archives so you know what they are talking about.) SATURDAY, July 23 10-11 Welcome to the Convention!! Keynote Speaker Phil Zimmerman 11-12 Gail Thackery and Toni Ames 12-13 Kurt Karnow, The legal implications of encryption 13-14 Cathy Compton, 13-14 Judy Clark, CPSR, [These five speakers will be spread out over four hours (I hope)] 14-15 BREAK 15-16 BREAK 16-17 Theora, Privacy & Annonminity on the Internet, Round table discussion 17-18 Cool toy demo 18-19 The Jackal, Radio communications overview 19-20 Torquie, The European hacking community and 'scene' 20-21 BREAK 21-22 BREAK 22-23 BREAK 23-24 Erik Bloodaxe, Weird Wireless Psycho shit. CDPD, POGSAG, Etc. 24-01 Mark & friends, Cellular workshop (Oki 900 and 1150) 01-02 "" 02-03 "" SUNDAY, July 24 10-11 George Smith, Virus Topic TBA 11-12 Padgett Peterson, Anti Virus, Cleaning up after other peoples messes 12-13 Dr. Ludwig, Virus Creation Awards and what to do when the feds come 13-14 BREAK 14-15 ???, S.P.A. 15-16 Loyd Blankenship, Netrunning in the '90s and RPGs 16-17 Lorax, The lighter side of the "underworld" 17-18 Red Five and HellBender MONDAY, July 25 Convention room closes 8 am Monday ============================================================================= FOR MORE INFORMATION For Internet users, there is a DEF CON anonymous ftp site at cyberspace.com in /pub/defcon. There are digitized pictures, digitized speeches and text files with the latest up to date info available. The FTP site was nuked, and some files recovered. The missing files (Dan Farmers speech, some of the image files) are being uploaded again. For email users, you can email dtangent(a)defcon.org for more information. For non-net people call: ---- A L L I A N C E ---- SysOp Metalhead 612.251.8596 USRobotics 16.8 Dual Standard Synchronet Multinode BBS Software International Informational Retrieval Guild (IIRG) Distro Site Electronic Frontier Foundation (EFF) MEMBER American Bulletin Board Association (ABBA) MEMBER ----------------------------------------------------------------------------- o FidoNet [1:282/8004] o CyberCrime international [69:4612/2] o Computer Underground Magazines, History, Updates & Text o DEF CON Mirror Archive o uXu, PHANTASY, CuD, EFF Magazine(s) Distro Site ----------------------------------------------------------------------------- For Snail Mail and Pre-Registration send to: DEF CON, 2709 E. Madison Street Suite #102 Seattle, WA, 98112 Make Checks payable to DEF CON For Voice Mail and maybe a human (me), 0-700-TANGENT on an AT&T phone. A DEF CON Mailing list is maintained, and the latest announcements are mailed automatically to you. If you wish to be added to the list just send email to dtangent(a)defcon.org. STUFF TO SPEND YOUR MONEY ON > Tapes of last years speakers (four 90 minute tapes) are available for $20 > DEF CON I tee-shirts (white, large only) with large color logo on the front, and on the back the Fourth Amendment, past and present. This is shirt v 1.1 with no type-O's. These are $20, and sweatshirts are $25. > DEF CON II tee-shirts will be made in various colors this year, including a few long sleeve shirts. Sizes will be in XL only again, with few white larges made. Shirts will be $15, Long Sleeve $17, Sweat shirts will be $20. Well, actually, I'll make a small quantity of various stuff, so with luck * There will be two styles available in black, white, and a few mixed colors. > We will have a few embroidered hats and knit "hood hats" with this years logo. Not sure how much they will be.. like $15 maybe. Two Color Logo. > 4 color DEF CON II wall posters will be for sale for about $10 (Sorry for the incorrect estimate, but they cost more to print than my 'source' said) * We will try to have poster tubes there so you don't have to crush the posters > Pre-Register for DEF CON II in advance for $15. > Make all checks/money orders/etc. out to DEF CON, and mail to the address above. Way above. Above the virus awards announcement. If you have any confidential info to send, use this PGP key to encrypt: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCrAiyI6OcAAAEE8Mh1YApQOOfCZ8YGQ9BxrRNMbK8rP8xpFCm4W7S6Nqu4Uhpo dLfIfb/kEWDyLreM6ers4eEP6odZALTRvFdsoBGeAx0LUrbFhImxqtRsejMufWNf uZ9PtGD1yEtxwqh4CxxC8glNA9AFXBpjgAZ7eFvtOREYjYO6TH9sOdZSa8ahW7YQ hXatVxhlQqve99fY2J83D5z35rGddDV5azd9AAUTtCZUaGUgRGFyayBUYW5nZW50 IDxkdGFuZ2VudEBkZWZjb24ub3JnPg== =ko7s -----END PGP PUBLIC KEY BLOCK----- - The Dark Tangent ============================================================================= (Note, I have put a copy of Dr. Ludwig's new KOH Data security encryption Virus on-line at the DEF CON ftp site in /pub/defcon/KOH along with full documentation. Get CrAzY.) VIRUS CREATION AWARDS: Announcing The Second International Virus Writing Contest Sponsored by American Eagle Publications, Inc. P.O. Box 41401 Tucson, AZ 85717 USA and The Crypt Infosystems BBS +1 (818) 683-0854 *** The Goal *** The purpose of this contest is to write a fully functional computer virus that entertains people with political satire. Viruses will be judged on the basis of originality, creativity, functionality, and political incorrectness. *** Eligibility *** Anyone who can write a computer virus is eligible. *** Contest Dates *** The contest is underway from January 1, 1994 until June 30, 1994. Your submissions must be received by June 30 to qualify. The winner of the contest will be announced at the DEF CON II conference in Las Vegas, July 22-24, 1994. If you can be present, an official award will be bestowed on you at that time. ************************************************************* Details ************************************************************* The philosopher Friedrik Nietzsche once said that if you want to kill something, you must laugh at it--and laugh at it deeply. So there should be little wonder that political satire is as old as politics itself. Is there something going on in the political arena that you abhor, that makes you sick, that is just plain wrong? Well, here's your chance to make a mockery of it. I've always had this idea that if someone wrote a sufficiently witty virus that really addressed the issues the way the people (not the press, not the politicians) saw them, it might just get passed around by people voluntarily. Let's find out. Write a virus that is itself a political satire. I don't mean a virus that simply displays a message. I mean a living entity whose every move--whose every action--is politically motivated. If you need more than one virus to make your point--perhaps two viruses working together, or something like that, that is fine. ----------------------------------------------------------- Let me give you a simple example: The Political Correctness Virus This virus is a spoof on the "political correctness" movement--which is just a form of self-imposed censorship--that is sweeping American intellectual circles, particularly colleges and universities. This virus is a memory resident boot sector virus which maintains a list of politically incorrect words on your computer system. It also hooks the keyboard interrupt and monitors every keystroke you make. If you type a politically incorrect word into the computer, the PCV springs into action. Politically incorrect words are ranked at three different offense levels. When the PCV encounters such a word, it determines what offense level that word is, and acts accordingly. The least offensive words merely register a beep. More offensive words cause a beep to sound for 10 seconds. The most offensive words cause a siren to sound for two minutes, locking the system for that duration. If you turn the computer off before the two minutes are up, the virus will stop the boot process for five minutes, with sirens, when you turn it back on. If you allow the siren to complete, then you can proceed. The virus has two different word lists, both stored in an encrypted and compressed format. The list is selected at random when the system is infected, after which it cannot be changed. The first list is the "proper" list of political correctness no-no's. For example, a word like "sodomite" is among the worst possible offenses. The second list is an inverted list of no-no's. This list tries to force you to use "sodomite" by flagging words like "gay" and "homosexual" as no-no's. If you allow the PCV to live in your system for three months without getting a single flag, you are given the supreme honor of viewing the word list assigned to you and adding a word to it. If you get more than 3000 flags in a lifetime, the virus will force you to enter a politically correct word before allowing you to start the computer, since you are obviously unwilling to submit to its censorship. The virus also uses powerful means to prevent disinfection, so that, once you get it, you can't get rid of it without a major effort. ------------------------------------------------------------ Now, I know you can get a lot more creative than this--so do it! Design your virus carefully, so that everything it does has meaning. Then send it in. Here are the criteria we'll use: 1. Originality: Your virus must be an original work. Do not send us anything that is not 100% yours. Your message should be original too. Do not just ape what everybody else is saying, especially the media. Also, a refined wit is much to be preferred over vulgarity. Vulgarity is a substitute for original wit. Foul language, porn, etc., are out. Destructive features should be incorporated only if they are VERY appropriate (perhaps if you are commenting on real live genocide in your country, or something like that). In general, though, destructive features will hurt you, not help you. The one exception is modifying anti-virus programs. That is considered to be CONstructive activity. 2. Creativity: Make us laugh, make us cry. Amaze us with how bits and bytes can say something about politics and issues. Think of it like this: displaying a message on the screen is like reading a text file. What we want is the equivalent of a multi-media extravaganza. Use all the system's resources to tell your message. Don't be afraid to write a virus that has some weird mode of infecting programs that tells a story, or to write one that sends faxes to the White House, or sends an automatic request for reams of free information to some government agency. 3. Functionality: The virus has to work. If it only works on some machines, or under some versions of DOS, or what-not, then that will count against you. The better it is at infecting systems and moving around, the better off you will be. So, for example, if you write a file-infection, make sure it can jump directories, and--if you're up to it--migrate across a network. 4. Political incorrectness: Since computer viruses are politically incorrect, their message should be too. If you send us a pro-establishment virus, then you will not win this contest. A word to the wise: think twice about what's correct and what's not. Many positions are only superficially incorrect, though they are really quite fashionable among the establishment. Look at it this way: if you could get a well-written letter expressing your view published in a big city newspaper, then it's not sufficiently incorrect. There are a LOT of ideas that are unofficially censored by society-- especially the media and academia. They tend to make themselves out to be the rebels, but they are really the establishment. If you can't think of anything creatively incorrect and sufficiently obnoxious then you shouldn't be writing viruses in the first place. ************************************************************* How to Submit an Entry You may mail your entry to American Eagle Publications at the above address, or you may e-mail it to ameagle(a)mcimail.com. Alternatively, you can submit it by dialing the Crypt Infosystems BBS and uploading it there. To get on to the system quickly, efficiently and anonymously, log on as VIRUS, using the password CONTEST. An entry consists of: 1. A complete copy of your virus, both source and executable files. 2. If the political satire isn't perfectly obvious, send a verbal description of how the virus works and why it does what it does. This is especially important if you are not an American and you are commenting on something that has not received worldwide attention. I don't care if you're Bulgarian and you're commenting on something we've never heard of--just make sure you explain it, or we won't understand and you'll lose. 3. If you want to be recognized for your work, include your name (real or handle) and a way we can get in contact with you. By submitting an entry, you grant American Eagle Publications, Inc. the right to publish your virus in any form. You agree not to make your virus public prior to July 25, 1994. If you do, you are automatically disqualified from the contest. For the sake of privacy, you may encrypt your entry and send it in with the following PGP key (which we highly recommend if you have PGP): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAi09jVgAAAEEAN3M9LFQXeBprkZuKo5NtuMC+82qNd3/8saHLO6iuGe/eUai 8Vx7yqqpyLjZDGbAS7bvobrcY3IyFeu8PXG4T8sd+g81P0AY0PHUqxxPG3COvBfP oRd+79wB66YCTjKSwd3KVaC7WG/CyXDIX5W6KwCaGL/SFXqRChWdf2BGDUCRAAUR tApDT05URVNUXzk0 =Z20c -----END PGP PUBLIC KEY BLOCK----- Good luck! **************************************************************** P R I Z E S In addition to instant worldwide fame and recognition, you'll get: 1. A cash prize of $100 US. 2. A year's subscription to Computer Virus Developments Quarterly. 3. Your virus will be published in Computer Virus Developments Quarterly, and other fine journals. 4. A handsome engraved plaque recognizing your contribution to the betterment of mankind. 5. A free secret surprise that we cannot tell you about right now, valued at $100. Two runner-ups will receive the secret surprise. !! GO FOR IT !! =============================================================================

1 0

On Encrypted rlogin sessions
by nelson＠bolyard.wpd.sgi.com 17 Dec '03

17 Dec '03

Encrypting sessions of the Berkeley rlogin protocol is trickier than one might imagine. There's a "feature" of BSD sockets that can cause data to be delivered in a different order than was intended. The straightforward approach used in the Kerberos IV implementation of encrypted rlogin, krlogin -x, didn't address this problem, which is why krlogin sessions are sometimes terminated, suddenly and unexpectedly. This paper, which I wrote and submitted to the MIT kerberos bug list several years ago, explains the problem, and one solution that I implemented successfully in an encrypted rsh/rcp/rlogin product that was never marketed. I submit it here, for your edification and amusement. This paper is approximately 4 printed pages long. In my spare time, I'm trying to prepare a version of the protocol design documentation for that old product that can be released for publication. BACKGROUND: BSD sockets provides a feature known as "Out Of Band" (OOB) data transmission. It provides a way to send one byte of data in the TCP data stream that is separated from the data stream by the receiver and made available to the receiving program ahead of the rest of the received (and queued) data previously received. The OOB feature is implemented using a feature of the TCP protocol called the "urgent pointer", which was never intended for this use, and which doesn't always work as anticipated for this purpose. When OOB data is received, a signal (SIGURG) is sent to the receiver to let it know that "urgent" OOB data has been received. - - - - - (the old paper follows) - - - - - THE PROBLEM: The "Out Of Band" feature of BSD sockets, used by the rlogin programs, has a nasty and little-known behavior which I call "OOB creep-in". Normally, an OOB byte is sent, marked with the TCP urgent pointer, and is extracted from the incoming data stream when received at the destination system. However, under some somewhat-rare circumstances, an OOB byte can be received without being marked by the urgent pointer, and consequently the "out of Band" byte is delivered to the receiving program "in band", indistinguishable from the ordinary data stream. The OOB byte "creeps in" to the "in band" data stream. This behavior is documented (er, mentioned) in the BSD 4.3 tcp source code in "tcp_input.c": /* * Remove out of band data so doesn't get presented to user. * This can happen independent of advancing the URG pointer, * but if two URG's are pending at once, some out-of-band * data may creep in... ick. */ There are several ways this can happen, but the simplest scenario is this: 1. Sender sends a byte of OOB data. 2. A TCP segment with OOB data (urgent pointer) is sent. Call this segment A. 3. Sender sends more normal in-band data (this is optional). 4. Segment A is not received, due to CRC error, or dropped by gateway. 5. Sender sends another byte of OOB data. 6. A new TCP segment (segment B) with the new OOB data (new urgent pointer) is sent. Sender socket's urgent pointer now points at latest OOB byte, not the earlier one. 7. Sender's TCP retransmit timer fires, causing all sent but unacknowledged data (including all of segments A & B) to be retransmitted in a new segment, called segment C. In segment C, the urgent pointer points to the newest byte of urgent data, not to the OOB byte of segment A. So both the old and new bytes of OOB data are delivered but the urgent pointer only points to the latter one of them, the earlier OOB byte is not detected as being urgent or "out of band". The rlogin daemon uses OOB data to convey commands to the rlogin client, such as "enable XON-XOFF", "disable XON-XOFF", "return current window size" and "flush all received data". When an OOB byte "creeps in" (in an unencrypted rlogin session) it appears as a funny character on the rlogin user's screen. Some terminals display these as blanks, and very often these go unnoticed by users. When noticed, the user typically takes some trivial action to correct it; such as redoing the "ls" command, or typing "^L" to redraw the screen in vi. Unfortunately, for users of Kerberos krlogin -x, which encrypts the entire in-band data stream, the consequences of OOB creep-in are very noticeable, confusing (except to those who understand this phenomenon), and usually require the rlogin session to be restarted to correct the problem. The protocol used by "krlogin -x" sends all in-band data in blocks that look like this: | Length | encrypted data ... +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ... 4 bytes roundup(length,8) bytes where Length is a 32-bit integer sent in Network Byte Order, unencrypted, and is followed by roundup(length,8) [that's the smallest multiple of 8 that is no smaller than length] bytes of encrypted data. A view of an rlogin session would show a series of these blocks: ...xxxxxLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxx... OOB bytes are inserted in the data stream by TCP after (or before) a block and are normally removed before being received by the client. The actual TCP data stream, with OOB data shown, might look like: ...xxxxxBLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxxxxxxBLLLLxxxx... If such a data stream were to experience creep-in, the rlogin client, expecting: ...xxxxxLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxx... would actually receive: ...xxxxxBLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxxxxxxLLLLxxxx... Instead of receiving a legitimate length LLLL, the receiver gets an incorrect length BLLL. The receiver becomes "out of sync" with the sender. When this occurs, B is generally non-zero, and krlogin detects this condition because the resultant value of the 4-byte length field is out of range (too large). This error is reported by krlogin code (incorrectly) as End-Of-File on the TCP socket. This causes the "reader" process to terminate. The krlogin user experiences an unexpected termination of the session. There are other problems with OOB as it is used in rlogin. For example, even in "normal operation" (e.g. no retransmission of data) loss of OOB data occurs when the reader's system is slow and cannot process the first OOB byte before the second byte is received. That is, BSD code keeps only one byte of received OOB at a time, and if the first byte is not consumed by the receiving process before a second OOB byte arrives, the first byte is lost, overwritten by the second. SOLUTIONS: Several solutions to the creep-in problem exist. One solution, which (I am told) has been implemented in another UNIX workstation vendor's kernel, prevents creep in by preventing the transmission of a second OOB byte until the receipt of the first OOB byte has been acknowledged by the receiver. Thus two OOB bytes are prevented from being sent in the same TCP segment. This solution is not in general use, and I ruled it out for the code I was developing because I was looking for a solution that would run on a wide range of 4.3-based platforms, and not only on those featuring this fix. Also, this solution does not prevent loss of OOB data. Another potential solution completely eliminates the use of OOB in krlogin, using an in-band mechanism to send commands. For example, one could use the most significant byte of the length field to send the command bytes, instead of using OOB. Without the SIGURG signal however, the "flushwrite" function becomes rather untimely and useless. The solution I chose uses OOB for the benefit of the SIGURG signal, and the timely processing of flushes that it brings, but processes ALL the OOB data in-band, so none is ever lost. That solution was succesfully implemented in the code I developed. My programs did not suffer from creep-in; that is, users of my encyrypted rlogin program experienced the exact same behavior as experienced by users of ordinary rlogin. No loss of synchronization is caused by creep-in. Although the code in the product I developed is proprietary to SGI, I can outline the elements of the solution. If you're interested in this solution (or some variant) for Version 5 of Kerberos, much more detail can probably be supplied. 1. Use socket option SO_OOBINLINE. With this option, received OOB data generates a SIGURG, but is NOT removed from the data stream (remains in-band). 2. The entire data stream is encrypted, both in-band and OOB data. 3. Send the encrypted data exactly as done in unencrypted rlogin. That is, no length or padding data is added. The protocol is identical to unencrypted rlogin (after key exchange is performed), except that the data is all encrypted. 4. Use 64-bit Cipher Feedback (CFB) {en,de}cryption (see FIPS pub 81) instead of CBC or PCBC. The CFB method has several advantages: 1. text is {en,de}crypted one byte-at-a-time, so each byte of plaintext is {en,de}crypted immediately, yet the encryption algorithm is still used only once every 8 bytes. (little additional overhead) 2. No length data is sent. 3. There is no padding, yet it is very resistant to known-plaintext attack. 4. There is no media bandwidth overhead, the number of ciphertext bytes and plaintext bytes are identical. Disadvantages of this scheme: All received data must be buffered and decrypted, even that which is to be immediately flushed. The routines reader() and oob() are completely rewritten. Instead of a single buffer which is alternately read, then written; reader reads data into buffers which are put on a chain of buffers-to-be-written (to the tty). Reader reads data into these buffers until no more data is available to be read. Then it writes data from the chain of buffers-to-be-written until the chain is exhausted or until SIGURG occurs. Then it goes back to reading. OOB data is processed immediately as it is read. A command to flush data causes the chain of buffers-to-be-written to be freed. The oob() routine merely counts the OOB received, and causes writing (to the tty) to stop and reading (from the socket) to begin again. No reading and no longjmps are done in oob(). While this solution is too large a change to be considered a "bug fix" or "patch" to kerberos version 4, perhaps it can be considered as a new krlogin protocol for version 5. [It wasn't] Your feedback is solicited. -- Nelson Bolyard Multimedia Server Division Silicon Graphics, Inc. nelson(a)sgi.COM Phone: 415-390-1919 Fax: 415-967-8496 Disclaimer: I do not speak for Silicon Graphics. --

1 0

Forward of alt.security.pgp message
by Black Unicorn 17 Dec '03

17 Dec '03

I thought I would post this to try and spur some discussion. It is my reply to DS's bid for the security of centralized authority in key certification. In article <strnlghtCpzCqo.Jzr(a)netcom.com>, David Sternlight <david(a)sternlight.com> wrote: >In article <Cpz2HA.HAG.3(a)cs.cmu.edu>, >Rujith S DeSilva <rudis+(a)cs.cmu.edu> wrote: > >> >>Mr. Sternlight said that RIPEM can have signed messages in which the >>authenticity of the public-key can be assured in the same message, and that >>PGP cannot do so. >> >>Mr. Repenning's `one-word reply' was a PGP signed message in which the >>authenticity of the public-key was assured in the same message. >> > >Nope. His message simply provided his public key without any authentication >other than those he got to sign it. Since those are themselves not >authenticated except by the few who trust them, his public key is basically >unauthenticated. What he DID do is prove that the message was authenticated >with that public key. So what? > >Ripem provides a certificate in which a known Certification Authority (in >most cases RSADSI--eventually the Internet authorities themselves--vouches >for the sender's public key and one knows what standards have been applied >to prove identity. That public key is used to sign the message. Thus the >person is matched to his key and certified by a high-level-of-trust standard >certifier. That key then is used to authenticate the message. > >Putting it another way, I can't get an RSA Certificate without passing a >number of tests of my identity--for the Unaffiliated User Heirarchy that >involves proving to a Notary Public I'm me, with 3 pieces of ID including a >photo ID, and making that assertion under penalty of perjury. > >Thus the chances are pretty good I'm me and the key is mine. I dispute this. It is a simple matter to circumvent this requirement. If you would like to find three or four people on any given weekend who have the capacity to obtain a "trusted" certification in another name, or any name they wish, I suggest you try a college bar in Georgetown, or any other college area for that matter. Even passports are subject to sophisticated and fraudulant application. Your blind trust in the ability of perjury to deter is misplaced, and I might add, typical of your legal process way of approaching problems. All a centralized authority really accomplishes is to put a cap and a floor on the threshold to accept a given key as "valid" or that said keyholder's name really is "Bob Dwyer." PGP claims no such authority. PGP merely says: This is who has certified and vouched for the ownership of this key. Take my key signing policies. I will sign anothers key in two instances. 1> If a physical exchange of key materials is made by the key holder, and if that owner can prove access to the secret key. (Signed with my low security key) 2> If I personally know the keyholder and am aquainted in a context outside of the Internet, and the above criteria can be satisfied. (Signed with my highsecurity key) Which will you assert is the more reliable? A central authority that has never seen or heard of said applicant before? Or an authority who has known said applicant for months or even years outside of the internet, and in a personal capacity? (My method #2) Until every man, woman, and teen has a smart national ID card based on fingerprints or retina scan or DNA sampling, centralized authority is really a limiter, and in many cases a deceptive appearance of "secure" certification. (I might add that these methods are unacceptable to me for other reasons). In fact, should you be willing to wager a sufficant amount, and assure my non-prosecution for perjury, I would be pleased to demonstrate the ability to circumvent the centralized procedure in whatever reasonable protocol you would like. Provided I have an individual who I trust to sign keys only of those he knows, the only way to circumvent my PGP authentication requirements is to physically intercept the secret key and break the passphrase, or to resort to rubber hose cryptoanalysis. A tactic that is likely to cause key revocation in any event. >With PGP one >makes up a key, finds someone or other to sign it, and unless the signers >are both known and trusted by every reader, one has nothing. RSA IS known to >every reader and their safeguards are published. So what you really have is the potential for untrusted signatures to be given in PGP. So? How is this a limiter to the user who is careful enough to screen the keys properly? A centralized key signor authority is merely laziness. It is a method forwarded by those who are too sloth to take security in their own hands and wish to have it instead provided for them. This is why PGP is often criticized: Users are simply too lazy to look out for themselves. The answer is to limit everyone. Typical American policy, shoot for the average every time. You don't need to learn how to drive, we'll just make the speed limit safe for any idiot. You don't need to know how to brake, we'll just invent ABS. You don't need to take responsibility for your own security, we'll just invent a mediocre standard to do it for you. >Until PGP has some trusted official signers with high security certification >device protection and identity safeguards, the level of authentication is >its weakest element. No, until users pay more attention to what really is a "high security certification." authentication is its weakest element FOR THOSE USERS. When users really take extensive steps to certify, a certification is MORE secure than a centralized authority. I'm going to trust my million dollar transaction to a trusted friends transaction way before I trust what amounts to the Department of Motor Vehicles' assurance of identity. >By the way, in his example he did it wrong. First public key, then signature >or the poor reader has to invoke PGP twice. And this is a good clue perhaps on his signing procedures and caution in methodology. >David -uni- (Dark) -- 073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est 6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa - wichtig!

2 1

Mosaic to support digital money in September
by jamesd＠netcom.com 17 Dec '03

17 Dec '03

I have only recently resubscribed to cypherpunks, so forgive me if this is old news. Enterprise Integration Technologies and friends will enable digital money transactions in Mosaic in September (they hope, I would guess January 1995 before it really works.) Press release follows after my commentary. The transaction model has a crippled mode for people outside the US and Canada They intend that you will be able to write contracts and internet checks on participating banks. It is very centralized of course, but don't whine - it is the thin edge of the wedge. Once American banks are on the internet, Swiss banks will follow. The model uses account based digital money. It is overly centralized, but it is an excellent step towards a decentralized system of digital money. The cypherpunks are experimenting with digital token based money. Digital token based money is damn inconvenient, and each digital token currency requires a single centralized server which tends to monopoly and is thus highly vulnerable to government coercion. Although the server does not know which of its clients has been transacting with which, it does know the thing that the government is most interested in knowing - how much the client got, and how much he spent. For this reason I think decentralized account based digital money is the best hope. The following press release was posted on the CIS forum INETFORUM Quote begins: __________________________________________________________- #: 11559 S1/General Information [INETFORU] 14-Apr-94 04:12:28 Sb: PR:EIT/NCSA/RSA Fm: Scott Loftesness 76703,407 To: All [from an EIT/NCSA/RSA press release] Enterprise Integration Technologies (EIT), the National Center for Supercomputing Applications (NCSA) at the University of Illinois and RSA Data Security have announced agreements to jointly develop and distribute a secure version of NCSA Mosaic, the popular point-and-click interface that enables easy access to thousands of multimedia information services on the Internet. The announcement was made in conjunction with the launch of CommerceNet, a large-scale market trial of electronic commerce on the Internet. Under the agreements, EIT will integrate its Secure-HTTP software with public key cryptography from RSA into NCSA Mosaic Clients and World Wide Web (WWW) servers. WWW is a general-purpose architecture for information retrieval comprised of thousands of computers and servers that is available to anyone on Internet. The enhancements will then be made available to NCSA for widespread public distribution and commercial licensing. Jay M. Tenenbaum, chief executive officer of EIT, believes secure NCSA Mosaic will help unleash the commercial potential of the Internet by enabling buyers and sellers to meet spontaneously and transact business. "While NCSA Mosaic makes it possible to browse multimedia catalogs, view product videos, and fill out order forms, there is currently no commercially safe way to consummate a sale," said Tenenbaum. "With public key cryptography, however, one can authenticate the identity of trading partners so that access to sensitive information can be properly accounted for." This secure version of NCSA Mosaic allows users to affix digital signatures which cannot be repudiated and time stamps to contracts so that they become legally binding and auditable. In addition, sensitive information such as credit card numbers and bid amounts can be securely exchanged under encryption. Together, these capabilities provide the foundation for a broad range of financial services, including the network equivalents of credit and debit cards, letters of credit and checks. In short, such secure WWW software enables all users to safely transact day-to-day business involving even their most valuable information on the Internet. According to Joseph Hardin, director of the NCSA group that developed NCSA Mosaic, over 50,000 copies of the interface software are being downloaded monthly from NCSA's public server - with over 300,000 copies to date. Moreover, five companies have signed license agreements with NCSA and announced plans to release commercial products based on NCSA Mosaic. "This large and rapidly growing installed base represents a vast, untapped marketplace," said Hardin. "The availability of a secure version of NCSA Mosaic establishes a valid framework for companies to immediately begin large-scale commerce on the Internet." Jim Bidzos, president of RSA, sees the agreement as the beginning of a new era in electronic commerce, where companies routinely transact business over public networks. "RSA is proud to provide the enabling public key software technology and will make it available on a royalty-free basis for inclusion in NCSA's public distribution of NCSA Mosaic," said Bidzos. "RSA and EIT will work together to develop attractive licensing programs for commercial use of public key technology in WWW servers." At the CommerceNet launch, Allan M. Schiffman, chief technical officer of EIT, demonstrated a working prototype of secure NCSA Mosaic, along with a companion product that provides for a secure WWW server. The prototype was implemented using RSA's TIPEM toolkit. "In integrating public key cryptography into NCSA Mosaic, we took great pains to hide the intricacies and preserve the simplicity and intuitive nature of NCSA Mosaic," explained Schiffman. Any user that is familiar with NCSA Mosaic should be able to understand and use the software's new security features. Immediately to the left of NCSA's familiar spinning globe icon, a second icon has been inserted that is designed to resemble a piece of yellow paper. When a document is signed, a red seal appears at the bottom of the paper, which the user can click on to see the public key certificates of the signer and issuing agencies. When an arriving document is encrypted, the paper folds into a closed envelope, signifying that its formation is hidden from prying eyes. When the user fills out a form containing sensitive information, there is a "secure send" button that will encrypt it prior to transmission. To effectively employ public-key cryptography, an infrastructure must be created to certify and standardize the usage of public key certificates. CommerceNet will certify public keys on behalf of member companies, and will also authorize third parties such as banks, public agencies and industry consortia to issue keys. Such keys will often serve as credentials, for example, identifying someone as a customer of a bank, with a guaranteed credit line. Significantly, all of the transactions involved in doing routine purchases from a catalog can be accomplished without requiring buyers to obtain public keys. Using only the server's public key, the buyer can authenticate the identity of the seller, and transmit credit card information securely by encrypting it under the seller's public key. Because there are fewer servers than clients, public key administration issues are greatly simplified. To successfully combine simplicity of operation and key administration functions with a high level of security that can be accessible to even non-sophisticated users, significant changes were necessary for existing WWW security protocols. EIT developed a new protocol called Secure-HTTP for dealing with a full range of modern cryptographic algorithms and systems in the Web. Secure-HTTP enables incorporation of a variety of cryptographic standards, including, but not limited to, RSA's PKCS-7, and Internet Privacy Enhanced Mail (PEM), and supports maximal interoperation between clients and servers using different cryptographic algorithms. Cryptosystem and signature system interoperation is particularly useful between U.S. residents and non-U.S. residents, where the non-U.S. residents may have to use weaker 40-bit keys in conjunction with RSA's RC2 and RC4 variable keysize ciphers. EIT intends to publish Secure-HTTP as an Internet standard, and work with others in the WWW community to create a standard that will encourage using the Web for a wide variety of commercial transactions. EIT will make Secure NCSA Mosaic software available at no charge to CommerceNet members in September and NCSA will incorporate these securefeatures in future NCSA Mosaic releases. Enterprise Integration Technologies Corp., of Palo Alto, (EIT), is an R&D and consulting organization, developing software and services that help companies do business on the Internet. EIT is also project manager of CommerceNet. The National Center for Supercomputing Applications (NCSA), developer of the Mosaic hypermedia browser based at the University of Illinois in Champaign, Ill., is pursuing a wide variety of software projects aimed at making the Internet more useful and easier to use. RSA Data Security Inc., Redwood City, Calif., invented Public Key Cryptography and performs basic research and development in the cryptographic sciences. RSA markets software that facilitates the integration of their technology into applications. _____________________________________________________________________ Quote ends. This press release was transferred from Compuserve to internet by Owen Morgan (omorgan(a)cix.compulink.co.uk) --------------------------------------------------------------------- | We have the right to defend ourselves and our James A. Donald | property, because of the kind of animals that we | are. True law derives from this right, not from jamesd(a)netcom.com | the arbitrary power of the omnipotent state.

2 1

Identity, anonymity and reputations
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

I'll bother you all yet again with an episode of my column. This one's on identity, anonymity and reputations. I haven't seen any article on this for the lay reader; I'd appreciate info on any such articles. Electric Dreams Weekly column for The Asian Age by Rishab Aiyer Ghosh #12, 16/May/1994: I e-mail, therefore I am When you read what I write, do you know whether I exist? Do you know who I am? Do I know who I am? Well, you know my name. You assume that I am a real person of that name, and that someone at this newspaper has contact with me. (In fact I file my column electronically, though I admit to have been seen on occasion!) Despite technological advances, people still start professional (or other) relationships after acquiring verifiable identification -- an address, a bank account, a face. What would happen in cyberspace, where people may be far apart geographically, and identities less rigid and secure? Electronic identities as widely used, are limited to e-mail addresses. As with a physical address, an e-mail address provides a way to contact an individual. Like the postmark stamped on tree- murdering paper envelopes, e-mail headers generally indicate that a message has, indeed, come from a particular address and hence a particular person. Unfortunately these headers are easily forged. Not only can someone pretend to be me, I can pretend to be someone who doesn't exist! Cybernauts see two issues here. The inherent insecurity of cyberspace, which makes normal interactions unreliable, is a lapse that demands attention. On the other hand, the amorphous nature of identity that the Net encourages is actually a Good Thing, balancing the ease with which privacy can be violated, and making the advantages of an information society apparent. There are a number of ways to ensure distinct identities. That is, to ensure that Rishab Ghosh who writes this column is the author of the previous episode. Digital signatures are secure, backed by the arcane mathematics that proves the difficulty of factoring large numbers. A digital signature is a very large number, correlating the signed data with other publicly available numbers that define an individual's identity. Though these identifying numbers are public, a signature cannot be forged, as it also depends on a private key kept secret by the individual. Similar methods can be used by anyone to send encrypted messages that can be read only by the intended recipient. There -- now I have an electronic identity. You might have noticed, though, that there is no link at all between an identity in cyberspace and any physical (real?) one. I could plausibly have multiple identities, for different purposes, conducting public arguments with each other. Which brings us to the Good Thing. There's no reason why I shouldn't write columns as Rishab Ghosh and poetry as Alfred Prufrock, while living the rest of my life as John Doe. I might have to, lest evil marketing managers monitor all my public actions and learn more about me than I do. To formalize this separation of identities, cybernauts have created services known as anonymous remailers, which accept conventional e-mail and repost them, shorn of all their direct identifying marks -- addresses, names and so on. It is up to the poster to create pseudonymous identities using signatures and other methods. There are varying degrees of anonymity provided; with many services it is even possible to reply to anonymous mail without knowing a 'real' e-mail address. This sort of anonymity might primarily be used for privacy -- from consumer surveys, cloak-and-dagger maniacs, and other assorted net pests. In an ideal world, we would be free to say what we like; till we are, anonymity allows us some freedom to express without reprisal. This freedom is already being taken advantage of; in Internet news groups such as alt.sexual.abuse.recovery, for instance, victims can comfort each other in public electronic gatherings without the risk of public exposure. As with any technological advance, anonymity can be abused. While 'whistle blowing' might be the right thing to do sometimes, there is no way to be compensated for anonymous defamation. Attempts are being made towards a system of reputations, where people would gradually build (or ruin) a reputation for their identities, as their posts are tested by time. A totally anonymous accusation will of course have a very low reputation. Reputation systems will not end identity abuse. Hopefully, as people depend on them to be taken seriously, and unsubstantiated accusations are taken with large helpings of salt, we will enter a more tolerant society, that concentrates on the expressions rather than the expressor. Rishab Aiyer Ghosh is a freelance technology consultant and writer. You can reach him through voice mail (+91 11 3760335) or e-mail (rishab(a)dxm.ernet.in) -------------------------------------------------------------------------- Rishab Aiyer Ghosh rishab(a)dxm.ernet.in Voicemail +91 11 3760335; Vox/Fax/Data 6853410 H-34C Saket New Delhi 110017 INDIA The National Short-Sleeved Shirt Association says: Support your right to bare arms! --------------------------------------------------------------------------

1 0

Re: Patent infringement (fwd)
by Hal 17 Dec '03

17 Dec '03

From: Brian Beker <beker(a)netcom.com> > From: David Sternlight <strnlght(a)netcom.com> > I found his .plan file contained a PGP 2.3a key. That infringes RSADSI's > patents. That this is so has recently been confirmed by an independent > inquiry by lawyers retained by MIT. > > The patent holder, RSADSI, has said that no only do versions of PGP except the > soon-to-be-released 2.6 and the commercially sold Viacrypt version 2.4 > infringe in the U.S., but posted keys and key servers constitute inducement > to infringe and/or conspiracy to infringe. This is the argument Schiller's message on 2.6 foreshadowed. However, there are some counterarguments you can make: - It's not clear that RSADSI has actually said that merely posting a key with the words "Version: 2.3a" in and of itself constitutes inducement or conspiracy to infringe the patent. Schiller speculated that running a key server which accepted pre-2.4 keys could represent contributory infringement but I haven't seen any statements from Bidzos that agree with this, let alone the stronger statement Sternlight is making. - Just because the key says "Version: 2.3a" doesn't mean much. This version string is appended by the program which turned the key into ASCII format. It says nothing about the version of the program which used the RSA algorithm. Granted, in practice this suggests that the key was extracted from a key ring using PGP 2.3a, but extracting from a key ring is not a patented process. Only communicating using RSA is patented. The mere existence of this key does not show that patent infringement is going on. - Possession of a 2.3a key does not necessarily constitute inducement to infringe the patent. Perfectly legal programs exist which will work very well with a 2.3a key (versions 2.4 and up). So by possessing a key labelled 2.3a you are not inducing others to violate anyone's patents. - In any case, Sternlight does not have any standing in making this charge. He is not a lawyer and is not affiliated with RSADSI in any way. At best his reports are second- or third-hand interpretations of his understanding of RSADSI's position. Unless or until the patent holder speaks directly to make these charges, there is no need to respond. Hal Finney hfinney(a)shell.portal.com

4 3

Re: NSA's Baker to debate key escrow live on AOL, May 26
by nelson＠crynwr.com 17 Dec '03

17 Dec '03

Date: Thu, 19 May 1994 03:03:31 -0700 From: Phil Karn <karn(a)unix.ka9q.ampr.org> In article <NELSON.94May14232954(a)crynwr.crynwr.com>, you write: |> I've heard Baker. He's not particularly articulate, especially when |> confronted by another lawyer (viz Karl Auerbach at Interop). He tends I missed that session, opting to head for the airport before the rush. What exactly did Auerbach say? Sorry I missed the fun. I missed it too, so I bought the tapes. This is transcribed from the tape of the Networld+Interop "The Clipper Chip Controversy" debate between Baker of the NSA and Weitzman of the EFF. Karl Auerbach was the first questioner: Auerbach: Okay, well, my name is Karl Auerbach, and first a calibration tone. I grew up reading the cases of Sacco and Vanzetti, and Julius and Ethel Rosenberg, and I remember Kent State, and things like that. So, do I trust my government? No. Certain things. First, a technical question. You said that you sent the chip off to the national labs for reverse engineering. Did anyone sent it to Taiwan? <audience chuckles> Next thing. Baker: Are these all going to be hypothetical? A: Did you really try giving it to the experts? I mean, is it really reasonable to expect that someone isn't going to try to reverse engineer this thing? B: I think it's quite reasonable to buy devices with the chip in it and sent it to whomever you'd like. I don't necessarily believe that I share your belief that you know who has the best technology for doing this because the people at the national labs get to practice against someone besides Intel and Motorola. <audience chuckles> Just a response, Karl. A: I'd like to see them have a try. Anyway, getting more to the legal matters, If I have a clipper phone, it's used by lots of people. And, does that increase the expectation of privacy which is recognized by the supreme court and what happens to other people -- are we going to enact parallel legislation that restricts the further use of just ancillary conversations on the phone by a third party. To make this work, we're going to have to enact legislation that prohibits the use of superencryption like pgp. Are we going to do that? And also B: NO! A: And also, are we going to allow PGP then? And we're going to superencrypt it. So that means that your total system is dead. B: <splutter> I have to ask myself, what is the value to you of superencrypting? A: So you can't read it! B: Yeah, that's right <audience laughs, applauds> Of course, but A: If you want to do police work, get the police to find the key that the pedophile used to encrypt his file. Get your warrant to look for that key. He kept it somewhere. It was just sloppy police work that didn't get the key he's got somewhere <audience applauds>. And I don't know what piece of information you had that led you to know that that encrypted file had what you thought was in it. Can you point, can you specifically articulate reasons that would give you probably cause to think that that information was in those files? And I might remind you, the Supreme Court requires that. <audience murmurs, whistles, claps> B: I'm trying to figure out which of your points to address first. Let me start with the suggestion that superencryption somehow makes this pointless. I agree that if the government said that the only kind of encryption you can use is clipper, that superencryption would be a way of evading some kind of enforcement mechanism designed to ensure that only clipper encryption was on the system. A: So if I use PGP then you'll have probable cause to get a warrant? B: No. First, there's no suggestion, hasn't been a suggestion, you've got denials left and right, that this is going to be a required system. If it's not a required system, what's the point of adding PGP to clipper? You can encrypt with PGP if you want to, and you get whatever strength PGP gives you. You add to that clipper and the government has probably cause to decrypt your clipper conversations, what you have is a single PGP-encrypted conversation, which is as good as not having bothered going through the clipper encryption at all. A: No, what I was expecting was that you're going to make the argument that if we've got clipper, and we find that someone is using PGP in addition to clipper, that therefore they've got something to hide, and we'd better go after them. B: Yeah, I think that's a paranoid suggestion. A: Well, I'm paranoid, but the government... <baker chuckles> And the other thing is, we saw an earlier slide that says that this will only be available to the federal government. Now, if my statistics memory is right, most criminals are investigated by state governments. So is this somehow, what's going to happen with the states? Are they going to have access to this, or are we going to create more magistrates? Are we going to deputize all the local police as federal agents? B: About 37 states have wiretap authority. If they encounter A: So the first slide lied. B: I don't think so. A: So those state police are now federal employees. So this is more than federal wiretapping, this is state wiretapping as well then? And I bet there's far more, how many state wiretaps are there per year? B: I think the 900 includes that. And the wiretapping proceeds in this country pursuant to federal law. It's regulated by federal law even when it's done by state authorities. That, probably, is the answer to the other point you had suggested, which is that we need some special law to protect third parties who might have conversations with people. In fact, there are already requirements on the books that, after all, if you're conducting a wiretap, of John Gotti, you're always going to get two people in those conversations. There's not much point in wiretapping him when he's not talking to somebody. Consequently, if he calls somebody to order pizza, or if his daughter orders pizza, or talks to her friends, there are already legal requirements that you cease the recording of those conversations when they're plainly not related to the crime. A: And finally in respect to the escrows, since this is personally identifiable information, I assume that under the privacy act, I have access to it. <someone else>: Karl, it's not personally identifiable in the sense that what the escrow agents maintain is a chip id and an encryption key and there is not a mapping maintained in the system in general, at any point, of who bought which device with chip id, so if that's what you were referring to, I don't think it qualifies as you described it. <someone else yet>: Let me just add that unfortunately there's a law enforcement exception to the privacy act, so I think it's an interesting question whether it is personally identifiable or not, but either way, there is an exception for on ongoing investigation. I heard somebody made a good crack to Baker about how he must have worked for the tobacco companies. Was that Auerbach? No, that was the person who spoke after him. It was "Mr. Baker, I just have a very simple question about your position on all this. Do you ever feel like a cigarette industry executive?" <audience laughs, applauds> B: Let me turn that around a little, and I'll ask that about the EFF. I wonder whether they don't ever feel like the NRA, because in fact, <audience laughs> the analysis we hear of this issue, and the stuff, you've all heard it, "they'll get my crypto key when they pry it from my dead, cold fingers". All that stuff is a deliberate invocation of the same kind of analysis that gave us the gun policy that we have in this country. And so I guess if you like the gun policy that the NRA gave us, I think you're going to love the privacy consequences of the policies that the EFF is urging on us. <other>: Isn't that what the United States Constitution says, though? B: <splutter> I don't think the constitution requires either of these things. etc. -russ <nelson(a)crynwr.com> ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

2 1

Re: Mosaic to support digital money in September
by Hal 17 Dec '03

17 Dec '03

From: jamesd(a)netcom.com (James A. Donald) > The model uses account based digital money. It is overly > centralized, but it is an excellent step towards a > decentralized system of digital money. > > The cypherpunks are experimenting with digital token based > money. Digital token based money is damn inconvenient, > and each digital token currency requires a single > centralized server which tends to monopoly and is thus > highly vulnerable to government coercion. Although the > server does not know which of its clients has been > transacting with which, it does know the thing that the > government is most interested in knowing - how much the > client got, and how much he spent. > > For this reason I think decentralized account based > digital money is the best hope. I don't know to what extent this system represents "account based digital money". It doesn't sound that different from emailing your credit card number, something you can do already using PEM or PGP2.4. I suppose you will have digital checks with this system as well. But all of these systems will allow total tracking of your transactions by the banks. The digital cash systems we have been experimenting with do not know "how much the client got, and how much he spent." There is nothing stopping a given holder of Magic Money cash from being anonymous to the bank. He does not have an "account" with the bank. (The structure of the client interface is somewhat misleading in this regard - the user has to go through an initialization step in which he communicates with the bank, and it might appear that he is in some sense registering or opening an account. Actually, he is just grabbing an information packet which shows the current exponent-to-cash-value mapping.) In a (hypothetical) "mature" Magic Money system, people could exchange cash tokens issued by a number of banks using anonymous networks to communicate with each other and the banks. There is no need to trust the bank's circumspection or immunity to political pressure to preserve your privacy. Hal

2 2

Re: AOL for Acronym OverLoading
by fnerd＠smds.com 17 Dec '03

17 Dec '03

And the current worst AOL (acronym overload): ATM Network -- Automatic Teller Machine, Asynchronous Transfer Mode Recently saw an employment ad for an "ATM Network Administrator". The whole job description was ambiguous ("you will oversee the operation of our ATM network...") until you got to the name of the company. -fnerd - - - - - - - - - - - - - - - To auditors without the code, calls seem indistinguishable from noise. --George Gilder -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

4 3

Re: David Sternlight's Slurs About Folks With "2.3a" Keys
by strnlght＠netcom.com 17 Dec '03

17 Dec '03

By publishing a private e-mail, both beker and Johnson are in violation of my copyright in that message, since it was a private communication and no permission was given to republish. Thus beker has now committed a new violation of his netcom agreement, and Johnson shows he has bad judgement. What's more, by trying to make what should be a private matter, to be decided by netcom based on their own rules, into a public cause celebre, and by writing to netcom as Johnson did to intervene in a private matter, he has made the situation worse for beker, not better. Netcom is perfectly capable of telling me to go peddle my papers if I'm wrong. Complaining against another user to netcom is with netcom's rules. I am, of course, content to rely on netcom's decision in these two matters. The behavior of officious intermeddlers like Johnson speaks for itself. By the way, I sent a copy of my complaint to beker at netcom support's own suggestion, in fairness to him. beker's abuse of that courtesy private e-mail means he has given up any chance of getting such courtesies from me in future. David

1 0

Re: Patent infringement (fwd)
by peb＠netcom.com 17 Dec '03

17 Dec '03

I don't see how having a key on netcom is a problem; the key itself cannot infringe on a patent. Paul E. Baclace peb(a)netcom.com

1 0

ANNOUNCE: Bay Area physical meeting May 21.
by hughes＠ah.com 17 Dec '03

17 Dec '03

ANNOUNCEMENT ============ SAME cypherpunks time! NEW cypherpunks channel! (er, location) What: Bay Area physical cypherpunks meeting When: May 21, 1994 12:00 noon - 6:00 p.m. Where: Silicon Graphics, Mountain View, CA Building 5, SGI cafeteria, aka Cafe Iris Many thanks to Katy Kislitzin for arranging us a new and larger meeting space. With Cygnus meetings averaging 40-50 people each month, we'd just plain run out of space in their small conference room. And many thanks to John Gilmore for the well-used Cygnus room. We'll be in Cafe Iris, with 75 seats and plenty of A/V equipment. There will be full MBONE support, including video. We'll have a camera, so those who want to broadcast their likenesses to the whole world will have the opportunity. The MBONE session has been advertised on 'sd' already. The New York Times magazine is doing a story on us, and a photographer will be there to take a group photo, last I heard. This month's theme is Protocols. We'll be doing protocols and other technical cryptography. Here's what's known to be on the schedule right now: -- Arthur Abraham. Broadband subliminal channel in the DSA -- Eric Hughes. Narrowband subliminal channel in the DSA These two will be presenting work by Gus Simmons on the various subliminal channels in the Digital Signature Algorithm, based on a pair of papers presented last year. Folks can prepare for these presentations by reading Schneier's _Applied Cryptography_, p. 300 and following, on El Gamal signatures, Schnorr signatures, and the DSA. -- Eric Blossom. Secure telephony Eric is working on a hardware-based secure telephone, similar to the clipper-ized AT&T secure phone. He will be discussing details of the protocols, not all cryptographic, required for implementation. -- the usual contributions from the attendees See you all there! Eric ----------------------------------------------------------------------------- [Thanks to Katy Kislitzin for directions--EH] Place: Silicon Graphics, Inc. Building 5 (SGI Cafeteria) 2025 North Shoreline Boulevard Mountain View From 101 take Shoreline East. Turn right onto Steirlin Court at the big red metal sculpture. Go almost to the end, and building 5 is on the right.

1 0