- cypherpunks-legacy - lists.cpunks.org

Re: Effects of S.314 (Communications Decency Act)
by Carl Ellison 17 Dec '03

17 Dec '03

>Sender: owner-cp-lite(a)comsec.com >X-Signed: PGP-Detached-2-3, > iQBXAwUBLzhSutC3U5sdKpFdAQEEqwIMCg1PFWC19WuW2BhwmzUyg84RthT/61x9 > vLrIPbgrYcCXCNB8F51tQogs5lBrry/aOk2Fk3Izl//XC4KDl+cADrCz >Date: Tue, 7 Feb 95 21:24:01 PST >From: jpp(a)markv.com >of the very most important rights. To hold the owner of a buliten >board responsible for the illegal messages posted to it, is to force >the buliten board owner to become a government censor in all but name >(and wages). anyone heard of "no unfunded mandates" ?

4 3

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: 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

Senate Version of HR666 (fwd)
by Brad Dolan 17 Dec '03

17 Dec '03

It is still *theoretically* possible to stop the legislative revocation of the 4th amendment, if you believe we have a representative government. Brad D. ---------- Forwarded message ---------- Date: 9 Feb 1995 11:14:58 U From: Cooley Stephen <cooley_stephen(a)space.honeywell.com> To: UWSA <uwsa(a)shell.portal.com>, baron_mark_a(a)smtpmm.space.honeywell.com, Bostock#m#_Craig_W.FL40-P02(a)smtpmm.space.honeywell.com, Kidd_Lee.FL51-P03(a)smtpmm.space.honeywell.com Subject: Senate Version of HR666 S54 - the Senate version of HR666 subverts the 4th Amendment! I called Sen Mack's (R-FL) DC office this morning for info on S54. This bill has been submitted to the Senate Judiciary Committee for consideration. Hearings for S3-The "New" Crime bill, are scheduled for Fed 15th. The new crime bill also has a Exclusionary Evidence section too. I have appended this section after S54 below. No hearings for S54 are scheduled as of yet. The aid I talked to didn't know if any hearings on S54 would even occur before it is passed onto the floor for a vote. The committe could mark up the bill and pass it on without hearings. Please pass this info onto other groups and reflectors. We have to get the word out on this bill. S54 modifies the requirements of the 4th amendment to ".....if the search or seizure was undertaken in an objectively reasonable belief that it was in conformity with the fourth amendment." Given the court rulings allowing traffic stops and searches due to an officer's descretion, "probably cause", S54 hammers another nail into the 4th Amendment coffin. Call your Senators and let them know your thoughts on this bill. There is no time to waste. FILE s54.is S 54 IS 104th CONGRESS 1st Session To amend title 18 to limit the application of the exclusionary rule. IN THE SENATE OF THE UNITED STATES January 4, 1995 Mr. Thurmond introduced the following bill; which was read twice and referred to the Committee on the Judiciary A BILL To amend title 18 to limit the application of the exclusionary rule. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That this Act may be cited as the `Exclusionary Rule Limitation Act of 1995'. Sec. 2. (a) Chapter 223 of title 18, United States Code, is amended by adding the following two sections: `Sec. 3508. Limitation of the fourth amendment exclusionary rule `Evidence which is obtained as a result of a search or seizure shall not be excluded in a proceeding in a court of the United States on the ground that the search or seizure was in violation of the fourth amendment to the Constitution of the United States, if the search or seizure was undertaken in an objectively reasonable belief that it was in conformity with the fourth amendment. A showing that evidence was obtained pursuant to and within the scope of a warrant constitutes prima facie evidence of such a reasonable belief, unless the warrant was obtained through intentional and material misrepresentation. `Sec. 3509. General limitation of the exclusionary rule `Except as specifically provided by statute or rule of procedure, evidence which is otherwise admissible shall not be excluded in a proceeding in a court of the United States on the ground that the evidence was obtained in violation of a statute or rule of procedure, or of a regulation issued pursuant thereto.'. (b) The table of sections of chapter 223 of title 18, United States Code, is amended by adding at the end thereof: `3508. Limitation of the fourth amendment exclusionary rule. `3509. General limitation of the exclusionary rule. Exclusionary Evidence section in the new crime bill S3: SEC. 507. ADMISSIBILITY OF CERTAIN EVIDENCE. `Sec. 3502A. Admissibility of evidence obtained by search or seizure `(a) Evidence Obtained by Objectively Reasonable Search or Seizure: Evidence obtained as a result of a search or seizure that is otherwise admissible in a Federal criminal proceeding shall not be excluded in a proceeding in a court of the United States on the ground that the search or seizure was in violation of the fourth amendment to the Constitution. `(b) Evidence Not Excludable by Statute or Rule: Evidence shall not be excluded in a proceeding in a court of the United States on the ground that it was obtained in violation of a statute, an administrative rule, or a rule of court procedure unless exclusion is expressly authorized by statute or by a rule prescribed by the Supreme Court pursuant to chapter 131 of title 28. `(c) Rule of Construction: This section shall not be construed to require or authorize the exclusion of evidence in any proceeding.'. (2) Technical amendment: The chapter analysis for chapter 223 of title 18, United States Code, is amended by inserting after the item for section 3502 the following new item: `3502A. Admissibility of evidence obtained by search or seizure.'. (c) Illegal Search and Seizure: (1) In general: Title 28, United States Code, is amended by inserting after chapter 171, the following new chapter:

1 0

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

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

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

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