December 2003 - cypherpunks-legacy

Re: Effects of S.314 (Communications Decency Act)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 12:02 PM 2/8/95, Robert Rothenburg Walking-Owl wrote: >Of course geographic community standards are problematic too with >telecommunications since postal inspectors from Tennessee can call >up adult bulletin boards in California... This reminds me of a joke I finally grew tired of, prescient though it may have been given current legal events in Tennessee: It's illegal in Cambridge to smoke in Boston... Most non-smokers, especially the reformed-smoker non-smokers, didn't think that that one-liner was very funny. Most small-l libertarians had a hoot or too about it though. (Just like the punchline about how many radical feminists it takes to screw in a lightbulb [A: That's really *not* funny.]) I guess I'll sit down now... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Re: Judges-L FAQ
by Michael Sattler 17 Dec '03

17 Dec '03

At 12:43 2/8/95, Craig A. Johnston wrote: >I must inform you that this FAQ is copyrighted material, and >you are requested not to distribute it. What good is a FAQ if you can't distribute it. The judges are confused in more ways than one. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

2 1

RE: a new way to do anonymity
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > I'd suggest just getting something running first, to get some > prototyping experience. Now that I've just spent some time compiling and playing with Matt's ESM program, it seems almost perfectly suited for prototyping Pipe-Net since you can use it to do nested encryption. All that's needed is to hack it so that it implements link encryption (i.e., send a constant stream of random data in between keypresses). This is what the user would do: (LESM for Link Encrypted Session Manager) lesm -l lesm -l login to server 1 lesm -s lesm -l (or better yet take over a free LESM session already running between server 1 and server 2) login to server 2 lesm -s lesm -s I wonder if Matt has the time and interest do this... If not then I guess I can try, but I've never done real crypto programming before... Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzlIdDl0sXKgdnV5AQFKuwQAqhJulKWcPV8GWUM11+2zonT+EQ8q18YV TAymUlhjuYo0csHP/nmoMDRpf/9veISdBQE/GlRkc1k0JsWpPBD0+6e0nA7kCTMO xqVoXdM3F/qN31CXjMT9rgAanIXFat2Ox3bjT3g07ReaN372TPnGGvNauxO69Z52 kvWajSSXiSY= =yF/i -----END PGP SIGNATURE-----

2 1

Re: MIME based remailing commands
by xpat＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

Hal writes: >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. >OTOH it does have the advantage that it is easy to do, at least with th >"::" pasting token idea (which perhaps would need to be documented in is >own right). IMHO, an ideal message would have the ability to handle nested objects of varying types, MIME is only a start. To construct a unique format for remail_messages is reasonable, perhaps even preferable. But of course, MIME *could* be a start, in a brown'n'serve roll sort of way. However, with a proprietary approach, what to use for delimiters, or quasi-parentheses (in the case of n layers of nesting, encrypted or unencrypted) needs extensive and careful consideration. This is the same dilemma many developers face with document-centric interfaces and their plethora of odd-bird formats. I say take the remail stuff out of the header altogether, MIME or not. ---------------------------------------------------------------- P M Dierking |

5 9

Hastur CT status
by A Loose Affiliation of Millionaires and Billionaires and Babies 17 Dec '03

17 Dec '03

(Sorry if the signature gets anybody's noses out joint. I'm in a goofy mood.) -----ORTVA CTC FVTARQ ZRFFNTR----- It's another Hastur Crypto Toolkit progress report. Why? Because many people expressed an interest in it, because I want to continue to get comments on what I'm doing, because I want people who might be inclined to do something similar to know about what I'm doing, and because cypherpunk projects tend to be assumed to be dead if nothing is heard. The general IO section skeleton is finished, and all file I/O and memory I/O types are supported. Encoding rules now fully coded in are rot13 (for simple testing), uuencode, and radix64. There are also unfilled stubs for DER/BER at the moment. I'm about to start in on the framework for crypto code and key management: Any ideas on handling a generalized concept of keys will be greatly appreciated! For instance, I've asserted several times here that X.509 keys can be fully modelled as special cases of PGP web-of-trust keys with one additional field, the expiration time. Nobody has flamed me, but nobody has agreed with me... since I've only read the X.509 spec and never actually used them, I'd like some assurance that I'm not missing some subtleties in this approach. The general I/O is fairly slow, since items are fetched in blocks appropriate for the encoding (IE, radix 64 maps 4 bytes r64 to 3 bytes binary); I might put the effort into optimizing it later, but my gut feeling is that the crypto is going to be at least an order of magnitude slower. Now, the general outline of what I'm building. This is pretty much the same as what I've posted before. I do want to note that all I/O is locking, using a library of locking versions of I/O fns I sent to some folks here a while ago. - --- Hastur Crypto Toolkit. In essence, what I'm building is a crypto library that takes a very general approach with a few parameters controlling its behavior. The idea is to have something that anybody can drop into their mail agent and have an easy way of using crypto and interface with existing systems such as PGP. A major design goal is to be backwards compatable with PGP, but paramount is having a plug-and-play library that will be flexible enough to meet future crypto needs. RIPEM compatability is also desirable. One of the biggest problems today is that crypto libraries are chiselled out to deal with very specific cases -- the most general I know of if is RSAREF, which deals with only with crypto functions that RSADSI happens to find useful. The things that I've parametrized in the design are: - Type of I/O. Right now, files (and fds) and a couple of memory configurations are supported. I've made it trivial to add new types of I/O as well, and there are flags to support to immediate zeroing of data once it is read into the internal structures. - Encoding of data. There are multiple ways to encode a bytestream and these methods can be nested. In this library, you can specify the type. I also want to eventually put logic in (where possible) to determine the type and will also use this to support various compression schemes. Currently supported are rot13, radix64, and uuencode. - Ciphers (this is the big one). Right now, as I've mentioned, things are very haphazard. What I want is a way to change one parameter from, for example, CRTYPE_IDEA to CRTYPE_DES and thus change the encryption scheme. - Key management. I know of two major ways of doing things right now, X.509/PEM certificates as pushed by RSADSI, and PGP web-of-trust. As far as I can tell, PEM-style certificates are just a degenerate case of PGP web-of-trust. - Random sources. People should be offered a pretty good source of random numbers, but should also be allowed to drop in their own sources. This is going to be relatively tough on platforms I don't know much about, IE Mac and PC, but I'm hoping for some help on this. I can also salvage some code from RIPEM for those. - Autoconfiguration to incoming messages. People should be able to open a file and have it work, even with schema added to the library after the original adaption to Hastur (assuming an upgrade of the library, of course). There's some other stuff that I'm probably forgetting here, but that's the gist of it. The cipher code is going to be pretty simple: I'm getting a lot of code from various places on the net; the code exists, it just isn't put into a form that is easy to use. The most difficult is going to be a generalized scheme for key management: first off, I'm probably going to simply use PGP's web-of-trust as my model, assuming the X.509/PEM style certificates can be treated as degenerate cases of web of trust. I also intend to offer a GSSAPI interface to all of this in release 1.1 or so. This is so far all in C: I'm not a C++ convert yet and C is still the most portable of the languages about. Later, perhaps class libraries can be designed around the same code. Comments are actively solicited. -----ORTVA CTC FVTANGHER----- Irefvba: 2.6.2 vDPINjHOYmxxvuAutbieCO7qNDSfStDNyU0k5/4/10EHEJGY72kwhzoGEAZMe0z7 oQf4Y+QbtweC9vauOYo8SAXFrI4td2coJ3xbtsojYTuhHamWcX2AxIlLedSWFuuJ e6mIEDbk6xIpoyLvIsfSLUqKkO6qe4hWXZxORSF6vN6cqvmNaNAuG17nE8IqfiAh ZeydKo0cNf8= =oOZD -----RAQ CTC FVTANGHER-----

2 1

The drumbeat against anonymity continues....
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

In addition to the articles and editorials, I'm seeing articles slamming anonymity and pseudoanonymity (we need a better word!) in business contexts. See the latest RISKS Digest (16.79, available on Usenet in the group comp.risks) for a couple of articles of interest. One is about the Singapore plans for an automatic vehicle intentification (AVI) system to implement "road pricing" on congested roads. Phil Agre's article makes some good points, and mentions using digital cash to avoid the Big Brother problems, but notes that Singapore is not seriously considering it. The real "drumbeat" article is about cellular phone fraud and toll-free number fraud. Actaully, a couple of related articles. (Everyone should at least skim "RISKS.") Anonymity is cited as a problem. But this misses the point, that the real problem is lack of a proper payment model. As David Chaum points out, there are really only two basic payment approaches: transfer of something of value or an account-based transfer. Cash or barter are examples of the first, checks or credit card payments are examples of the second (though each has some wrinkles). Digital cash, when online cleared, behaves mostly like real cash. The phone companies that are complaining about fraud have inadequately arranged for security and need to adopt a mode that fixes this. Since physical money can't be fed into the slots of a handheld cell phone (or at least can't then be delivered to the service owner!), the solution has traditionally been an account-based payment system. (Accounts can also be better protected against fraud by having PINs, etc.) What about telephone calling cards? I don't recall the details well enough to know if they could be used on handheld units. Maybe they could be used. This could eventually be a market for digital cash. (If fraud is a serious-enough problem, costing enough, then a service which could lower costs by using digital cash could make market inroads.) What we need to watch out for are proposals to limit anonymity, to mandate national ID cards, so as to somehow limit such cases of fraud. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay

1 0

Not necessarily crypto but scary anyway...
by root 17 Dec '03

17 Dec '03

Hi all, A friend advises me that today House Bill 666 passed. This supposedly would allow police officers to use evidence collected illegaly if they 'believed' that it was collected in good faith. Any word on it? Thanks.

10 13

Meeting Anncouncement for Sat. Feb. 11 1995 SF Bay Area Meeting
by hugh＠ecotone.toad.com 17 Dec '03

17 Dec '03

What: Cypherpunks SF Bay Area Physical Meeting When: 13:00 February 11 1995 Where: Silicon Graphics, Inc., Building 5 (SGI's Iris Cafeteria) 2025 North Shoreline Boulevard, Mountain View, CA, Earth, Sol, MW Topic: Crypto Networking Protocol Hygiene Agenda: (listed times are almost all a joke) 12:00 Brown Bag Lunches, AV Debugging, Loose Talk 13:00 Meeting Begins (MBONE broadcast begins) 13:02 Meeting Announcements, Agenda Rewrite 13:08 Hugh Daniel on "When What Goes Where: Good Networking Protocol Hygiene" 13:45 Eric Hughes on "Sendmail as a Multiplexor" 14:30 Michael Sattler on "Announcement of CryptDisk v1.0" 14:40 General Announcements, Questions, Confusion etc. 15:00 BREAK! 15:30 Doug Barnes "Stream-oriented, analysis-resistant public-key protocols over UDP" 16:15 Raph Levien & KT Kislitzin on "Design philosophy for the upcomming PGP 3.0 API" 17:00 Hot New Topics of the Week & General Free For All! 17:59 Mbone Broadcast ends 18:00 KP room, Thank our SGI hosts & GOTO Dinner Presentations: "When What Goes Where: Good Networking Protocol Hygiene" Hugh Daniel <hugh(a)toad.com> When designing, coding and testing programs we are confronted with a myriad of choices as to how various parts of the solution communicate. Much is known about how to design 'protocols' that are flexible, debugable & robust. We are currently encoding cryptographic protocols in our systems and networks at a furious rate, yet there are new challenges in keeping such systems robust, secure and sometimes even anonymous. I hope to touch on some of the well known tricks and dangers, what is new when cryptographic and anonymous systems are combined with todays systems and where we might learn from the past. "Sendmail as a Multiplexor." Eric Hughes <eric(a)remailer.net> The basic architecture of sendmail is a recognizer and a dispatcher. These two elements provide a good framework for designing systems that can be changed piece by piece. Even when a facility seems to have stabilized, it's often a good idea to keep the flexible framework around for future experimentation and expansion. "Announcement of CryptDisk v1.0" Michael Sattler <msattler(a)jungle.com> CryptDisk (for the Macintosh) is an example of the kinds of [mostly] transparent strong crypto that we need. Integrated smoothly with the operating system, CryptDisk provides IDEA encryption on a block read/write level for a virtual hard disk. It's beauty lies mainly in that it does exactly what the user expects and requires no more setup than remembering a pass-phrase. Source code is available upon request. Warning: Some governments might consider this software a "Munition", not suitable for "private possession" by free peoples. "Stream-oriented, analysis-resistant public-key protocols over UDP" Doug Barnes <dab(a)Tadpole.COM> Many cypherpunks projects have a need to reliably transmit variable-length (sometimes quite long) data over unreliable networks. TCP lends itself to traffic analysis and is not well-suited for use in a hypothetical system of packet laundries that would lead to packets within a particular stream appearing to come from a variety of sources. We have designed and are currently implementing a UDP-based, hidden-streams protocol that utilizes fixed-length blocks and pseudo-random sequence numbering to provide reliable, stream-oriented services to higher-level applications despite extremely creative routing and laundering of packets. Raph Levien <raph(a)netcom.com> & KT Kislitzin <ktk(a)sgi.com> "Design philosophy for the upcomming PGP 3.0 API" PGP is getting a major upgrade soon, some of the team doing the work will talk about the motivations and directions the work is going in. --------------------------------------------------------------------------------

1 0

Re: Effects of S.314 (Communications Decency Act)
by dmandl＠panix.com 17 Dec '03

17 Dec '03

At 11:02 AM 2/8/95, strick(a)techwood.org wrote: >Right now there is a "safe harbor" from around 10pm (or is it 9pm?) >thru 6am, but this changes regularly, usually as a result of "case law" >(someone being prosecuted under next month's rules, not this month's) Yup, this stuff is subject to change about every week--so much so that at WFMU, our station manager simply imposed one set of fairly "conservative" restrictions on "obscene" language at _all_ hours, set it down on paper, and left it at that. Can't blame him, as the guidelines were changing literally every few months and at one point it was very easy to be operating based on last month's rules. "Safe harbor" loopholes, disclaimers, etc., are history right now as far as I know, but of course it may have changed. I think the important thing is for the program director to have some "responsible" codified policy to show to the FCC if they hassle you. They mainly want to know that s/he's keeping an eye on things and has some coherent house rules. This sucks, of course, but probably makes life easier in the long run. I have occasionally let a naughty word on a record slip by (accidentally, of course), and no one's going to make a big deal about it. For a while, we were all convinced that the FCC left all these rules impossibly vague on purpose, just so that you didn't even know how to obey the law if you wanted to. Everyone a potential criminal. --Dave. -- Dave Mandl dmandl(a)panix.com

2 1

Re: Judges-L FAQ
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 3:43 PM 02/08/95, Craig A. Johnston wrote: >It has come to my attention that the Judges-L FAQ is being distributed >by someone who obtained it on this list, and being sent to people made >to look as if it has issued from David Stodolsky. > >I must inform you that this FAQ is copyrighted material, and >you are requested not to distribute it. Huh? What kind of an FAQ is it, that can't be freely distributed? If you don't expect people to redistribute the text, don't call it an "FAQ". The phrase "FAQ list" is understood internet-wide (or at least usenet-wide) to mean a freely distributable list of information someone might want on a certain topic. (It doesn't neccesarily mean "Frequenty Asked Questions", literally, these days. Cause there are often FAQs distributed that just contain general information on a certain topic, but not actually questions that have ever been asked before. The Judges FAQ might be a good example.) If you don't want people to redistribute the thing, the really should change it's name. And write very explicitly at the top of the document that no one should copy it without permission of the author. These things just aren't generally supposed to be true of FAQs.

1 0

S. 314 and existing situation
by Richard F. Dutcher 17 Dec '03

17 Dec '03

Gee, fellas, looking over this bill, *most* of what's going on is just porting existing telephone law over to cybercomm. Given the existence of 900-sex-talk, the phone companies are clearly not being held responsible for content. They are required, of course, to cooperate when complaints of harassing or obscene calls are made, to obey properly warranted requests for wiretaps, etc. It's perfectly reasonable to expect similar requirements on net service providers. > > Read carefully. There are indeed implications for Internet service > providers in terms of their responsibility under the law for the content > of their systems and services. > Yeah, but First Amendment and common carrier law is a morass of conflicting statutes, interpretations, and case law. After all, libel law puts some content liability on newspapers [too much, IMHO, but it has hardly destroyed freedom of the press]. As several posters have noted, the placement of the key words "knowingly" and "intentionally" are critical. It doesn't appear, though, that any "knowingly"s or "intentionally"s have been removed. I am forwarding copies of this and the whole bill text to my brother, the former DA in Telluride, to see if he sees any unusual craptraps. I'll post any useful reply ... > > (a) Prohibited acts generally > > Whoever - > > (1) in the District of Columbia or in interstate or foreign > communication by means of [telephone] telecommunications > device - > > (A) [makes any comment, request, suggestion or proposal] > makes, transmits, or otherwise makes available any comment, > request, suggestions, proposal, image, or other communication] > which is obscene, lewd, lascivious, filthy, or indecent; > > (B) [makes a telephone call, whether or not conversation > ensues, without disclosing his identity and with intent to > annoy, abuse, threaten, or harass any person at the called > number] makes a telephone call or utilizes a telecommunications > device, whether or not conversation or communications ensues, > without disclosing his identity with intent to annoy, abuse, > threaten, or harass any person at the called number or who > receives the communication; > > (C) makes or causes the telephone of another repeatedly or > continuously to ring, with intent to harass any person at the > called number; or > > (D) [makes repeated telephone calls, during which conversation > ensues, solely to harass any person at the called number; or] > makes repeated telephone calls or repeatedly initiates > communication with a telecommunications device, during which > comversation or communication ensues, solely to harass any > person at the called number of who receives the communication; > or I.e., *just like with phones,* you can't send harrassing or obscene messages to unwilling recipients. Is there a lot of slack for bullshit? You betcha! A major change from the present? Doesn't look like it. [no intention of holding up the present as paradise, of course ;-] > > > (b) Prohibited acts for commercial purposes; defense to prosecution > > (1) Whoever knowingly - ^^^^^^^^^^ [applies to A & B below] > > (A) within the United States, by means of [telephone], > telecommunications device makes (directly or by recording device) > any obscene communication for commercial purposes to any person, > regardless of whether the maker of such communication [placed the > call] placed the call or initiated the conversation; or > > (B) permits any [telephone] telecommunications facility under such > person's control to be used for an activity prohibited by > subparagraph (A), shall be fined in accordance with title 18 or > imprisoned not more than two years, or both. > > (2) Whoever knowingly - ^^^^^^^^^^ [applies to A & B below] > > (A) within the United States, [by means of telephone, makes] > by means of telecommunications device, makes, knowingly > transmits, or knowingly makes available (directly or by recording > device) any indecent communication for commercial purposes which is > available to any person under 18 years of age or to any other person > without that person's consent, regardless of whether the maker of > such communication [placed the call] placed the call or > initiated the communication; or > > (B) permits any [telephone] telecommunications facility under such > person's control to be used for an activity prohibited by subparagraph > (A), shall be fined not more than [$50,000] $100,000 or imprisoned not > more than [six months] 2 years, or both. > =================================== Rich Dutcher, San Francisco Greens P.O. Box 77005, San Francisco, California 94107 USA "That's libertarians for you - anarchists who want police protection from their slaves." Kim Stanley Robinson, "Green Mars" Greens, of course, only enslave plants - so weed-whackers work better than cops ... ====================================

