December 2003 - cypherpunks-legacy

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

Re: Selection key crypto protocol trial balloon
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

wcs(a)anchor.ho.att.com writes: > I'm not sure I really believe it's workable, but what it does > sound a bit like is CDMA spread-spectrum, which lets a bunch of Um no. The main thing is that what is extracted with the selection key is _different_ from what was put in... ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

Re: Not necessarily crypto but scary anyway...
by dshayer＠netcom.com 17 Dec '03

17 Dec '03

>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? Yes, this bill is real, and it passed the house resoundingly. (I don't know if the bill number is accurate.) According to the ny times, the republicans have been trying to pass this for a long time, and now they control congress. Interestingly, the ATF and IRS are specifically excluded! The bill was opposed by both civil liberties groups and gun nuts. (Hope I don't offend too many gun nuts.) The ATF was excluded as a sop to the NRA I suppose. During debate, Rep. John Dingell (MI) called the ATF "jackbooted American fascists." Way to go John! David +------------------------------------------------------------------------+ |David Shayer dshayer(a)netcom.com | |Sentient Software / Symantec shayer(a)applelink.apple.com | |"Shoot Newt." | +------------------------------------------------------------------------+

7 6

Wiretaps & terrorism
by Adam Shostack 17 Dec '03

17 Dec '03

(Why the FBI doesn't really need wiretaps) (Part of a continuing series) >From todays (Feb 8) Boston Globe, page 3 by Larry Neumeister, AP New York- the FBI was on the trail of three of the World Trade Center bombers nearly four years before teh explosion that killed six and injured 1,000, the government said yesterday. In evidence presented at the trial of Sheik Omar Abdel-Rahman and 10 others, the FBI also said it had bugged the Sheik's phone a week before the blast. The surprising testimony - a day ater a key defendant switched sides - indicated that the government had more extensive knowledge of the planning for the trade center bombing than it had acknowledged. And it reaised anew questions about why the FBI was unable to prevent the 1993 bombing, one of the most serious terrorist actions in the United States. ...

1 0

LESM - Link Encrypted Session Manager
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I finished hacking Matt's ESM to do link encryption yesterday, but for some reason the mail I sent to cypherpunks didn't get echoed back to me, so I'm sending this again. To install: get ESM and RSAREF, make sure you can compile ESM, then replace the esm.c with my hacked version and recompile. To use: same as ESM, but there's an extra option "-b bandwidth", the default is 100 cps. I've attached the modified esm.c here since it doesn't include any crypto code. To get ESM, write to cfs(a)research.att.com and state the following: - you are in the US or Canada, and - you are a US or Canadian citizen or legal permanent resident, and - You've read and understand the license and export conditions. RSAREF is in ftp://rsa.com/rsaref/ Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzqTtTl0sXKgdnV5AQEmbgP8CRxE+RCGsDXwwShWhZKGytSywyWZ8RXB RPBHZmk6UgdpCR2VVo8wXjcPuEv4SHp9ZjhFTq53JZ/s3YcV5FxF33/ivSlh1Ra4 P8GSYnoEaIJoFrJyagukbBUaY6zWCx0PcnsLoVArCxujwRYwfrQvHdiNx13z7bJh OSEhhoE9djg= =PY8P -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ? This message contains a file prepared for transmission using the MIME BASE64 transfer encoding scheme. If you are using Pegasus Mail or another MIME-compliant system, you should be able to extract it from within your mailer. If you cannot, please ask your system administrator for help. ---- File information ----------- File: lesm.c Date: 8 Feb 1995, 23:57 Size: 19769 bytes. Type: Text

1 0

Re: lwall
by EFN Autoresponder 17 Dec '03

17 Dec '03

DO NOT PANIC! REMAIN CALM! READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET! Your Usenet test article was received here at the news gateway machine for Oregon Public Networking, located in Eugene, Oregon, USA. The OPN newsadmins can be reached via e-mail at usenet(a)news.efn.org. 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. Or you can just ask us to mail you a copy. 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. There are typically 5 possible reasons why you were sent this e-mail message: 1) You intentionally posted a Usenet news article to a *.test newsgroup. These newsgroups exist so you can verify that your articles are being propagated correctly. When your article arrives here, we send you this message as confirmation. We will only send you ONE e-mail reply for each of your test articles that we see. 2) You unintentionally posted a Usenet news article to a *.test newsgroup. This is a bit of net.childishness caused by a Followup-To: header directing all replies into a *.test newsgroup. This is done by somebody upset with the content of a discussion thread who wants to "punish" anybody who replies to his message. Your reply will be sent to *.test instead of the original newsgroup, and you will start receiving autoresponder messages similar to this one that you didn't ask for. To avoid this in the future, look for a Followup-To: header and make sure it's appropriate before replying to any articles. 3) You were a victim of a Reply-To: header directing your e-mail into a *.test newsgroup via a mail->news gateway. Similar to 2) above. 4) Somebody has forged a posting in your name to one of the *.test newsgroups. To avoid this in the future, use better net.etiquette and you will make fewer net.enemies. If you want to try and identify the forger, use the following procedure. Make a legitimate posting to the same *.test newsgroup that the forger used. We will send you an e-mail reply. Compare the Path: header from this legitimate reply with the Path: header from the forgery. The front part of the two headers will be the same or topologically similar path to your site. Where the forged header becomes substantially different can provide clues to where the forger lives. Note that if you receive multiple newsfeeds you may need to repeat this process several times so you can discover all legitimate paths between our site and yours. Once you think you've identified the forger's site, try sending POLITE e-mail to the newsadmin/ sysadmin/postmaster explaining the situation. 5) You issued a cancel control message to a *.test newsgroup. Some users dislike autoresponses for cancel messages, but the newsadmins here think it can be a valuable diagnostic tool for verifying cancel propagation. If you don't like it, use the "delete" key in your mail client! All headers plus at most 10 lines of user text from your original article are reproduced below for your perusal: Path: mars.efn.org!cs.uoregon.edu!news.uoregon.edu!vixen.cso.uiuc.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

Four Horsemen
by kkirksey＠world.std.com 17 Dec '03

17 Dec '03

Message-Id: <v01510101ab5ecb0e67cd@DialupEudora> -----BEGIN PGP SIGNED MESSAGE----- Just a quick question: someone asked me the other day what the "Four Horsemen of the Infocalypse" were, and I told him 1) Drug Dealers 2) Terrorists 3) Pedophiles 4) Pornographers Did I get it right, or did I have a synaptic misfire somewhere along the line? 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 iQCVAwUBLzkbhOsZNYlu+zuBAQHVigQAzkp3fIlEfT82zSaRZPkIqkkaDJ5MNyRK SOOq0QwAMB1/bGNGda0plC+aNGT1RnSpNJTS/8ISIJTDCwbmJGFYGxvRSgqyUkXO dQrd6pLbYIxH1sTPIaAoM4BnmUhYzr5L4TauPgqTLYhqGKDa8RWbHggjLyTr/UfF drRgBOM919Q= =OcUi -----END PGP SIGNATURE-----

2 1

Judges-L FAQ
by Craig A. Johnston 17 Dec '03

17 Dec '03

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. -Craig

3 2