December 2003 - cypherpunks-legacy

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

17 Dec '03

On Feb. 8, Samuel Kaplin wrote: > The question is: What is obsene? What the community in NYC considers > obsene is sure a lot different than what the community in Elk River > Minnesota considers obsene. (They've been trying to eject their one XXX > bookstore for years now while NYC has the American Museum of Pornography > at 42nd Street ;) ;) :) ) As you can see, obsenity depends where you are > geographically located, at least according to our highest court. If > community standards say it is obsene then it is. They never legally > defined what constitutes something as being obsene or an obsenity. > > Sam > And don't forget the recent case where the operators of a California bulletin board were prosecuted and convicted in court in Memphis....whereas they never would have been convicted under the community standards in California. You want to talk about scary....there is a section in Robert Heinlein's "Job: A Comedy of Justice" where the protagonist describes some "moral" codes that they got passed...one of them was having the community standards of the median size community of the state apply to all communities in the state. What's the betting out there that this is what would ultimately happen under these kinds of bills?

1 0

Re: Netzwelt: Geiselnahme im Netz (article in DER SPIEGEL)
by mf＠mediafilter.org 17 Dec '03

17 Dec '03

[...] > Mit so negativen Reaktionen hatte Kashpureff nicht > gerechnet. Noch vor einer Woche behauptete er > gegenžber Wired News selbstbewuþt: "Wenn Network > Solutions mir an den Kragen geht, dann werde ich ein > grþerer Mrtyrer als Phil Zimmermann" -- jener > inzwischen weltweit bekannte Bžrgerrechtler, den die > US-Regierung erfolglos wegen der Verbreitung seiner > Verschlžsselungssoftware PGP verfolgt hatte. > Angesichts des Imageproblems, das Network Solutions im > Netz hat, war die Zuversicht des Domnenguerilleros > gar nicht so abwegig. Doch trotz dieser alten > Animositten stiftete Kashpureffs Aktionismus > ausnahmsweise einmal Konsens in der Welt der > Internetverwalter: So geht es nicht. http://www.spiegel.de/netzwelt/themen/kashpureff.html [...] ...Kashpureff didn't expect such a negative reaction. "When Network Solutions cuts my throat, then I will become a gurella martyr like Phil Zimmerman (of PGP fame)" he proclaimed to Wired news.... [...] Give me a break! this is like some bad tv movie. Kashpureff, the self-styled martyr in hiding from the feds as they move in to seize his computers after he hijacked traffic from Nework Solutions' website to his own (in a desperate attempt to log some hits?). If this is supposed to be some profound statement, I think the message is lost in the idiocy of it all. As I stated in a previous posting, I denounce this type of traffic hijacking as irresponsible practice and as a negative reflection on other independents who are working to open up the address space on the net in the interests of the public. If Kashpureff would like to participate in the evolution of the net, he should not jeopardize its stability of for the sake of personal vanity. This type of drama and diversion are totally unnecessary, and obscures the focus on the real issues at hand in the whole namespace debate. One major factor of the issue is being settled in the name.space/pgMedia anti trust action against NSI...Kashpureff and others could potentially benefit from the outcome of that action if they conduct themselves in a mature and responsible manner. The next step in the implementation of the expanded namespace demands responsible practice if we are to avoid government regulation and corporate beauracracy and let the system evolve and regulate itself naturally. Judging by this recent bahavior though, it appears that some can't deal with it all now, that it's beginning to get too real. The games and posturing are over. It's time to finally put up or shut up. ...In my opinion, that is... Paul Garrin name.space http://name.space http://namespace.xs2.net

1 0

MBONE access needed
by perry＠imsi.com 17 Dec '03

17 Dec '03

Hey, guys! I need to get MBONE access in New York City or nearby this weekend in order to deliver a presentation for the Cypherpunks meeting this Saturday on IPSP. If anyone in New York can provide such access, please get in touch with me ASAP; the site that I thought I could use has sadly become unavailable... Perry

1 0

Re: lwall
by NIEHS Autoresponder 17 Dec '03

17 Dec '03

Your Usenet test article was received here at the news gateway machine for the National Institute of Environmental Health Sciences, in Research Triangle Park, North Carolina, USA 35 47 N by 78 38 W. The NIEHS newsadmins can be reached via e-mail at usenet(a)news.niehs.nih.gov. Please note that we do not offer news access to sites outside of our organization. If you're a newsadmin and you'd like to run your own autoresponder, this one is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond. If you want to suppress this message in the future, include the word "ignore" in the Subject: header of any subsequent articles posted to *.test. You could also post your test articles with a Distribution: header of "local" to prevent them from leaving your local machine, or you could also ask your local newsadmin to create a local *.test group that will not propagate outside of your organization. Path: jeeves.niehs.nih.gov!darwin.sura.net!news.udel.edu!udel!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail Subject: lwall Message-ID: <PINE4545-dhfsdkjc(a)ack.berkeley.edu> NNTP-Posting-Host: ack.berkeley.edu Organization: cypherpunks Lines: 2 From: cypherpunks(a)toad.com Distribution: world Newsgroups: alt.test Date: 6 Feb 1995 19:34:19 GMT test test

1 0

Email Add's of Senators?
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Anyone have a list of these? Do they exist? It would be very helpful if they do and someone has a list or a pointer to a list, as my campus is gearing up a petition signing campaign against this S.314. Thanks in advance, - -Jaeson -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLzjdKObIUsJnAZfNAQEknwQA1malQkHdtMdX5okXYd2W/nY29gWr+ICM cflNswC7ABV3wtmkMEACxP1geLXHI7zyqRWF3h6z23eqeOycYVZTfNKwDD8DykW0 fV+kru2dMuhhRihvTmH6ztdF9QCfB4LIAN38+GP0H0NFkRgZUs8dIXcHJh//pSec F5bt7iDjwXw= =vjyH -----END PGP SIGNATURE----- _____________________________________ {-: 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: USPO & Digital Postage/E-Cash Project
by haeberli＠apple.com 17 Dec '03

17 Dec '03

Dale, I would appreciate any citations you can offer which: -Describe the proposed system in some detail -Describe the weaknesses identified by the CMU team. Also, this group might want to know that CMU has (perhaps independently) done work in this area over two years ago. It may well be that the team at CMU which did the USPO contract research is the same team that proposed digital postage in a research paper in that time frame, and it may well be that their system would withstand a much more rigorous attack. I'm afraid I've lost the precise citation, but I found the report browsing the CMU tech reports server about 18 months ago. Martin At 10:25 PM 02/07/95, Dale Harrison (AEGIS wrote: >The US Post Office just killed a project that would have created a >digital postage/e-cash system. This would have been a digital >replacement for the Pitney-Bose style Postage Metering machines. To use >a PM machine one has to take the entire machine physically to a Postal >Station and purchase some fixed dollar amount of postage. The Postal >clerk unseals and unlocks the machine, dials in the amount of postage >purchased and then relocks and reseals the machine. > >This mechanical system would have been replaced by a serial-port dongle >and a piece of software. The dongle would contain an EEPROM in a >replacable button (made by Dallas Semiconductor) into which would be >loaded data indicating the amount of postage that had been purchased and >not yet used. The software package would be able to print the address, >postage seal, routing codes, etc directly on the envelope via a laser >printer and decrement the amount of available postage left in the >dongle. In the original test, customers would have to take the dongle >to a Postal Station to purchase additional postage, but the ultimate >goal was to have been to have a commerical dial-up service available >that one could dial into and purchase additional postage directly. > >A proof-of-concept prototype was developed in VB and a production >prototype was then developed in VC++. Unfortunately the crypto wasn't >very strong. The USPO contracted with Carnege-Mellon to try and break >the system and they were able to within a couple of weeks. USPO then >killed the project. > > >Dale H.

1 0

Re: Seals and Sealing Waxes
by System Operator 17 Dec '03

17 Dec '03

chen(a)intuit.com (Mark Chen) writes: > with the requisite proclivities). I only have a hardcopy, though if > enough people are interested, I might be persuaded to scan some of it > in. This appears to be an appropriate point for me to extend an offer to scan any cypherpunk material for this list and/or achives that may be appropriate. I have a Hewlett-Packard ScanJet IIcx with the Automatic Document Feeder attachment, and Caere's OmniPro OCR software, as well as Microsoft Office and WordPerfect 6.0. Dan dan(a)decode.com -- system(a)decode.com (System Operator) Cryptography, Security, Privacy BBS +1 410 730 6734 Data/FAX

1 0

Re: MIME based remailing commands
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

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

1 0

Re: Seals and Sealing Waxes
by kkirksey＠world.std.com 17 Dec '03

17 Dec '03

Message-Id: <v01510102ab5ecd95ffb0@DialupEudora> -----BEGIN PGP SIGNED MESSAGE----- > "All crypto is economics," and this is what made seals and sealing wax so > useful for so long. Saying "seals were duplicatable from the start" does > not mean this feat was easy, even if technically possible. > > In fact, the fine details produced by a good seal are hard to exactly > emulate with a copy. Even on a two-dimensional surface. And with the advent > of three-dimensional surfaces, which sealing wax made possible, the fine > detail of a good seal was in fact very hard to forge. But not impossible. According to Kahn, the Austrian Black Chamber was quite adept at forging seals in the late 1600's / early 1700's. They were able to take sealed correspondence in at 7 a.m., unseal it, copy the message, re-seal it, and have it back in the postal stream by early afternoon. There was only one recorded case of them re-sealing a message with the wrong seal, and that was because the seals were so similar. All this is from memory, since I don't have my copy of _The Codebreakers_ here at work, so I may be off in some details. Ken = Ken Kirksey And the Clinton administration launched an attack on = = kkirksey(a)world.std.com people in Texas because those people were religious = = Mac Guru & Developer nuts with guns. Hell, this country was founded by = = religious nuts with guns. - P.J. O'Rourke = -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzkeVusZNYlu+zuBAQG5HgP+LuE0aOG6UxgZp/IrZCm2y9ESi9AT13v+ ePMulQHUXUv8cc4m0RTjD35+cmKSKADrP6L1oC6BCia+5d3Rhidh2KcqaoQZQLvc rSuXbPgUpM7VJBOELtxc68CLJTpyaHBHvORJ//xH+/kN/++2f110+hZMwvgynrRd Pj54hvqthKA= =Jhff -----END PGP SIGNATURE-----

1 0

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