June 1993 - cypherpunks-legacy

Re: Lobbying for Cryptoprivacy, non-U.S.
by haahr＠mv.us.adobe.com 05 Jun '93

05 Jun '93

> In smaller countries this will be easier since its doubtful > small governments can set up a spook/chip-maker axis to rival the > NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., > cooperating major European countries and Japan have such a capability. what about Canada? or has it been absorbed into the US? :-) Russia probably has the chip-making skills (and, certainly, the spookish ones) to fit, but they probably count as a ``cooperating major European countr[y]'' now.

2 1

chain.zip uploaded
by nobody＠soda.berkeley.edu 05 Jun '93

05 Jun '93

I just put chain.zip into the /pub/cypherpunks/incoming. This is source and an MSDOS executable for the "chain" utility I mentioned last week, which works similarly to Karl Barrus's scripts for sending messages through several remailers. This program includes options for encrypting the message for the recipient, and if run on a Unix system it can automatically send the message to the first remailer in the chain. I'm going to be off the list for a few days for personal reasons, but if anyone has any comments or problems with the program, let me know and I'll look into it when I get back. Hal Finney 74076.1041(a)compuserve.com

1 0

INFO: .forward
by elee9sf＠Menudo.UH.EDU 05 Jun '93

05 Jun '93

> Would someone explain how to do this. I need an idiot's > description. I tried to get my mail to go through a filter > once....twice actually. Never did get it to work. Well, I'll give it a shot. Sendmail optionally reads a file in your home directory named .forward, and follows the instructions there. Typically, a .forward contains another address, in which case mail sent gets forwards to the address in the .forward file. For example, my .forward file on tree.egr.uh.edu is elee9sf(a)menudo.uh.edu so any mail sent to barrus(a)tree.egr.uh.edu gets forwarded to elee9sf(a)menudo.uh.edu. A more interesting application is to forward your mail to a command (pipe mail to a command). In that case, the .forward file reads "|/path/mycommand options" and mail gets piped to mycommand for further processing. For instance, the vacation program works by piping incoming mail to vacation, which both files and responds for you. Also, the cypherpunk remailers work by using a .forward file to pipe incoming mail to the scripts which make up the remailer. Yet another example is the slocal program which is part of the mh mail system; incoming mail gets piped to slocal, which in turn relies on a configuration file (.maildelivery) which contains instructions for handling the mail. My idea was to have all mail sent to barrus(a)tree.egr.uh.edu piped through pgp and then mailed to elee9sf(a)menudo.uh.edu. The rough idea is to do this: "|/path/pgp -fea barrus | mail elee9sf(a)menudo.uh.edu" Here, incoming mail gets piped to 'pgp -fea barrus' which encrypts the message with my public key, and the result is piped to 'mail elee9sf(a)menudo.uh.edu' which then mails the encrypted result to me. For various reasons I'm still exploring, this didn't work (even with PGPPATH set, piping to a script, etc. I've got more things to try to see why it isn't working.) on the NeXT. So, I tried to do this from the menudo.uh.edu side. Using the slocal program and the associated .maildelivery file, I have mail which comes from barrus(a)tree.egr.uh.edu (remember my mail from tree is forwarded to menudo) piped through 'pgp -fea barrus' and then the result is piped into an mh command which stores the mail in a folder. Of course, this isn't a substitute for end-to-end encryption. Here, mail travels all the way to me before getting encrypted, so if somebody wanted to snoop me they could just stand between the sender and my account and eavesdrop. A better solution would be to have the sender encrypt the message! But as I mentioned I was trying to set this up so that replies to a USENET posting got encrypted before finally getting dropped on menudo. An improvement would be for me to get the encryption and remailing working on the NeXT, but again, this is inferior to having the sender encrypt in the first place. You mentioned trying to put your mail through a filter - were you trying to use the filter command of elm? Sometimes you have to watch subtle things like file permissions (slocal will not use a .maildelivery file that is group or other readable) or pathnames (try putting the fill path names when you use commands). /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

1 0

THANKS: pgp, mh, .forward
by Karl Barrus 05 Jun '93

05 Jun '93

