- cypherpunks-legacy - lists.cpunks.org

Tempest@home?
by J. Michael Diehl 05 Jun '93

05 Jun '93

I'm really intrigued by the technology known as TEMPEST. If a guy had a mind to, is it possible to put together a do-it-yourself "tempest-aware" machine? That is, could a guy buy supplies that would make his machine "quiet?" If so, would someone please tell me how! This would be very usefull to many cypherpunks and would be of (IMHO) general interest. Thanx in advance. BTW, this message was mailed by my pgp-aware, automatic mail script. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

Dig. Cash Question.
by J. Michael Diehl 05 Jun '93

05 Jun '93

I'm reading the paper that was announced on this list about Digital Cash last week. It was writen by Stefan Brands. I think I have a strong Math background, but I don't know what is meant by a "descrete log" in a group G. I understand what a group is. I just don't know what properties an element, a, would have if it were the log sub p of e. Can someone help me. Otherwise, this is a very interesting article. Thanx in advance. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

Anon.penet.fi and penet.anonymous.net
by Johan Helsingius 05 Jun '93

05 Jun '93

Since I announced my intention to re-establish the full anon.penet.fi service, I have received several messages with very valuable and useful ideas. I just want to clarify my situation. What I'm doing now is to simply re-establish the old service, without any changes/improvements (except for an AUP-free connection and a faster box). This gives me time to work on the improved Mk II with support for PGP, multiple ID's, selectable double/single blind etc. I expect to bring up Mk II as penet.anonymous.net this fall, but I need some time to implement the stuff, write documentation etc., and I have to take care of my "daytime" jobs as well. Somebody has to pay for all that new hardware and that international connection... Not mentioning my rent ;-) Julf

1 0

Software infrastructure
by nobody＠shell.portal.com 05 Jun '93

05 Jun '93

In thinking more about Eric's proposal for a terminal program, I can see the value in putting in the hooks for stream encryption even if we don't implement it right away. That should be one of the points of this software, to have it be easily expandable. So we would want to make it so that a layer could be inserted just above the serial I/O layer which would do transparent encryption. The mechanism for creating the shared keys could be added later, perhaps. We are seeing a lot of different suggestions here, which is good at this point. Some of the issues: Overall functionality To keep our focus: we want something which will help the average computer user who has a PC or something similar at home be able to use encryption easily in sending and receiving email. The problem is that people send and receive mail in very many different ways. So we propose to provide a very flexible and extensible solution that can be adapted to many situations. This leads to the idea of a terminal program with built-in encryption, since most people can use a terminal program to get their mail. This would not be aimed at people running UUCP or similar fancy protocols on their home machines. They must be pretty sophisticated to get this stuff working. PGP and RIPEM already come with a bunch of scripts to let them be used in Unix and similar environments. (Maybe I'm mistaken, though, in thinking that good solutions already exist for these people. I don't know much about this mode of operation.) Build or Buy Do we roll our own or do we try to tap into an existing program? Among existing terminal programs, do we: try to provide add-ons to widely used commercial or shareware programs (for which we don't have source); try to convince the authors of these programs to make the changes we desire; or find such a program which has source available (e.g. kermit) and take that as our starting point? Target OS We have seen suggestions for DOS, Windows, Unix, and Linux (about which I know nothing). DOS and Windows are the biggest target market and the most likely to be used by the naive users we are trying to help, IMO. It would not be too hard to write for DOS but to isolate the OS dependencies so it could be easily moved to Unix (and perhaps Linux). But the DOS vs Windows decision is more fundamental. More generally, it is the command-line vs GUI decision. It's very hard to write code which is portable across these two approaches. I would lean towards the command line approach because it is easier to write portable code, in my experience (portable between DOS and Unix, say, is easier than portable between Windows, X, and Mac). But just fixing on Windows is another option. Serial Interface Focusing on DOS, apparently there are several ways of interfacing to the serial port. I know nothing about these. The main issues would be portability - does it require the user to have some third-party software, or to run on only a limited subset of PC clones - and efficiency - can we run at 9.6 or 14.4 Kbaud? What solutions accomplish both of these? And what if we went with Windows? Does that narrow our options? User Interface I still think this is one of the harder issues. How exactly can we make this easy to use? Can anyone suggest a non-magical (e.g. no mind-reading) but still ideal interface for encryption? I kind of liked Greg's suggestion of using the rollback buffer for decryption - when it sees an encrypted message go by it automatically decrypts it and offers it to the user to see. I'm not exactly sure what you do with it then, though. It would be helpful for me to hear more about how people read and send mail on their home computers, in some detail. If Mike Diehl got enough responses to his survey that would be good to hear about, too. Hal Finney 74076.1041(a)compuserve.com

4 6

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