4 3

Re: Not necessarily crypto but scary anyway...
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

> > On Wed, 8 Feb 1995, Ben wrote: > > > On Wed, 8 Feb 1995, root wrote: > > > > A friend advises me that today House Bill 666 passed. This supposedly would > > > allow police officers to use evidence collected illegaly if they 'believed' > > > that it was collected in good faith. > > > This sounds like a spoof. Look at the number. > > Unfortunately, it is not. World Wide Web yourself over to > http://thomas.loc.gov/ and search for hr 666...you will find it. > > "A Bill to control crime by exclusionary rule reform..." maybe if > "control" means "aiding and abetting" > > -Thomas > I haven't looked it up yet, but I did hear about the bill on news last night, so I would say it is legit. The number of the devil indeed. ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX http://spirit.aud.alcatel.com:8081/~droelke/

1 0

Vernor Vinge info...
by jmueller＠gac.edu 17 Dec '03

17 Dec '03

This may or may not have been already mentioned, but I've noticed that Vernor Vinge will be the Guest of Honor at this year's Minicon Science Fiction convention in Minneapolis, MN over easter weekend. I'm planning on going, and was just wondering if anyone here had anything in particular they'd like me to ask him, should I get the chance to talk to him (considering that I know quite well the chairman of last year's Minicon, this is distinctly possible). If anyone would like to attend, memberships are $25 until February 14, then $55 after that and at the door. Contact me for further info if you're interested. -- Joel Mueller - "Here lies one whose name is writ in water." -Keats Check my .plan for my PGP Public Key. PGP encrypted mail is very welcome! This must be Thursday. I never could get the hang of Thursdays. -Dent

1 0

Re: Judges-L FAQ
by Michael Sattler 17 Dec '03

17 Dec '03

At 17:40 2/8/95, James A. Donald wrote: >But I repeat, I think that the judges list is necessary >and desirable, so long as they remember they are self >appointed and do not start to imagine that they are >the "official" judges. By choosing that name they've shown (to my satisfaction) that they have the subtlety and self-importance of a lynch mob. The goofiness about a copyrighted FAQ only adds to my feelings of them being a dangerous keystone kops net-alike. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

1 0

S314 and potential hell-raising
by silly＠beat.ugcs.caltech.edu 17 Dec '03

17 Dec '03

It seems that 314 is a VERY BIG potental problem, and we should probably be doing everything in our power to find out what it REALLY means and fight it tooth and nail. I think Usenet is the perfect place to take this fight, but I'm not sure what groups are best suited to a discussion. Any suggestions? We simply MUST isolate this bill and, if it even comes close to sounding like what I think it does (ending the near-absolute freedom of expression and content across the Internet), we must fight it in every way possible, enlisting the ACLU, the EFF, and any other group potentially willing to pour money into a legal battle. (me)

3 2

Re: Not necessarily crypto but scary anyway...
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 9:50 PM 02/08/95, Black Unicorn wrote: >As I understand the bill,(Though I didn't know it was up for passge...) > this is merely a restatement of the current judicial doctrine which >prevents officers acting in good faith from being hindered by an >illegally issued warrant. In essence the concept is that the 4th >ammendment is intended to deter police misconduct by kicking out evidence >gathered illegally. Once a judge issues a warrant, and assuming it is >issued illegally, but with no knowledge by the officers who execute the >search, there is no longer any deterant value in supressing the evidence >and as such it would be "counterproductive" to bar it from presentment. Right, just what we want to do. Encourage police officers to remain as ignorant as humanly possible about constitutional law and citizens' rights. If the police officers can manage to remain so ignorant of con law that they have absolutely no idea that sometimes they aren't supposed to search citizens' property, appearantly all the evidence they aquire will be admissible in court. Well, I feel safer knowing that we encourage a police force that won't let a little knowledge of the bill of rights interfere with there ability to apprehend drug dealers, terrorists, and pedophiles. But if it's already current practice, it's already current practice. Of course, it would be nice if our legislators took time to write law which _increased_ our rights, or which more strictly defined rights that previous legislation and constitution as interpreted by the courts defined loosely. Instead, we seem to to expect congress to constantly try to get laws by the supreme court that are completely totalitarian, and feel lucky when they merely reinforce preexisting undesirable court decisions. sigh. Jefferson _and_ Hamilton are both spinning in their graves.

1 0

Re: Da Judge-L FAQ -- We are not Amused
by Michael Sattler 17 Dec '03

17 Dec '03

At 19:56 2/8/95, Timothy C. May wrote: >It has come to Our attention that Our FAQ, the Da Judge-L FAQ, is being >distributed amongst the rabble...Defense will be heard, and then the >guilty will be punished. Thank you, Sir. May I have another? -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

1 0

Wed 15 Feb, 730pm: BayFF's first monthly Bay Area EFF meeting
by gnu 17 Dec '03

17 Dec '03

EFF is pleased to introduce a series of monthly `BayFF' meetings in the San Francisco Bay Area. All EFF members, guests, and the public are invited. The first meeting will be in San Francisco on February 15, 1995, at 7:30PM. The gracious donor of our first meeting place is: Wired Magazine 520 Third Street, Fourth Floor San Francisco, CA +1 415 222 6200 voice John Gilmore and Cindy Cohn will speak on the constitutional issues around export controls on cryptography. John is a co-founder of EFF and Chair of the EFF Board's Crypto Committee. Cindy is an attorney in private practice at McGlashen and Sarrail in San Mateo. These controls inhibit free speech, publication of software and papers, academic freedom of inquiry, and personal privacy, as well as having a strong negative impact on computer security. We'll explore some of the implications and prospects for change. Dave Farber will speak on "Living in the Global Information Infrastructure -- some concerns". Dave is an EFF Board member and has more years of experience in computers and networking than the total experience at many startup companies. Vice President Gore has proposed that the nations of the world undertake the building of a Global Information Infrastructure -- the GII. While most leaders agree with the sprit of the Gore proposal -- namely to provide a mechanism which could invigorate the world economy in the forthcoming information age, many disagree with his belief that it will bring democracy to the world. They interpret such statements as being another example of American colonialism. It is this basic lack of uniform global agreement on what terms mean, what rules apply to electronic commerce and what impact a GII will have on their nation that underlies the comments Dave will make. These raise questions about the universality of Cyberspace. He will seek to table a set of questions that may stimulate your thinking in this area. There will also be plenty of time for general and specific questions, issues, discussion, meeting people, and socializing with frontier- minded folks. We will schedule the second monthly meeting near the Computers, Freedom, and Privacy conference -- tentatively on Friday night, March 31. Watch this space for more information. We hope to see you on Wednesday! John Gilmore Jane Metcalfe Denise Caruso (Bay Area members of the EFF Board)

1 0

Re: The drumbeat against anonymity continues....
by ethridge＠netcom.com 17 Dec '03

17 Dec '03

Late night, off the top of my head, so no quotes, please. Tim May wrote: > > >The real "drumbeat" article is about cellular phone fraud and >toll-free number fraud. Actaully, a couple of related articles. >(Everyone should at least skim "RISKS.") > >Anonymity is cited as a problem. But this misses the point, that the >real problem is lack of a proper payment model. As David Chaum points >out, there are really only two basic payment approaches: transfer of >something of value or an account-based transfer. Cash or barter are >examples of the first, checks or credit card payments are examples of >the second (though each has some wrinkles). Digital cash, when online >cleared, behaves mostly like real cash. > >The phone companies that are complaining about fraud have inadequately >arranged for security and need to adopt a mode that fixes this. Since >physical money can't be fed into the slots of a handheld cell phone (or >at least can't then be delivered to the service owner!), the solution >has traditionally been an account-based payment system. (Accounts can >also be better protected against fraud by having PINs, etc.) > 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. I'd say that the problem isn't just a lack of a proper payment model, but also an unwillingness to provide adequate technology to the problem. Of course, the GSM approach does nothing for anonymity or digital cash. allen(a)well.sf.ca.us It's dangerous, child, to come to conclusions ethridge(a)netcom.com when you don't have any facts. my opinions are my own Dr. Hemlock, The Eiger Sanction

2 1

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