- cypherpunks-legacy@lists.ogf.org

IETF + PEM = Internet Commerce
by L. Detweiler 10 Sep '93

10 Sep '93

Report: the IETF (Internet Engineering Task Force) is very pro-commerce and recently met in Amsterdam for a session to discuss Internet Mercantile Protocols (IMP). It would allow consumers & companies on the Internet to combine PEM and MIME to complete and automate commercial transactions. J. C. Davin, previously of Bellcore helped initiate the IMP project. He envisions a standard that would allow companies to sell data such as image files or software. Another approach being considered would allow a sort of `home shopping network' approach. Meeting m Amsterdam minutes can be found at thumper.bellcore.com. Directory path: pub/devetzis/imp. Get: imp-archive. Mail me for more information. - - - On a related note, Bob Metcalf of IETF and columnist for InfoWorld was on NPR recently and talked about the `pampered elite' of people with Unix machines that are currently using the internet. The comment was clarified to mean that a vast audience of people with PCs and Macs and other low-end computers are mostly unconnected. IETF membership info appended. He shows a strong commitment to: 1) increasing address space for participants of the next century - `upgrading in one of the biggest cutovers since Great Britain decided to drive on the right side of the road' 2) exploiting ATM with ``cell-based protocols, operating systems, and applications. Otherwise, the Internet stays stuck in its current 20-year-old ASCII-bound applications -- TELNET, FTP, and E-mail.'' 3) strong support for *individual* subscribers vs. the current institutional monopoly, with ISDN playing a central role 4) he's in favor of usage billing as a critical aspect of commercial development. ``Internet carriers must be able, as are telephone companies, to settle with one another for traffic carried on behalf of each other's customers.'' From: "Bob Metcalfe" <Bob_Metcalfe(a)ccgate.infoworld.com> >if you want to join the Internet Society, as I just did, >to keep in touch with how the third generation is coming along, it costs $70 >per year and gets you the quarterly /Internet Society News/. Call >703-620-8990.

1 0

Re:Crypto Visions
by nobody＠pmantis.berkeley.edu 09 Sep '93

09 Sep '93

Hey Nick, visionary stuff in general, but . . . szabo>* Internet Casino: why travel to Las Vegas or Monte Carlo when szabo>you can play the finest games in the privacy of your own home? Maybe it's time you stopped working on the CRT tan, and checked out the showgirls :-). There is *virtually* nothing like it.

1 0

REMAIL: cache
by nobody＠Menudo.UH.EDU 09 Sep '93

09 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, This is a test message of the caching implementation I've added to the remailer elee9sf(a)menudo.uh.edu. If you are reading this, it should be working :-) I implemented caching with three extra scripts: filer.pl, mailout.at, and mailout.pl. filer.pl accepts incoming messages and files them into a queue directory, appending the time in seconds, minutes, hours, and the process id number to the file. Hopefully, this will store the file in a random order with respect to the actual order they arrived in. Instead of piping incoming mail to slocal.pl, which is what the typical cypherpunks remailer does, it is piped to filer.pl which just files the messages. mailout.at is a script for the at command. It invokes the mailout.pl command, which mails out the queued messages, and reschedules itself for midnight the next day. Today, I scheduled for 18:00 CDT, so this message should leave for cypherpunks(a)toad.com then. I forgot to check to see if I'm in cron.allow; if so I'll change from the at command to a crontab. For the time being the remailer "flushes" its queue every night at midnight. After a while I'll make it less often, perhaps every other day or every three days. A week is probably too long :-) mailout.pl is a script which opens the queue directory and gets a list of files. Every file in the directory is opened, piped to slocal.pl, and unlinked. Well, that's it in a nutshell. Next up: padding messages, and an smtp package instead of sendmail. <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLI+wM4OA7OpLWtYzAQGM2wQAulXlIz50z6fVPdWeHstdyFA5GgeCPUaO XRWooj0PNPPRrAcfUQqFhhgTZibBDHP6qmOXGU4GWfYL6dqPJhCHTi6iBUOGWQ+2 K1+YHinz7h6vNTf1R9fCRElvH0tn5iwq3uR4ZWLqJhhxtD6Mv01qidOsUQIUfQ9G oN2lT+JrkeU= =RdzB -----END PGP SIGNATURE-----

1 0

encryption
by Cdt Pvt Dan Doughty 09 Sep '93

09 Sep '93

sub cypherpunks Daniel J. doughty

1 0

blank lines v. the remailer
by collins＠newton.apple.com 09 Sep '93

09 Sep '93

