December 2003 - cypherpunks-legacy

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