- cypherpunks-legacy@lists.ogf.org

Re: Another chaining utility
by elee9sf＠Menudo.UH.EDU 05 Jun '93

05 Jun '93

Hal wrote: > I couldn't get Karl's hopmail.bat to run on my PC (not enough environment > space?) so I wrote this in C and it works OK. Say, is anybody else having this problem? I wonder what the problem is (environment space?) PLEASE let me know about bugs or problems with the scripts. I'm going to be updating the dos versions pretty soon, and will see if I can figure out what the space error means. Thanks, Hal! /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

2 1

Re: CryptoStacker, long term vision
by RYAN Alan Porter 05 Jun '93

05 Jun '93

This is tiring drivel concerning the CryptoStacker project. It just started yesterday, so don't expect it to be too mature, we all have other things we have to do to pay the rent, right? Anyway, I am posting this to the list because it is kind of a plea for ideas, among other things, there are some tidbits that we need some help on. This particular message seemed to address both of the main ones, so I picked it. Don't complain about bandwidth, ok? Alright, to summarize the needs of the project at this point--> we need: 1) some ideas on a good algorithm for a quick and easy encryption to be used in a simple straight software on-the-fly disk encryption. I know that it's ironic, but it seems that that I and the people interested in funnelling me ideas are mainly deficient in the encryption area... 2) does anybody know how the hell Stacker or DoubleStor or whatever executes the actual interception of the read/write routines and stacks them? I don't get it at all. I am more than willing to learn to get this thing working though. To summarize this message in particular: Hugh: "Hey, wouldn't bell/whistle XXXXXX be a good idea?" Ryan: "Yeah, but can we get the thing to work at all first?" There, you have it. You don't even have to read it if you're not interested... _______________ Message follows: > Here is one method of encrypting whats on a disk that I see as > usefull for some, but not all of us. There are real problems for > folks like me who have Unix systems as their home systems, but we will > leave that as a extra credit problem. Yeah, I am just concentrating on getting something out there for DOS support. I actually loathe DOS and would rather be supporting UNIX (this would be a lot easier under Unix) but DOS is still a defacto standard and the people who need to be protected will be using DOS a lot... > I see a disk drive (or scsi controler or bus interface or even > something that sits in the middle of a scsi cable) with a PCMCIA slot > in it. Data gets passed about in the clear if no (or a dummy) card is > in the slot. If a real card is in the slot then all data goes though > the card before being sent the rest of the way though the interface > (might also take the data out via the card, but that makes the card > more complex, even if the drive is cheaper, and has other problems). > The card is a key, if its in you can read the disk and see the data > and it all looks fine. If its not in and you read the disk you see > whatever is on the disk, mixed plain and/or cypher text. I like this idea, but I don't know about having ALL data go through the encryption system. What about the idea of setting up a 'secure' partition and a 'fast' partition and having a device controller that would only run stuff sent to the 'secure' partition through the crypto system? I also don't know about the practicality of making the thing easy to download your own crypto into it. I think that if I am using a DES chip that is widely understood and trusted that there would be no need for the further complication of letting people hack at it... It would be a really cool option, and it would be a lot closer to allowing people to seize their own security, but I don't think that I can justify adding such a complicated feature at such an early stage. > You now have a 'key', if you don't want the disk read take the key > out, breakit it even (if broken the card needs to erase its self as it > might be read even in this state by a electron micro scope or some > such). I really like this PCMIA key idea. I don't think that just having a key would be enough though. Say the Secret Service walks in tomorrow and my system is CryptoStacked, and the PCMIA key is dangling out of the slot because I fell asleep programming last night and forgot to take it out and put it in the safe or whatever. <poof> all of that hard earned security is naught. I am much more in favour of a password system to assist the key, much like PGP uses a password system to assist the secret keyring. > There are sevral types of cards one could use in such a system, the > ones I would like to see would have all sorts of crypto support > hardware and some sort of processer. I want to be able to download my > own crypto system into the card (which should be program ONCE), so as > I can feal safe in that I control everything that goes on. This might > be slower then doing a dedicated chip, but more usefull. Support > chips(well features) might include hardware DES,RSA, etc. to speed > things up. I am thinking mainly of finding this much rumored DES chip and trying it out on a dedicated board. I had another idea for an initial stepping stone: are ISA cards DMA mapped? If so, howabout a card that simply has the key burned into it's virtual value, but only when it is properly activated? You could easily achieve this by burning a simply program into an EEPROM, and the activation could be something like punching in a code on a keypad attached to the board or something. (this comes to mind because I have a friend that just finished burning some simple programs into EEPROMS and building a simple keycode keypad, integrating them should be a weekend project) That way, I could do the encryption in software for the specified 'secure' partition (until I can get my hands on a DES chip) using the value returned by the EEPROMs as the key. Sound feasable? > If one feals like haveing fun you might be able to use the card > remotely, by sending the data (see why I don't want the card to be the > interface) over the net and decrypting it localy, then useing it > localy or re-encrypting it and sending it back to be used at the other > end again. This is more work, but usefull! Hmm, that could work perhaps, but the main idea was to create a transparant file system encoding system for once the data already is local, there are certainly better packages out there for data transmission security than anything that *I* could cook up... Just look at the flack that the Dolphin guys are getting just for even suggesting something like that... > This would mean that the crypto key cards would need to be designed > to be usefull in disks, or as keys in CPU's. The more general the > better. I agree, but a file system CryptoStacker will be hard enough to implement in the first place, I think that I will need to worry about that first. > If one want to play around one could try to have passwords to turn > the cards on (digital text/voice, or phyical interface on the back of > the card). Ahh, should have read ahead... I like that voice recognition concept though, but that sounds kind of like a bells/whistles kind of thing too... > One problem I see with this is how low a level it works at, for > instance blocks of disk are likely to expand/shrink with ecryption, > but for this sort of interface we have to pad. Uck. Right, that is my main nightmare, what size blocks to use? I just don't quite understand how Stacker does it. the way I see it we have a serious problem because there are at least two different ways of getting data onto or off of a disk. If it was one or the other, I would be able to cope with it by intercepting that method and changing it, but there are at least two fundamentally different ways, reading by bytes and reading by variable length blocks. I'm not sure if it is possible to read by bits or not, I've certainly never needed to do so, but a good scan through the PC interrupts might be necessary... The size of a block of data would not change with DES encryption, would it? I might have a serious misunderstanding about how DES works if the size *DOES** change... Here is a though, the apparant ignorance of which is entirely due to the fact that I just don't understand at all how Stacker works on an intercpet level: How about just encoding each byte seperately, that way I could intercept the byte read/write no problem, and I could intercept the variable block read/write in a similar manner, just break it down into a series of single byte read/write cycles? Is it possible to DES encode a single byte and have it remain a single byte? Is it a reasonably secure idea? I would do some DES research, but I am mail only and it takes WEEKS to poke around ftp sites through the mail, dig? Perhaps someone could send me a nice FAQ? Perhaps someone knows of a nice method by which I *COULD* securely encode a byte to a byte and have it remain a byte using keys and such? I suppose you might have noticed by now, I am a very good software engineer, and a pretty good structure programmer, but only a good machine level programmer, and only a mediocre cryptologist, let's get all of that straight right here. > I have in the back of my head an idea for a NFS like data (in the > simple case disk) server. How this might be done is murkey to me > right now. > My first problem is deciding on where I want the decryption to > happen. We keep talking about doing it in the disk drive, but as my > example above shows there is no reason to do it that way, and it's a > lot safer to pump crypted data through a (maybe leeky) SCSI data cable > then to have it all ready decrypted. > Maybe what this is trying to tell me is that there is a trueism > about decrypting data as close as resonable to the use point (and NOT > the source) as one can. This is all well and good, but I think that getting the damned thing to work at all will be a bitch, much less worrying about perfectly optimal security... > Question is: Is there a good algorithm that can be done totaly in > software, that gains more speed & security from beside memory general > purpose decryption hardware and even more from dedicated cards? This is my question exactly, what encryption algorithm... > This is really a protocall questoin, as we should be able to change > the crypt algorithm weekly if we want (might need to do this!). Oi, please... I am worried about finding ONE algorithm, you are already thinking about implementing any number on infinities... > I wonder how this can work if I decide that I need not one, two or > three crypt keys, but hundreds! I can see that I am going to have > just a few keys for the basic disk keys (can do one per disk) in > hardware, and likely hundreds of others that can't (afford or > effectivly) use dedicated hardware for. Well I don't see why any relatively unlimited number of keys couldn't exist. As for those people that can't afford to use dedicated hardware, there is still the less secure idea of having the key stored on a floppy that would be inserted at load time and read into memory. This would have the obvious disadvantage of having the key sitting around in memory, a sitting duck (especially for people who leave their systems on all of the time, like me, as soon and the Nazis learned about systems like these then 'Run a key scanning program on the system to be confiscated' would just become step one in their procedure, would be a hole even if the keys were password protected) but it would be better than nothing at all, and the speed problems could be dealt with by using the multiple partition method that I described earlier, having a 'secure' virtual disk where all of your data goes, and a seperate 'fast' virtual disk which is unencrypted where all of your programs and such go. > Have fun, theres work to be done! > ||ugh Daniel > hugh(a)toad.com Yes, but you know, the more I think about it, the easier it looks... my two main problems right now are: 1) What algorithm? How? 2) How the hell to intercept the read/write routines? After that, the rest is just writing code. Code I can do, code is no problem... -Ryan the Bit Wallah