Thanks Hal, Stanton, Miron - I finally got it to work, on the menudo side, not the NeXT. I don't know what the deal is with the NeXT; 'cat .plan | myscript' worked (myscript had all the necessary stuff) but having this .forward file didn't: "|/bigpath/barrus/myscript" But, I got it to work from menudo with this in my .maildelivery file: to "barrus(a)tree.egr.uh.edu" | A "PGPPATH=/fajitas/elee9sf/Crypto/pgp22 /fajitas/elee9sf/bin/pgp -fea barrus | /usr/lib/mh/rcvstore +fromnext" Mail sent to barrus(a)tree.egr.uh.edu gets piped through pgp, encrypted, and then stored in the mail folder 'fromnext'. The PGPPATH did seem to be the missing factor! Now, for those who wonder why in the world I'd want to do this... I've been involved in a quasi-flame session on USENET (in comp.admin.policy and other cross-posted groups) concerning a student who was suspended here. My posts became more and more sarcastic, and as I was contemplating sending out a post which may have been on the edge, and not wanting to make the sh*tlist here - or get higher up on it :-) - I was going to route it through penet from my tree account. But then responses to the post would have eventually been dropped here on menudo, since I have my mail forwarded. Now I'm not suggesting that the admins here are watching my mail, but it wouldn't be difficult for the admins to do some traffic analysis (crypto sophistication!), noting that Karl's mail file grows coincident in time and size to responses to XYZ post... enter encryption! So it would be better to get the encryption going on the NeXT side, but this solution is good enough for me. Final note: I forgot penet is restricting posts for the time being, but in any event this system is working.) /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

3 2

(fwd) NIST CSSPAB Resolutions 6/4/93
by tcmay＠netcom.com 05 Jun '93

05 Jun '93

Here's something important from sci.crypt! -Tim May Xref: netcom.com alt.privacy:7178 alt.security:9808 comp.org.eff.talk:18101 sci.crypt:15143 alt.privacy.clipper:555 Path: netcom.com!netcomsv!decwrl!elroy.jpl.nasa.gov!usc!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!eff!wilson.eff.org!Banisar From: Dave Banisar <Banisar(a)washofc.cpsr.org> Newsgroups: alt.privacy,alt.security,comp.org.eff.talk,sci.crypt,alt.privacy.clipper Subject: NIST CSSPAB Resolutions 6/4/93 Date: 5 Jun 1993 00:48:11 GMT Organization: CPSR Washington Office Lines: 101 Distribution: world Message-ID: <1uoqgb$peg(a)kragar.eff.org> NNTP-Posting-Host: wilson.eff.org X-UserAgent: Nuntius v1.1.1d17 X-XXMessage-ID: <A8356712AB01AC7F(a)wilson.eff.org> X-XXDate: Fri, 4 Jun 93 01:54:42 GMT NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. competitiveness in the world market and are not inhibiting the foreign production and use of cryptography (DES and RSA) - The Clipper/Capstone proposal does not address the needs of the software industry, which is a critical and significant component of the National Information Infrastructure and the U.S. economy. - Additional DES encryption alternatives and key management alternatives should be considered since there is a significant installed base. - The individuals reviewing the Skipjack algorithm and key management system must be given an appropriate time period and environment in which to perform a thorough review. This review must address the escrow protocol and chip implementation as well as the algorithm itself. - Sufficient information must be provided on the proposed key escrow scheme to allow it to be fully understood by the general public. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (e.g., three "escrow" entities, one of which is a non-government agency, and a software based solution). - The economic implications for the Clipper/Capstone proposal have not been examined. These costs go beyond the vendor cost of the chip and include such factors as customer installation, maintenance, administration, chip replacement, integration and interfacing, government escrow systems costs, etc. - Legal issues raised by the proposal must be reviewed. - Congress, as well as the Administration, should play a role in the conduct and approval of the results of the review. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg(a)washofc.cpsr.org ======================================================= -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it.

1 0

Software infrastructure
by nobody＠soda.berkeley.edu 05 Jun '93

05 Jun '93

From: Hal Finney, <74076.1041(a)compuserve.com> Mike Diehl's system sounds pretty good to me. You can create messages, encrypt them, upload and send them, as well as downloading, decrypting, and reading messages, all with a nice menu-based interface. That's what we want, right? It sounds like the system would be easily adaptable to other types of hosts, too. BBS operators could customize the scripts for their particular systems and offer the package. We could create versions for users of other mail packages than elm on Unix systems, as well as for some of the commercial systems. You could cover a lot of people this way. > Well, if you have followed my this far, you either crazy or interested. ;^) > It puzzles me why we are contemplating writing our own comm package when so > many good ones are out there that can be made to serve our purposes. I'm > open to comments..... Fire away! The only real problem I see is the use of Telix. How much does this program cost? We can't give away a disk with Telix on it. What about Kermit? It's free and it has a scripting language, but it doesn't sound nearly as advanced as Telix's. Would it be good enough? Or are their other free programs which we could use? If we could adapt Kermit or some other free program to do what Mike is describing, we could give away floppies with secure and easy-to-use encrypted email handling capabilities, as well as making them available on the net. People could just get the version they need for their particular mail access.method. The package would include the communication program, the scripts, and the encryption software. The user interface would be as Mike described, all menu driven and easy to use. I think this would be a good way to go if we could get past the hurdle of finding a free comm program that would be adequate. Note added in proof :) Eric mentioned concerns about reliability. Scripts can in principle be made flexible enough to handle many sorts of errors. You just need a lot of states and a lot of result checking. This technique of automatically attaching to a host system and downloading data is widely used by computer novices. I just saw an ad today for a product which lets you create your own "newspaper front page" graphically, then will log on to Compuserve and fill in the news, sports, and business figures you have specified, and do so at regular intervals, automatically, running in the background. I often use a package called Tapcis which automatically logs onto compuserve, getting my mail and sending new mail, reading various topics of interest that I have selected. I used to use a Mac program called Navigator which did the same. Granted, none of these are scripts, they are all custom programs, but the kinds of checking they do should be doable in scripts as well. (I wasn't sure whether Eric's point was that high level scripting languages are excessively clumsy, or the more general point that automated mail access was the wrong way to go. I am addressing the latter here.) Hal

