December 2003 - cypherpunks-legacy

Coming to a newsserver near you alt.defeat.s314
by nobody＠tower.techwood.org 17 Dec '03

17 Dec '03

Psychic Flash...This group will be up on auto-subscribing news server's VERY soon.

2 1

S.314 on Web
by Richard Martin 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The text of S.314 (the pi bill, as Doug pointed out to me earlier today -- why I didn't realise earlier...) is available at http://baldric.resnet.cornell.edu/frodo/s.314.txt.html with a rapidly hypertextified version of Slowdog's text on what the bill will do to American law at http://baldric.resnet.cornell.edu/frodo/s.314.changes.html If there are errors or omissions, please tell me. If the URLs are wrong, the failsafe is my homepage, http://baldric.resnet.cornell.edu/frodo/frodo.html which has links to both. (Really. They're there. There's some bumf about me. But the links are there.) This may be useful to some. I find it handier to have it there than in an odd text file lying around here. frodo =) Richard Martin ChemPhysCompSci 9T7+PEY = 9T8 g4frodo(a)cdf.toronto.edu Trinity College University of Toronto SVW92 martinrd(a)gpu.utcc.toronto.edu My opinions, when not poached. (or fried) frodo(a)uhura.trinity.toronto.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBLzqwH6+lG3+zwTCVAQEGfwP+MOSWEAB2kbbabdai/y3o6QIDIWNefRle UPTCVyqadfIIs7s8bJjymlJs/OCutm76Pdfst8U40Tpi4DcE6NGyuLe9TauHkQEf +wFtgOYrju35YV/pdiXvIBmdnv8etthbtLA+b0KcaRVEKXVYP2NsZ7+WBT/gAVV1 XPbBwe1UJXw= =kaQ8 -----END PGP SIGNATURE-----

1 0

Re: S314 and potential hell-raising
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

>What other kind of responce other than no compromise should be entertained? Very much agreed. In this type of situation there is no room for compromise. If we compromise, we lose, thus my earlier snipy comment about EFF. They compromised and lost. We cannot do this now, we must win this or it starts going downhill from here. _____________________________________ {-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-} {-: www server: http://josaiah.sewanee.edu/ :-} {-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-} PGP block.

1 0

Re: MIME based remailing commands
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

>Nathaniel Borenstein <nsb(a)nsb.fv.com> writes: > >>Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co.. >>"Perry E. Metzger"@imsi. (2553) > >>> > > It is being remailed via a MIME-based structure where two new >>>content types >>> > > are defined: multipart/remail and application/remail-commands. The >>> > > multipart/remail type is supposed to be composed of two parts, the >>> > > application/remail-commands part which has remailer commands, and the >>> > > other part which is the "payload" to be remailed. > >>Perhaps you might consider writing up an informational RFC to define >>these types? I think that would be very useful. -- Nathaniel > >Well, that was just an example; I was making those names up off the top >of my head in order to concretize what I understood Perry was suggesting. > >I can see that putting remailer commands into a specific part of a MIME >multipart message has some advantages. Right now we are basically >having the remailing commands be mail header fields. But really people >aren't supposed to just make up new fields like that. I think the >"name space" of these fields is protected somewhat more than many other >aspects of communication protocols on the net. Is there precedent for >adding service-by-mail functionality in this way? I am not completely >comfortable with it. And as we think of new functionality and new >commands they all have to get added at this top level, the same >visibility and name space as "Subject", "From", and "To". > >OTOH it does have the advantage that it is easy to do, at least with the >"::" pasting token idea (which perhaps would need to be documented in its >own right). > >If we did use a separate message part we'd have our own little name space >to use, with no fears of conflicting with someone else. (Maybe "Latency" >might be used in a future extension of RFC822 for some other meaning than >what we are using it for.) I am not sure what has to be done to get an >RFC approved but I suspect that adding mail header fields would be much >more likely to hit opposition than adding yet another MIME type. > >What does Mixmaster use for its commands? Does it use "::" followed by >Anon-Send-To: and such? Or some other format? Maybe it should be made >MIME compliant from the beginning. This way we are moving with the >current, the flow of the net, rather than across it. > >Hal With Mixmaster, everything is hidden inside the encrypted and ascii armored message structure. I use the :: token to let the remailer know that this is a remailer message of some sort. The Remailer-Type will eventually be used to indicate the version that created the message. It would be easy to add support for MIME. It would just replace the token and version number. All remailing instructions are inside the ascii armor. Note that the block of ascii armor is allways exactly the same length. :: Remailer-Type: 2.0 -----BEGIN REMAILER MESSAGE----- hQCMAgbmF1BLzawNAQP/RFw2/UagugMFPlnJ94KLmhaxDoplzAhNBCxuFRL2fosL V1YnFd2XVckJJ6vTe6DB+POO+V7HEdXkp3sWtjb56Am+/B+tM1TdeC6NPNV4g5PC 15oYl7eD0ZxyjB34GdN5z/C2mOMbvP3k9eK3pn3ffkaXHBt1Y0I9ZieHkE6erxem AAAAusuiqVunPh15+7gttD5pNuIAOFDKfH8NJ39ReSEFAeeiOun6KSneJT+2DJ9Q LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58 0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj <SNIP> LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58 0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj VYbH5jxvKPjF4HEaS++MaBwTvzBkEKxbS+6oh7G/ndkHBxA7d7C0sx+qX9sjJyAs OIpGERZYA9RVspXUWys5fihnwrhk90dDAVZb8hTsPQfTXLp4 =ouPq -----END REMAILER MESSAGE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

2 1

(fwd) OREGON HOUSE BILL 2319 - Outlaw Anoniminty??
by skaplin＠mirage.skypoint.com 17 Dec '03

17 Dec '03

Damn!! Has this been a crappy week!!! Sam Path: skypoint.com!scipio.cyberstore.ca!math.ohio-state.edu!howland.reston.ans.net!news.sprintlink.net!uunet!news.fc.net!ima!libertybbs!terry.liberty-parker From: Terry.Liberty-Parker(a)libertybbs.ima.infomail.com (Terry Liberty-Parker) Date: 09 Feb 95 08:26:51 Newsgroups: comp.org.eff.talk Subject: OREGON HOUSE BILL 2319 - Message-ID: <ff3_9502091822(a)ima.infomail.com> Organization: Austin InfoMail Association - Austin, TX Lines: 112 -=> Note: Forwarded (from: LIBALERT) by Terry Liberty-Parker using timEd. Originally from ERIC GRAY (76:48/200.0) to ALL. Original dated: Feb 05 '95, 03:42 This message was from LES LEMKE to ALL, and was forwarded to you by ERIC GRAY. ------------------------- ( HB 2319 Page 1 ) 68th OREGON LEGISIATIVE ASSEMBLY - 1995 Regular Session HOUSE BILL 2319 Ordered printed by the Speaker pursuant to House Rule 12.00A (5), Presession filed (at the request of Representative Kevin Mannix) SUMMARY The following summary is not prepared by the sponsors of the measure and is not a part of the body thereof subject to consideration by the Legislative Assembly, It is an editor's brief statement of the essential features of the measure as introduced. Directs operators of computer networks to keep records of identity of users of network and of personal information about individuals that is disclosed to users. Requires disclosure to individual when information about individual is accessed by user of network. Sets rules for disclosures. Allows injunction or maximum civil penalty of $100,000, or both, for violation. A BILL FOR AN ACT Relating to computer information systems. Be It Enacted by the People of the State of Oregon: SECTION 1. As used in sections 1 to 3 of this Act: (1) To "access" means to instruct, communicate with, store data in, retrieve data from or otherwise make use of any resources of a computer, computer system or computer network. (2) "Computed' means, but is not limited to, an electronic device that performs logical, arithmetic or memory functions by the manipulations of electronic, magnetic or optical signals or impulses, and includes all input, output, processing, storage, software or communication facilities that are connected or related to such a device in a system or network. (3) "Computer network" means, but is not limited to, the interconnection of communi cationlines, including microwave or other means of electronic communication, with a computer through remote terminals or a complex consisting of two or more interconnected computers. (4) "Computer program" means, but is not limited to, a series of instructions or statements, in a form acceptable to a computer, that permits the functioning of a computer system in a manner designed to provide appropriate products from or usage of such computer system. (5) "Computer software" means, but is not limited to, computer programs, procedures and associated documentation concerned with the operation of a computer system. (6) "Computer system" means, but is not limited to, a set of related, connected or un connected, computer equipment, devices and software. (7) "Data" means a representation of information, knowledge, facts, concepts, computer software, computer programs or instructions. "Data" may be in any form, in storage media, or as stored in the memory of the computer, or in transit, or presented on a display device. "Data" includes, but is not limited to, computer or human readable forms of numbers, text, stored voice, graphics and images. SECTION 2. (1) An owner or operator of a computer network or computer system shall establish procedures requiring each person who accesses the network or system to disclose NOTE: Matter in boldfaced type in an amended section is new; matter [italic and bracketed] is existing law to be omitted. New sections are in boldfaced type. LC 984 [1] --- * Origin: Stargate Oregon - North Bend, Oregon USA (1:356/3) * OLX 2.2 TD * The oldest question known to man: "Where are my keys?!" ___ GOMail v2.0t Beta [94-0145] - Origin: The Desert Reef * LIB * Tuc.Az * V.34 * 602 624 6386 (76:48/200) --- timEd 1.00 * Origin: LibertyBBS Austin,Tx [512]462-1776 (1:382/804)

1 0

NSO Challenge 95 Nr. 1
by Network Security Observations 17 Dec '03

17 Dec '03

*********************************** Network Security Observations Challenge Nr. 1995-001 February 8, 1995 *********************************** Network Security Observations invites the international research community to produce a detailed presentation on the following subject: > Establishment, authentication, and verification of a relationship and untraceability of undeniable secret transactions < Conditions - Party A (Alice) - Party B-n (Bob) - A multitude of Bobs know who Alice is - Alice - being only one party - does not personally know who the Bobs are - It is the desire of Alice to transact - Bob - only producing a certain proof - remains further a static party - At one given time Alice established a relationship with Bob-n - Further, from time to time Alice wants to check this relationship with Bob-n - Alice may utilize the verification process only for this purpose - At a given point Alice might want to terminate her relationship with Bob-n, or vice versa - It is essential that the relationship between Alice and Bob-n is set up so that Bob can prove to Alice that he is the legitimate Bob, but, in such a way that his real identity remains secret for Alice - Alice can only use this procedure to verify Bobs legitimacy - Alice may only verify, but not register - Alice may have the option to repeatedly challenge Bob s legitimacy, but the conditions under which these separate verification checks take place may not be registered as well - Alice now wants that Bob can undeniably prove to her that he is who he says he is, by untraceable number verification, thus without actually knowing the real identity of Bob, and without the ability to utilize the verification process for any other purpose The presentation should include the full theoretical processes, applying known cryptographic algorithms, the theories of undeniable untraceable number verification and secret transactions as developed by Dr. David Chaum (see proceedings Crypto, Eurocrypt, etc.), and envision a practical applicability in a real world environment. The presentations will be judged by a team of seven international experts of senior academic/research level. The best presentation will receive international acclaim (including, but not limited to TV) and a (secret) financial reward of substance. It is essential to register, (name, surface mail address information, affiliation, email address, p-pgp key (optional)). One should do so by sending an email message with this information to: nso(a)delphi.com Upon registration a notification and detailed instructions will be mailed to the individual who registers by surface mail/airmail. There is no limitation as to origin, nationality, position, or seniority of the researcher(s). The presentation may be made by more than one researcher, but a lead-researcher must be registered. Co-researchers will share equally in the benefits, allowing for one extra share for the lead-researcher. There is no set maximum number of pages for the presentation, though an extended abstract must be at least 15 pages, while the full paper must be at least 25 pages in length. The lead-researcher and at least two co- researchers (if any) must be prepared to present the efforts in person during an international conference. Commercial entities/companies may not participate. Employees of commercial entities/companies may participate individually, but must testify that their employer shall have no benefit of their efforts. To allow for proper preparation the deadlines are as follows: 1. registration with NSO: ends on March 1, 1995. 2. proposed presentations (extended abstracts) should be received by NSO on or before August 31, 1995. 3. final presentations must be received by NSO on or before November 30, 1995. The presentation selection/review process takes place in three rounds: - first selection of the extended abstracts - correction selection of first round passed - final selection of remaining passed More details will be available in the next issue of Internet Security Monthly and the next supplement of Network Security Observations. | Network Security Observations - Internet Security Monthly | International Research Journals on | Datacommunications and Network Security | Suite 400, 1825 I Street NW, Washington DC 20006 | United States | Telephone +1 202 775 4947 - Fax +1 202 429 9574 | Internet: nso(a)delphi.com ----------------------X----------------------

1 0

Re: The drumbeat against anonymity continues....
by rparratt＠london.micrognosis.com 17 Dec '03

17 Dec '03

Allen B. Ethridge wrote: > The technology to reduce cellular fraud, through encryption and > authentication, is easily implementable, but for some reason neither > the operating companies nor the manufacturers want it. > > In contrast, European cellular (GSM) products do implement > encryption and authentication (at least as far as laws allow). > GSM mobile phones can be equipped with a slot for a card that > identifies the subscriber. Billing is based on the subscriber's > identity, not the phone's. Actually, all GSM phones use a smart card to ID the subscriber. There was at one point the idea that this card would be useful for other things, e.g. you could plug it into a fixed line phone and have that phone take on your personal number, or even use it as a payment card. However, the desire for ever smaller phones means that the credit card form factor is dying out for SIM cards, and one doesn't want to keep popping a 0.5" x 1" mini-SIM out of the bowels of the phone. GSM uses less than strong encryption, by the way. I forget the technical details, but it is of the level that governments can fairly readily crack, but beyond the reach of most private organisations. (So no more 'Squidgy-gate'). It would, however, be quite feasible to add additional second stage encryption to phones (since the dataflow is digital point-point). I wonder if Nokia, a Finnish company well outside the scope of COCOM, might offer a feature like this. Incidentally, is there likely to be any adoption of GSM in the US in the near future? -- Richard Parratt

1 0

Crusade's End
by Nathan Zook 17 Dec '03

17 Dec '03

Date: Wed Feb 1 20:35:31 1995 From: Rick Busdiecker <rfb(a)lehman.com> Date: Wed, 1 Feb 1995 18:59:54 -0600 (CST) From: Nathan Zook <nzook(a)bga.com> Instead of routing all of those messages to /dev/null, forward them back to the authors, perhaps with a notice that the message appears to have been mistakenly routed to you? And then all LD has to do to have lots-o-fun is to send you a whole bunch of "your OS sucks" messages with the From: line set to alt.religion.scientology(a)some.mail2news.site . . . . Rick Presumably, this sort of censure would occur very rapidly. The script had specific from/to lines it was looking for. Neat idea, though. Nathan

1 0

Frothing remailers - an immodest proposal
by Nathan Zook 17 Dec '03

17 Dec '03

kevin(a)elvis.wicat.com: >Be gentle, though - it's my first time. Here? You jest. ;) >It seems to me that the current remailer web suffers a fundamental flaw. >It is simply too static. When a remailer disappears, service is >disrupted and messages are lost. Humans have to statically route their >messages through the web either by hand or using relatively primitive >tools such as the chain script (not to belittle the useful work that has >been done, but it is by no means idiot proof yet). Basically, the >current web of mailers shows nothing of the dynamic nature that has kept >the internet alive and has offered us a decent chance at truly anonymous >communications, nor is it easy to use to its full potential. > >Consider a more dynamic web of remailers. I envision remailers that >actively advertise their presence on the web so that all active >remailers are aware of all other active remailers. This advertising is >to have very low latency so that a new mailer can be known to the web >within minutes (I will address the implementation of this later). Thus, >remailers can constantly be appearing and disappearing without impact on >the web as a whole (I refer to this dynamic web of remailers as a >"froth"). Imagine also that remailers are allowed to dynamically perform >the routing functions that are currently done statically offline (for >reasons I will discuss shortly). > Some version of this discussion came up a few months ago, and I passed on it then, but I think I've heard enough to comment now: The remailers are based on an inherently different model than the InterNet. Some of these differences, in fact, are crucial. 1) The InterNet is based on mutual cooperation/mutual trust. Cypherpunks trust no one that they don't have to. This is not just a result of our twisted psyche. If we could trust everyone, we wouldn't _need_ remailers. Since we don't even know who is whom out there, we avoid extending trust. 2) The InterNet is concerned first about reliability, and not at all about privacy. The remailers are concerned first about privacy, and can leave reliability to the users, if need be. There is nothing to prevent Alice and Bob agreeing to send each other ACK statements, and retransmitting messages if they don't get the ACK. There has been some mention of remailers doing the same with each other, in an attempt to improve net-wide reliability. BTW, with T1, sending ACKs is not unreasonable between remailers. 3) From 1) and 2). The remailers are heading towards mandatory PGP, possibly nested. All InterNet messages are world-readable--although this may be changing as the model breaks down. Again, this has to do with the intrinsic diffences. >The use of such transient routers implies allowing dynamic routing. If >any given remailer may go down or move at any point, it is impractical >to expect users to keep track of which are up at the moment and create >static routes in the current manner. The only reasonable solution I have >come up with is to allow the remailers themselves to choose routing, >given that they have full knowledge of the current state of the froth. Here we have the real head of the problem, as Hal so asutely points out: in your model, if the first remailer is bad, the message is compromised. If user encrypt to all remailers, they might as well encrypt directly to mole(a)snakeoil.nsa.gov. If they don't, they severly limit who can pick out their messages. In particular, they bypass transient remailers. But that isn't all. If the remailers pick the route, they are in a no better state than the users. Since the flushing attack requires remailers to operate on ticks, with carryover, an hour delay per remailer is almost minimal, untill traffic really picks up. So if some message routes through four remailers, a minimum of four hour delay results. In your case, this could easily move between in/out of service modes. > Think about the proposed extension to MixMaster to >allow separate parts of a multi-part message to be routed separately, >and consider whether you really want to have to do this by hand. I >strongly suspect that most messages are currently routed via boilerplate >scripts, which has to make the job of traffic analysis much easier for >our good friend Eve. Stupid is as stupid does. >By the way, a brief rant on a related topic; people speak of not >trusting remailers any further than necessary, while I am clearly >suggesting granting more authority and trust to the remailers. This >notion of not assigning trust is simply nonsense. When you send a piece >of mail to a remailer, encrypted or not, you are assigning complete >trust in that remailer to keep you anonymous and not to forward your >mail to the NSA immediately. NOT TRUE. With proper use of encryption, you are trusting your first remailer only to not reveal that you sent a message, and not to correlate that message to the one it sends out. With rational use of garbage running two deep, you can even suffer this loss without significant harm. >This does lead to a related problem, however; if we allow remailers to >pop up at random and join in the froth, how do we know that Deitweiller >won't set up a number of black hole remailers that take your mail and >throw it away, disrupting the froth, or forward it to nphard(a)nsa.gov? How indeed? The reason we chain is because we _don't_ really trust our first remailer--or any other. >Fortunately, we already have the PGP web of trust model in place and can >use it to good effect in this case. Remailers should simply not route >mail through any remailer whose public key is not trusted unless >explicitly ordered otherwise. This requires remailer operators to >cooperate to some extent to validate one another's remailer keys, but >does confer the great advantage of portable remailers as mentioned >above; if I run a trusted remailer on one machine, I can move it to >another machine, and as soon as I advertise the new address and the PGP >public key, it is a trusted and useful part of the froth. Actually, there may be something here. I don't know about you all, but my PGP isn't very happy about all these new remailer keys. We could agree to the following standard: Signing a remailers' key means that you believe the remailer to be secure. Trusting a remailer key means trusting the remailer operator to validate other remailer's security. This adds a whole new meaning to the phrase, "key compromise certificate". >While we are advertising a PGP key and internet address, we might as >well incorporate other useful information. For instance, remailers could >advertise their maximum latency. While I agree that it is useful to post the operating characteristics of the remailers, the maximum latency must theoretically be infinite in the standard model to prevent flushing attacks. > Kevin Hal <hfinney(a)shell.portal.com>: >I do like Kevin's ideas about a dynamic remailer net, but I think >another approach would put more smarts into the client program used by >the originator. Hear ye, hear ye! And along those lines... I'm scetchy (at best) by what is meant by "pinging" a remailer. Would it not be possible for live-on-the-net remailers to accept a (socket?) quick check to see if they are online? If so, then the ping would only work if the remailer was active when tried. Furthermore, client software could startup by sending out these pings, and presenting only responding remailers to the user--with an exception list for those not "live". Nathan P.S.: Late breaking weakness: Pinging a group of remailers is strong evidence that you are about to send a message.

1 0

re: Remailer Encryption Module
by Nathan Zook 17 Dec '03

17 Dec '03

From: eric(a)remailer.net (Eric Hughes) From: Nathan Zook <nzook(a)bga.com> I also believe that hacking PGP is a bad thing (tm), because it means that every time an upgrade comes out, it will need to be re-hacked, and once you start hacking, when do you stop? I agree. PGP just does not have the support for the encryption required for mixing remailers. These deficiencies have been known for about two years at this point and still nothing has happened. I expect this not to change anytime soon. That means that we have to replace PGP as the encryption module for remailers. The first thing to do is to design a data format which supports what the remailers need now, and nothing speculative. Since this data format has a single purpose, we can make new revisions more easily than for a general purpose package. Once we get a data format, implementations will follow. Eric As I've considered this problem, I've arrived at essentially the same conclusion. We need an RSA-IDEA package that does something very close to Mixmaster. The only caveat is that we _must_ retain compatibility between signature formats, even though, as I've suggested, a signature on a remailer's key might mean something different than a signature on an individual key. Nathan

1 0