4 9

here ya go
by poier＠sfu.ca 05 Jun '93

05 Jun '93

heres the procomm+ 2.0 hook prog... -----snip snip----- /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 HOOK.C - Programmer's interface for PROCOMM PLUS 2.0 22 22 COPYRIGHT (C) 1990 DATASTORM TECHNOLOGIES, INC. 22 22 22 22 PROCOMM PLUS passes the "hook" program the address in memory of 22 22 the PCPLUS.PRM file structure, and the ASPECT N0-N9 and S0-S9 22 22 arrays. This sample code makes local copies of these so it can 22 22 use the small memory model and not have access those locations 22 22 directly (look at the movedata() function calls.) 22 22 22 22 This file also contains other PROCOMM PLUS information that 22 22 programmers may wish to make use of. 22 22 22 22 NOTE: This code example is written for Microsoft C, which 22 22 defaults to "word alignment" of integer size items and causes 22 22 extra bytes to be inserted in structures to insure field 22 22 alignment. Turbo C, Zortech C, and other compilers that default 22 22 to "packed" or byte alignment must be explicitly set to word 22 22 alignment (usually the -a compiler option). 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 IMPORTANT NOTICE: The concepts and the text contained in this 22 22 file are hereby released into the Public Domain for use by 22 22 programmers in developing PROCOMM PLUS-compatible code. 22 22 Programs developed using this file may be distributed freely by 22 22 programmers without any financial or legal obligation to 22 22 Datastorm Technologies, Inc. However, this in no way implies 22 22 that any other material in the PROCOMM PLUS package may be 22 22 distributed in such manner, or that PROCOMM PLUS or any other 22 22 Datastorm product may be bundled for distribution with programs 22 22 developed using this file. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ #include "stdio.h" #include "stdlib.h" #include "dos.h" /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS PCPLUS.PRM information 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ struct PARMLIST { /* line settings */ int port; /* com port, 0=COM1 etc */ unsigned int baud; /* index into baud_rate[] array */ int parity; /* parity: NOEMS = 01234 */ int sbits; /* stop bits as int */ int dbits; /* data bits as int */ /* Modem General Options */ int mdm_timeout; /* secs to wait for connect */ int mdm_pause; /* secs to pause between calls */ int abdetect; /* autobaud for dialing: FALSE/TRUE */ int ddtrflg; /* 1=drop dtr in dial dir */ char redialc; /* character to send in redial */ int cdover; /* override CD and send init string ? */ int maxcalls; /* max retries for dial dir */ /* Modem Command Options */ char mdminit[47]; /* modem init string */ char mdmcmd[25]; /* modem dialing command */ char mdmsuf[25]; /* modem dial command suffix */ char hu_str[25]; /* modem hangup string */ char ans_str[25]; /* modem auto anser string */ char no_ans_str[25]; /* modem no auto answer string */ /* Modem Result Messages */ char mdm_msg[11][16]; /* modem messages, 0-6 = connect */ /* Modem Port Assignments */ int baseaddr[8]; /* com port base addresses */ int irqnumbr[8]; /* com port irq selection */ /* Terminal General Options */ int termtype; /* terminal type */ int echo_flag; /* duplex: 0=FULL, 1=HALF */ int use_xon; /* use flow control: FALSE/TRUE */ int hardflow; /* use hasrware flow ctrl: FALSE/TRUE */ int wrap; /* use line wrap FALSE/TRUE */ int scrlflag; /* scroll page FALSE/TRUE */ int lfflag; /* add LF to CR coming in: FALSE/TRUE */ char dest_bs; /* use destructive BS: FALSE/TRUE */ int brklen; /* BREAK length in ms */ int enq_on; /* respond to ENQ: NONE/ANSWERBACK/CIS B */ int use_uline; /* 1=EGA/VGA true underlining */ int col132mode; /* 0=80 col, 1=132 col */ int ansi8bit; /* 1=ANSI 8 bit mode, 0=ANSI 7 bit mode */ /* Terminal Color Options */ int tcnorm; /* Terminal normal attribute */ int tcbold; /* Terminal bold attribute */ int tchalf; /* Terminal wrt prt/half intense attribute */ int tcrev; /* Terminal reverse attribute */ int tculine; /* Terminal underscore attribute */ /* Display/Sound Options */ int explode; /* use exploding windows: FALSE/TRUE */ int soundon; /* use sound: FALSE/TRUE */ int alarmon; /* use alarm: FALSE/TRUE */ int attenlen; /* seconds for alarm sound */ int snow; /* flag for using fast display updates */ int sline_off; /* 0=use status line, 1=use 25 lines of data */ int bigcur; /* 0=line, 1=block */ unsigned int rfarsize; /* far mem for redisplay buffer */ int startextralines; /* startup in extraline mode? */ int extralines; /* 25, 28, 43 or 50 line mode */ /* General Options */ char prtfilename[13]; /* name of PRN device */ int cd_at_exit; /* 0=ignore, 1=hangup, 2=ask */ int fastkbd; /* AT keyboard speedup */ int remcmd; /* flag for using remote script commands */ int xlatflag; /* use xlate: FALSE/TRUE */ char xlatps; /* pause character */ int keypause; /* pause between chars in ms */ int nophonelog; /* flag for using phone log */ int filelu; /* flag for using auto filename lookup */ int use123; /* use lotus menus ? */ char key123; /* lotus menu key */ int dtrflag; /* drop DTR in hangup: FALSE/TRUE */ int page_is_xfer; /* 1=PgUp/Dn xfer, 0=Ctrl-PgUp/Dn xfer */ char chat_blk_mode; /* flag for char/block mode in "chat" */ /* Host Mode Options */ int hardwire; /* host connection type: MODEM/DIRECT */ int autobaud; /* use autobaud in host mode */ char host_id[51]; /* host welcome string */ int opensys; /* host is open system: FALSE/TRUE */ char hostup[51]; /* host mode upload default dir */ char hostdn[51]; /* host mode download default dir */ int hosttimeout; /* host inactivity timeout (in minutes) */ int hostbyemode; /* what to do after end of call */ int hostnewuserdl; /* can new user xfer files? */ /* File/Path Options */ char log_name[65]; /* default log file name */ char scr_name[65]; /* default screen dump fiel name */ char dl_path[65]; /* default d/l path */ char viewname[65]; /* view prog name */ char ed_name[65]; /* editor name */ /* Color Options */ int hmclr; /* colors */ int hmhi; int pdclr; int pdhi; int slclr; int slhi; int tcclr; int tchi; int xclr; int xhi; int ddclr; int ddhi; int kmclr; int kmhi; int pmclr; /* colors for pulldown menus */ int pmhi; /* colors for pulldown menus */ int pmrev; /* colors for pulldown menus */ /* ASCII Options */ int ascii_echo; /* echo ascii uploads: FALSE/TRUE */ int blankx; /* expand blank lines in ASCII uploads */ int tabx; /* expand tabs in ASCII uploads */ int cpace; /* char pace time for ASCII uploads */ int pchar; /* pace character for ASCII uploads */ int pace; /* line pace for ascii u/l */ int up_cr; /* CR define for ascii u/l: */ int up_lf; /* LF define for ascii u/l: */ int dn_cr; /* CR define for ascii d/l: */ int dn_lf; /* LF define for ascii d/l: */ int strip8; /* strip 8th bit in ASCII xfers */ int ascii_dl_to; /* auto timeout value for ascii dloads */ /* Kermit Options */ int srpsiz; /* kermit stuff */ char spadchar; /* kermit stuff */ int ksoh; int spad; char squote; char sqt8bitchar; char sseol; int sbctr; /* kermit stuff */ int sbinary; int turnch; /* kermit stuff */ /* Zmodem Options */ int zadl; /* ZMODEM auto download flag */ int zds; /* ZMODEM time/date stamp flag */ int zcr; /* ZMODEM crash recovery flag (0, 1, 2, 3) */ int zscr; /* ZMODEM send crash recovery flag (0, 1 */ int ztw; /* ZMODEM tx window size (0, 2048, 4096) */ int zcrc; /* ZMODEM crc type (0 = 32 bit, 1 = 16 bit) */ /* int zmt; ZMODEM moby turbo compatibility flag */ /* External Protocol Options */ char epname[3][9]; /* display name */ char epupload[3][16]; /* upload command */ char epdnload[3][16]; /* download command */ int epmode[3]; /* 0,1,2=ASPECT,Program,Hook */ /* General Protocol Options */ int relax; /* XMODEM relaxed mode: FALSE/TRUE */ int trash; /* garbage placeholder */ /* Editor Options */ unsigned char textmode; /* input mode 0:Aspect 1:word */ unsigned char omiteof; /* don't write EOF flag */ unsigned char exptabs; /* expand tab characters */ unsigned char wordwrap; /* word wrap enable flag */ unsigned char justify; /* right margin justify flag */ unsigned tabsize; /* tab-stop constant */ unsigned pindent; /* programming indent level */ unsigned windent; /* indent level (zero-based) */ unsigned lmargin; /* left margin (zero-based) */ unsigned rmargin; /* right margin (zero-based) */ unsigned es0; /* status line headers */ unsigned es1; /* status line file information */ unsigned es2; /* status line message area */ unsigned et0; /* normal text display */ unsigned et1; /* reverse video text display */ unsigned et2; /* highlighted text display */ unsigned ep0; /* prompt window display */ unsigned ep1; /* prompt input field */ unsigned em0; /* default message attribute */ unsigned em1; /* message MSG attribute */ unsigned em2; /* message EMSG attribute */ #if defined(ACSI) char acsi_callname[17];/* ACSI server name */ #endif int mouse_x_sensitivity; /* x mickey sensitivity */ int mouse_y_sensitivity; /* y mickey sensitivity */ int xfer_cd; /* flag for testing CD in Xfers */ int clip_separator; /* char sent between clipboard entries */ int ax132; /* Value for AL for forced video mode */ int hcmdrte; /* TRUE if using HCOMMAND.RTE */ } ; /* End of parmlist */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS dialing directory entry. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ struct DDREC { char ddname[25]; /* name */ char ddphone[21]; /* phone number */ int ddbaud; /* baud rate as int */ char ddparity; /* parity as short int */ char dddata; /* data bits as short int */ char ddstop; /* stop bits as short int */ char dddup; /* duplex as short int: 0 = full */ char ddscript[9]; /* ASPECT file w/o ext */ char ddlast[9]; /* last call: mm/dd/yy */ int ddtotal; /* total connects */ char ddproto; /* default protocol as short int */ char ddterm; /* terminal type as short int */ char ddmode; /* 0 = mode, 1 = direct */ char ddpassword[11]; /* like it says */ char ddmacfile[9]; /* keyboard macro file */ char ddkbdfile[9]; /* keyboard mapping file */ char ddport; /* com port to use */ char ddnotefile[9]; /* note file */ }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 Structure for PROCOMM PLUS .KBD file terminal entry: 22 22 22 22 struct TERMTABLE 22 22 { 22 22 char def[79][12]; 22 22 }; 22 22 22 22 All fields are fixed length and are padded with NULLs. 22 22 22 22 The file is built in the terminal order in the term_desc array 22 22 below. Each terminal entry has the keys stored in the following 22 22 order: 22 22 22 22 KEYPAD ASTERISK (*) 22 22 KEYPAD MINUS (-) 22 22 KEYPAD PLUS (+) 22 22 KEYPAD PERIOD (.) 22 22 KEYPAD SLASH (//) 22 22 KEYPAD ENTER (CR) 22 22 22 22 TAB 22 22 BACKTAB 22 22 INSERT 22 22 DELETE 22 22 BACKSPACE 22 22 22 22 CTRL-HOME 22 22 CTRL-END 22 22 CTRL-PGUP 22 22 CTRL-PGDN 22 22 CTRL-BACKSPACE 22 22 22 22 F1 22 22 F2 22 22 F3 22 22 F4 22 22 F5 22 22 F6 22 22 F7 22 22 F8 22 22 F9 22 22 F10 22 22 F11 22 22 F12 22 22 22 22 KEYPAD 0 22 22 KEYPAD 1 22 22 KEYPAD 2 22 22 KEYPAD 3 22 22 KEYPAD 4 22 22 KEYPAD 5 22 22 KEYPAD 6 22 22 KEYPAD 7 22 22 KEYPAD 8 22 22 KEYPAD 9 22 22 22 22 SHIFT-F1 22 22 SHIFT-F2 22 22 SHIFT-F3 22 22 SHIFT-F4 22 22 SHIFT-F5 22 22 SHIFT-F6 22 22 SHIFT-F7 22 22 SHIFT-F8 22 22 SHIFT-F9 22 22 SHIFT-F10 22 22 SHIFT-F11 22 22 SHIFT-F12 22 22 22 22 GREY CURSOR UP 22 22 GREY CURSOR DOWN 22 22 GREY CURSOR LEFT 22 22 GREY CURSOR RIGHT 22 22 GREY INSERT 22 22 GREY DELETE 22 22 GREY HOME 22 22 GREY END 22 22 GREY PGUP 22 22 GREY PGDN 22 22 22 22 CTRL-F1 22 22 CTRL-F2 22 22 CTRL-F3 22 22 CTRL-F4 22 22 CTRL-F5 22 22 CTRL-F6 22 22 CTRL-F7 22 22 CTRL-F8 22 22 CTRL-F9 22 22 CTRL-F10 22 22 CTRL-F11 22 22 CTRL-F12 22 22 22 22 CURSOR UP 22 22 CURSOR DOWN 22 22 CURSOR LEFT 22 22 CURSOR RIGHT 22 22 22 22 HOME KEY 22 22 END KEY 22 22 ENTER KEY (CR)" 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ unsigned char *termdesc[] = { "TTY ", /* TTY 0 */ "VT52 ", /* VT52 1 */ "VT100 ", /* VT100 2 */ "VT102 ", /* VT102 3 */ "VT220 ", /* VT220 4 */ "VT320 ", /* VT320 5 */ "ANSI ", /* BBS 6 */ "IBM PC ", /* IBMPC 7 */ "WYSE 75 ", /* WYSE75 8 (ANSI terminal) */ "ATT 605 ", /* ATT605 9 (ANSI terminal) */ "ATT 4410", /* ATT4410 10 (ANSI terminal) */ "TVI 922 ", /* TV922 11 (ANSI terminal) */ "HEATH 19", /* H19 12 */ "IBM 3101", /* IBM3101 13 */ "IBM 3161", /* IBM3161 14 */ "DG D100 ", /* DGD100 15 */ "DG D200 ", /* DGD200 16 */ "DG D210 ", /* DGD210 17 */ "ADDS 60 ", /* ADDS60 18 */ "ADDS 90 ", /* ADDS90 19 */ "ADM 3A ", /* ADM3 20 */ "ADM 5 ", /* ADM5 21 */ "ADM 31 ", /* ADM31 22 */ "ESPRIT 3", /* ESPRIT3 23 */ "3270/950", /* IBM3270 24 */ "TVI 910 ", /* TV910 25 */ "TVI 912 ", /* TV912 26 */ "TVI 920 ", /* TV920 27 */ "TVI 925 ", /* TV925 28 */ "TVI 950 ", /* TV950 29 */ "TVI 955 ", /* TV955 30 */ "WYSE 50 ", /* WYSE50 31 */ "WYSE 100" /* WYSE100 32 */ }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 p.baud from the "parmlist" structure above is an index into the 22 22 following 2 arrays. 22 22 22 22 i.e. the current baud rate for PROCOMM PLUS is baud_rate[p.baud]. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ char *baud_desc[] = /* baud rates as strings */ { "300\0\0\0", "1200\0\0", "2400\0\0", "4800\0\0", "9600\0\0", "19200\0", "38400\0", "57600\0", "115200" }; long baud_rate[] = /* baud rates as longs */ { 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 }; /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 HOOK.C declarations and defines 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ #define PARMSIZE sizeof(struct PARMLIST) #define VMAX 10 #define SLEN 81 #define NSIZE VMAX * 2 #define SSIZE VMAX * SLEN struct PARMLIST near p; /* PCPLUS.PRM structure */ int asp_nums[VMAX]; /* ASPECT N0-N9 array */ unsigned char asp_strings[VMAX][SLEN]; /* ASPECT S0-S9 array */ unsigned int ptr_seg1; /* segment addr */ unsigned int ptr_off1; /* offset addr */ unsigned int ptr_seg2; /* segment addr */ unsigned int ptr_off2; /* offset addr */ unsigned int ptr_seg3; /* segment addr */ unsigned int ptr_off3; /* offset addr */ char far *suptr; /* ptr to far storage */ int type; /* flag from PROCOMM PLUS */ struct SREGS seg; /* structure for DS value */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 main() program routine 22 22 22 22 Hook programs receive the following arguments: 22 22 22 22 ARG 1: The string "PCPLUS". 22 22 ARG 2: Far pointer in ASCII to the ASPECT N0-N9 array. 22 22 ARG 3: Far pointer in ASCII to the ASPECT S0-S9 array. 22 22 ARG 4: Far pointer in ASCII to the PCPLUS.PRM structure. 22 22 ARG 5: Integer in ASCII indicating where hook was called from. 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ void main(argc,argv) int argc; char *argv[]; { /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get value of segment registers into structure (we need DS value). 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ segread(&seg); /* get value of DS register */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of ASPECT N0-N9 array... 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[2]); /* convert str to ptr */ ptr_seg1 = FP_SEG(suptr); /* get segment addr */ ptr_off1 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy ASPECT array into local array 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg1,ptr_off1,seg.ds,(unsigned int)&asp_nums[0],NSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of ASPECT S0-S9 array... 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[3]); /* convert str to ptr */ ptr_seg2 = FP_SEG(suptr); /* get segment addr */ ptr_off2 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy ASPECT array into local array 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg2,ptr_off2,seg.ds,(unsigned int)&asp_strings[0][0],SSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 get segment and offset of PCPLUS.PRM structure from PROCOMM PLUS 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ suptr = (char far *) atol(argv[4]); /* convert str to ptr */ ptr_seg3 = FP_SEG(suptr); /* get segment addr */ ptr_off3 = FP_OFF(suptr); /* get offset addr */ /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 copy PROCOMM PLUS' structure into local structure 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ movedata(ptr_seg3,ptr_off3,seg.ds,(unsigned int)&p.port,PARMSIZE); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 "TYPE" lets you know where the hook program was called from in 22 22 PROCOMM PLUS: 22 22 22 22 TYPE VALUE CALLING LOCATION 22 22 --------------------------------- 22 22 0 Upload Protocol 22 22 1 Download Protocol 22 22 2 Aspect Script 22 22 3 Meta Key Hook 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ type = atoi(argv[5]); /* 22222222222222222222222222222222222222222222222222222222222222222222222 22 22 22 The following code is a simple example of what you can do with 22 22 a "hook" program. It assumes it was called fram an ASPECT script 22 22 and was passed some information in ASPECT variables N7 and S7. 22 22 It displays that information, then displays some information 22 22 about current settings in PROCOMM PLUS. It then puts new data 22 22 into N7 and S7 and passes it back to PROCOMM PLUS. 22 22 22 22 This is a sample ASPECT program that you can use with this hook 22 22 program to show how things get passed back and forth: 22 22 22 22 proc main 22 22 locate 0 0 22 22 n7 = 777 22 22 strcpy s7 "This message is from the ASPECT file." 22 22 hook "hook.exe" 22 22 fatsay 10 0 31 "ASPECT variable N7 passed from hook: %d" n7 22 22 fatsay 11 0 31 "ASPECT variable S7 passed from hook: %s" s7 22 22 endproc 22 22 22 22222222222222222222222222222222222222222222222222222222222222222222222 */ /* sample: */ printf("\nASPECT variable N7 passed to hook: %d",asp_nums[7]); printf("\nASPECT variable S7 passed to hook: %s",asp_strings[7]); printf("\n\n\nPROCOMM PLUS INFO:\n"); printf("\nBaud Rate: %s, Terminal: %s",baud_desc[p.baud],termdesc[p.termtype]); printf("\nPort: COM%d, Modem Init String: %s",p.port+1,p.mdminit); /* put some info into variables for return to ASPECT... */ asp_nums[7] = 99; strcpy(asp_strings[7],"This message is from the hook program."); /* copy local variables back into ASPECT variables... */ movedata(seg.ds,(unsigned int)&asp_nums[0],ptr_seg1,ptr_off1,NSIZE); movedata(seg.ds,(unsigned int)&asp_strings[0][0],ptr_seg2,ptr_off2,SSIZE); /* signal normal exit (can be tested for with ASPECT "if success" command) */ /* 0 signal sucess, 1 signals failure. */ exit(0); } -- -----====> 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 \== ==/

1 0

Re: Software infrastructure
by Pat Farrell 05 Jun '93

05 Jun '93

>Maybe I have a slow version, but I have NEVER gotten comparable results 'tween >kermit and zmodem, or even ymodem. Usually it's a 2:1 difference. It is important to have recent version on both the PC and host side. The versions that I run on my PC is 3.12. The Unix host version is close to 5A... I had to slurp the latest Sun version from Columbia to get decent performance. The version supported by my Sysadmin was obsolete. I haven't claimed that Kermit is faster, but with sliding windows, large buffers, and other tricks, the night and day difference goes away. >>glowing BS about TCP/IP, NASI, etc. elided... >This is worth considering... I agree. That is why I posted. Perhaps a Kermit guru lives within the list. >> I expect that Kermit is good enuff if you are interested in commandline >> scripts for plain old DOS. And the scripting language is also >> supported by the C version that run on nearly all Unixs and most other >> boxes. This would allow a single script to support a lot of users. >What do you mean by "commandline script?" I mean that a script that works like unix or DOS command line programs should (speculation alert!) be possible. We can handle obscure options, switches, etc. My target audience can't. Kermit has automatic scripts and macros that should be able to handle what we need. Heaven help us when there are errors tho.... Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

2 1

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