> Upon repeated tests of my remailers, I noticed that if there's >more than one blank line between the header and the header-pasting, then >the pasting doesn't take place. Does this happen with other people's >remailers? How is your script different from mine? How can this be fixed? What follows is some of the text of the recurse.pl script, a component of the remailer system. I imagine that there are different versions of this script floating around, but this is the version I got from soda.berkeley.com when I set up my remailer. I have commented it (and noted my comments with 'SC:') to explain the relevent behavior, and deleted non-relevent sections: ----------cut here---------- # SC:read the header, looking for relevent lines while (<>) { # SC:get the next line (from where ever) into $_ s/[ \t\r]*$// ; # SC:remove trailing white space from $_ last if /^$/ ; # SC:get out if this line ($_) is otherwise blank ...code deleted here... } # SC:at this point $_ contains the blank line that followed the header # unless there was no blank line or message following the header (bad message) # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::[ \t\r]*$/ ) { # SC:get the next line (from where ever) into $_ ('if' can't use 'while' # magic form), and if that next line is the pasting token then... # SC:append all the folling lines (up to, but not including, # the next blank one) to the header while (<>) { ...code deleted here... } } ...code deleted here... ----------cut here---------- You can see (from the condition of the 'if') that this code only finds the pasting token if it is separated from the header by exactly one blank line. This is easy enough to fix, if it is not the desired behavior, by inserting while (<>) { last unless /^[ \t\r]*$/ ; } before the 'if' and removing the '($_=<>) &&' from the if condition. Hope this helps, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

REMAIL: Perl/problems
by Sameer Parekh 09 Sep '93

09 Sep '93

I'm not good at perl, so I can't solve this problem on my own. (I hardly know anything about perl, actually.) Upon repeated tests of my remailers, I noticed that if there's more than one blank line between the header and the header-pasting, then the pasting doesn't take place. Does this happen with other people's remailers? How is your script different from mine? How can this be fixed?

3 2

DES is Dead
by Philip Zimmermann 09 Sep '93

09 Sep '93

Forwarded message: >Date: Thu, 09 Sep 1993 10:23:00 +0000 >From: "Michael (M.J.) Wiener" <wiener(a)bnr.ca> >Subject: re:fw:DES is Dead >To: prz(a)acm.org > >Philip, > >I'm pleased that my paper is getting some attention. However, there >were a few things in your note below that concerned me. > >The first is minor. My last name is spelt "Wiener" - I've always been >a little touchy about that. > >The second is that not only have we not built this machine, but we >have no intention of doing so. To say that the chip is ready for >fabrication may mislead people about our intentions. This is >strictly a detailed paper design. > >Finally, I don't think that DES is dead. After about 15 years of >public scrutiny, we can conclude that DES is a well designed cipher >with a well understood limitation (56-bit keys). A natural >replacement for it is triple-DES. Proclaiming the death of DES >may lead to its being replaced with an entirely new cryptosystem >(e.g. Skipjack). > >I'd appreciate it if you would send a clarification (particularly on >the second point) to the audience that received the message below. > >Thanks, > >Mike Wiener > > >>From: Philip Zimmermann <prz(a)columbine.cgd.ucar.EDU> >>Subject: Re: DES Key Search Paper (fwd) >> >>Michael Weiner presented a paper at Crypto93 that describes a fast DES >>key search engine that uses a special inside-out DES chip that he designed. >>This chip takes a single plaintext/ciphertext pair and quickly tries >>DES keys until it finds one that produces the given ciphertext from the >>given plaintext. Weiner can get these chips made for $10.50 each in quantity, >>and can build a special machine with 57000 of these chips for $1 million. >>This machine can exhaust the DES key space in 7 hours, finding a key >>in 3.5 hours on the average. He works for Bell Northern Research in >>Ottawa, and says they have not actually built this machine, but he has >>the chip fully designed and ready for fabrication. >> >>This is a stunning breakthrough in the realization of practical DES >>cracking. BTW-- note that PEM uses straight 56-bit DES. >> >>$1 million - 3.5 hours >>$10 miliion - 21 minutes >>$100 million - 2 minutes >> >>It is not plausible to me that NSA's budget for examining DES-encrypted >>traffic is less than $100 million. Two minutes. DES is dead, dead, dead. >> >> -prz >>

1 0

Re: REMAIL: pasting
by doug＠netcom5.netcom.com 09 Sep '93

09 Sep '93

hughes(a)ah.com (Eric Hughes) said: >Yet RFC-822 is followed as much in the breach as in the observance. Not only that, but it is woefully shortsighted. For instance, when I reply to messages from email lists, sometimes I want to reply to the list, and sometimes to the originator. The variations in RFC-822 *compliant* email list headers are staggering; I have yet to see any mail software that understands the variety of syntactically- parseable signals that show that something is from a list, and allows me to easily reply to either the list or the sender. This is a technically trivial wish. It could be done, at least to the 95% mark, even as things stand. But NOOOOOoooo. :-) Similar comments apply to saving things interactively. I'm about to try procmail for non-interactive uses, but I still haven't seen a mailer that lets me say e.g. "(save (from cypherpunks | to cypherpunks | cc cypherpunks | Bcc cypherpunks | "From " cypherpunks) > savefile) & delete Maybe I'm just email-challenged. Suggestions? Doug

3 2

Subscribe
by desilets＠sj.ate.slb.com 09 Sep '93

09 Sep '93

Please subscribe desilets(a)sj.ate.slb.com (Mark DeSilets) Thanks Mark

2 1

No Subject
by Mark Batik 09 Sep '93

09 Sep '93

subscribe me again please Mark Batik | AT&T: Phones with big brother | University of Redlands | built in. | 96mbatik(a)ultrix.uor.edu "The man who does not value himself, cannot value anything or anyone" -Ayn Rand the opinions expressed are obviously too intelligent and thoughtful to be those of the University of Redlands

1 0