4 4

NIST CSSPAB 6/4/93 Resoluti
by Dave Banisar 05 Jun '93

05 Jun '93

NIST CSSPAB 6/4/93 Resolutions NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. competitiveness in the world market and are not inhibiting the foreign production and use of cryptography (DES and RSA) - The Clipper/Capstone proposal does not address the needs of the software industry, which is a critical and significant component of the National Information Infrastructure and the U.S. economy. - Additional DES encryption alternatives and key management alternatives should be considered since there is a significant installed base. - The individuals reviewing the Skipjack algorithm and key management system must be given an appropriate time period and environment in which to perform a thorough review. This review must address the escrow protocol and chip implementation as well as the algorithm itself. - Sufficient information must be provided on the proposed key escrow scheme to allow it to be fully understood by the general public. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (e.g., three "escrow" entities, one of which is a non-government agency, and a software based solution). - The economic implications for the Clipper/Capstone proposal have not been examined. These costs go beyond the vendor cost of the chip and include such factors as customer installation, maintenance, administration, chip replacement, integration and interfacing, government escrow systems costs, etc. - Legal issues raised by the proposal must be reviewed. - Congress, as well as the Administration, should play a role in the conduct and approval of the results of the review. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg(a)washofc.cpsr.org =======================================================

1 0

Procomm and encryption
by poier＠sfu.ca 05 Jun '93

05 Jun '93

This discussion of integrating encryption with a comm package made me remember: Procomm Plus 2.0 allows "hooks" to be assigned to meta-keys. I have the exact interface hook.c around here somewhere, if someone wants me to post it. Skye -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier(a)sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ ivel' or some such. I would like to make it clear that the 'tiring drivel' that I was referring to was MY post and not the letter from Hugh and I merely intended the note to serve as a warning to people not interested in the project. I see now that it is, indeed possible that this informal not may have been misunderstood and I hope that you will understand my real intent now and not hold it against me. I am truly greatful for the help that I have received on this effort and hope that we will have another product of guerilla programming soon. Again, sorry for the misunderstanding, especially to Hugh, and keep those suggestions coming, there is work to be done... -Ryan the Bit Wallah

2 1

Lobbying for Cryptoprivacy, non-U.S.
by jhart＠agora.rain.com 04 Jun '93

04 Jun '93

>I have shied away from any "political" action against Clipper because I am >unsure how a Canadian can help... Non-U.S. citizens can lobby hard to get all phones containing key-escrow (aka wiretap) chips banned in your country. You have a very good argument: do y'all want Yankee spooks listening in on your phone calls? Make sure the following specifics are included in the legislation: * Try to get key escrow banned *in general*, instead of just from foreign countries. In smaller countries this will be easier since its doubtful small governments can set up a spook/chip-maker axis to rival the NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., cooperating major European countries and Japan have such a capability. * Be careful with the wording of the legislation; be sure to specify *key-escrow* and not any other forms of cryptography. * If political feasible the legislation should specifically encourage private, commercial forms of cryptography. Jim Hart jhart(a)agora.rain.com

5 4

Re: Term software develo
by gdale＠apple.com 04 Jun '93

04 Jun '93

>I've been thinking about what kind of an API could be negotiated >between terminal-program authors and encryption-mechanism authors. > >Suppose a terminal program looks for resources (using macintosh-like >terminology for a moment) of some type 'Encr', and load them. >It expects to find subroutines there, that the >cypherpunk can add to any conforming terminal emulator. >Something like this: > > resource #1: function initialize() -- grab resources > resource #2: function set_key(char key[8]) > resource #3: function encrypt(long block_no, char block[8]) > resource #4: function decrypt(long block_no, char block[8]) > resource #5: function finalize() -- shutdown, release resources > Woops, this is what I get by not reading all my mail before posting. I just posted the same suggestion with considerably less detail. Anyway, I second what henry says. ________________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- gdale(a)apple.com "Mind your nerve ends, love bunch" -- Dr. Caligari

1 0