- cypherpunks-legacy@lists.ogf.org

Work the work!
by fergp＠sytex.com 04 Jun '93

04 Jun '93

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 1 Jun 93 09:56:45 -0700, Eric Hughes <uunet!soda.berkeley.edu!hughes> wrote - > We are trying to build a sandbox, and the government is trying to > restrict the use of sand. We are indeed doing just this. Although the small minority of us compu-professionals are writing code, flailing congressmen, etc., it takes more than what is currently being acknowledged to get things changed. I will not, however, discontinue my diatribe with my elected representatives on the topic of our electronic rights to privacy under the first and fourth amendments. (I'm having too much fun doing something that I seriously, and perhaps foolishly, believe in.) Is there something going on with the EFF that we should know about? > That said, I also urge those who are writing code to continue. To > those of you not writing code, however, I say start talking to your > friends and neighbors and communities and newspapers. > Now. We are working on it. A vote of confidence towards crypto-freedom. Are we east-coast-niks welcome in this process? Is policy being drawn by a few EFF persona without consultation of the masses? Eric, before you say "Now,", you'd best detail us. I know what you mean, however, many of the crypto-warriors which may follow do not. It may be a good idea to _now_ place a broad policy statement. Cheers. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwNs5RLcZSdHMBNAQFlRAP7BSpktDz4URB0rhWQ5mxb2UcJqEZHdp+2 It+Whxh1MzYTLFi0SfvZRQYjPEZO1wN2ac8bQyl2zOpi7viAg8X+AfEZACWooqUQ y8Dyddup15MNj/p53fJQhzKYaX4K4xD2h6WTWO1X8Q2SPHo0WV48Hu+uO8nyeoqD PJj0d/IHvg4= =6GvE -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp(a)sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip.

4 4

HELP: pgp, .forward, mh
by Karl Barrus 04 Jun '93

04 Jun '93

Situation: I'd like mail that arrives at my other account to be encrypted and then forwarded to this account. I have spent a few hours trying various things and nothing seems to work. I've tried this as my .forward file: "| /myhome/pgp -fea barrus | mail elee9sf(a)menudo.uh.edu" but all that arrives at elee9sf is a blank message. I've tried "| /myhome/remail.script" where remail.script was a one-liner similar to the above. Nothing. Any suggestions? Note: 1) barrus(a)tree.egr.uh.edu is a NeXT account. Is NeXTSTEP just too different for this stuff to work? 2) I'm running pgp2.1 on tree.egr, and don't have the old docs anymore. Was the -f option not present? 3) Anybody have a makefile for NeXT so I can upgrade? I compiled 2.1 by hand editing some lines, but the task looks pretty daunting with 2.2. I tried 'make mach' but that didn't get very far. So, if that's impossible, how do I get my elee9sf account to do it? I use mh on menudo, and have tried to barrus(a)tree.egr.uh.edu | A "/path/pgp -fea barrus | /path/rvcstore +tonext" in my .maildelivery but that doesn't seem to fly either. Any suggestions? /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

2 1

RE: Term software develo
by Doug Porter 04 Jun '93

04 Jun '93

Eric Hughes says: > FOSSIL is . . . the only abstraction for serial communications the PC has . . . There are at least 7 versions of INT 14. Then there's Ungerman-Bass's old INT 6B as well as two flavors of its successor, NASI/NCSI. There are also many variants of COMx device drivers. These are all serial line abstractions for the PC. There are others. FOSSIL may be popular on BBSs, but NASI/NCSI is number one in the market. The oldest version of INT 14 is number two. Who was it said "The nice thing about standards is that there are so many to choose from"? :-) Doug

3 2

Re: Term software dev
by Doug Porter 04 Jun '93

04 Jun '93

Eric Hughes asks: > What are NASI/NCSI? Does it cost to use them? Is source available? It's an API originally developed by Network Products Corporation and based on an earlier spec from Ungerman-Bass. NPC used it in building an async comm server for LANs. NPC called the API "Network Communications Server Interface" or NCSI. Novell licensed the technology from NPC and renamed the API to "Novell Asynchronous Server Interface" or NASI. Other async server vendors picked up on it about then as a result of Novell's evangelism. Serial communications software packages from Crosstalk to Procomm to tiny niche products started to support it. Then because of the end user package support, the standard was used for different kinds of serial connections. For example, we (CyberCorp) built a NASI/NCSI interface for intelligent Digiboards a while back. I've never heard of anyone being charged to use the spec for whatever they like. At least part of the spec, the part promoted by Ungerman-Bass, seems to be in the public domain. We originally got the spec from Novell when we built a Netware compatible async server. I don't know of any free source code, but code for either end of the spec is only one or two thousand lines of C. Doug

1 0

Re: VinCrypt
by Clark Reynard 04 Jun '93

04 Jun '93

Even as a former 'hacker' myself, the second to last person I would trust not to install a backdoor (next to the NSA) is a hacker. In addition, merely having been a systems hacker hardly qualifies one for writing complex crypto software. Without any assurance as to the authors' qualifications for writing a crypto package, or their integrity. Even if I could trust their integrity, I'm very leery of black-box software. ---- Robert W. Clark Just Say No! to the rclark(a)nyx.cs.du.edu Big Brother Chip

8 9

Term software, disk driver encryption
by greg＠ideath.goldenbear.com 04 Jun '93

04 Jun '93

Am suprised no-one's mentioned DISKREET, the encrypted disk driver software included with the Norton Utilities. It does DES, though the manual doesn't mention which flavor of DES it uses. I have been using it for roughly 2 years now without any trouble. It's been well-behaved and is probably already on lots of folks' disks, by virtue of being included with the rest of the Norton stuff. I think "TPU" refers to Turbo Pascal Units. "Async Pro" is, if I remember right, the name of an add-on async communications library for Turbo Pascal. Telix is not free, but is freely distributable, as it's shareware. -- Greg Broiles greg(a)goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764

1 0

subscribe
by bei＠dogface.austin.tx.us 04 Jun '93

04 Jun '93

subscribe l-cpunks(a)dogface.austin.tx.us

1 0

DOS disk encryptor
by Eric Blossom 04 Jun '93

04 Jun '93

Ryan, Good luck on building the DOS disk encryptor. I belive that what you need to do is write a standard DOS disk driver (that can be installed in CONFIG.SYS) that implements the READ and WRITE primitives. I belive that they use the same entry point (the STRATEGY entry) in the driver. You would basically just call the BIOS routines to do the actual i/o. You don't have to worry about the FAT etc, just encrypt everything. You will probably want to use DES or IDEA and run it in CBC mode or Counter Mode. You would use the DISK BLOCK NUMBER as a piece of the key material (or part of the Initialization Vector), hence, even if the same data appeared multiple places on the drive, it would appear different on the surface. There is a good description of operation modes in "Modern Cryptology: a Tutorial" by Gilles Brassard (Springer Verlag Lecture Notes in Computer Science #325, 1988). Denning's book covers it too. I'd probably start out getting it running on a floppy. After that, just use a separate partition to make life easier. The driver is handed physical (or logical) block numbers, and these map directly to the physical drive block number by adding the offset of the beginning of partition. At driver init time, you read the partition table on the hard disk, looking for a "system type" that identifies the partition as one of your encrypted ones. Prompt for the pass phrase, and store it in the driver. I assume that your concern is somebody physically grabbing the disk drive. I don't have a problem with the pass phrase in memory, as long I have physical control of the system. In some of the DOS references, there used to be a sample RAM DISK device driver. You could use it as the skeleton to get the entry points right, and then just encrypt the block and call the BIOS to do the i/o. Have fun, Eric Blossom

1 0

good day
by Timothy Newsham 04 Jun '93

04 Jun '93

Ahh.. what a good day it was today! I am currently logged in to my UNIX account from home. I am sitting here mailing you guys, and everything I type is being sent over the modem in encrypted form. I worked out some very irritating bugs in my software and have my link protocol up and running pretty reliably. It still needs some cleaning up. I will be cleaning it up a little and running it on a few different platforms to test it out. The code is basically the same as the unix end I mailed out to several people earlier (with just 3 or 4 lines changed), but I now have a good, functional VT100 end for my amiga. I will post here after I clean up and test the code a little and get it ready for "release". So if you're interested, basically just wait. But I am looking for people who are willing to port to other platforms. The common code should need no porting, what needs to be done really is to find a good P.D. term program in source form and modify it (this is what I have done). The common code was written with this in mind and it shouldnt be terribly hard (simply replacing writes to screen and serial with encoding/decoding routines and then outputting the results, and small things like providing the user a way to turn on and off the encryption). Tim

1 0

(fwd) [comp.os.linux.announce] New loop devices, even with DES encryption
by kelly＠netcom.com 04 Jun '93

04 Jun '93

Organization: NETCOM On-line Communication Services (408 241-9760 guest) Path: netcom.com!netcomsv!decwrl!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!agate!usenet From: almesber(a)nessie.cs.id.ethz.ch (Werner Almesberger) Newsgroups: comp.archives Subject: [comp.os.linux.announce] New loop devices, even with DES encryption Followup-To: comp.os.linux.announce Date: 4 Jun 1993 01:35:22 GMT Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH Lines: 42 Sender: adam@soda Approved: adam@soda Distribution: world Message-ID: <1um8sq$86e(a)agate.berkeley.edu> References: <1993Jun1.201347.7433(a)klaava.Helsinki.FI> NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: comp.os.linux.announce X-Original-Date: Tue, 1 Jun 1993 20:13:47 GMT Archive-name: auto/comp.os.linux.announce/New-loop-devices-even-with-DES-encryption Version 0 of the new loop devices patch is in tsx-11.mit.edu:/pub/linux/BETA/loop and nic.funet.fi:/pub/OS/Linux/BETA/loop The files are: lo.0.tar.z The loop devices patch des.0.tar.z DES-encryption for the kernel Note: If you're FTPing from outside the U.S. or Canada, please get the DES patch from nic.funet.fi, because of the well-known US export restrictions. (DES encryption is optional. The loop devices also work without it.) Loop devices give you the ability to mount file systems from regular files. Additionally, you can use them to have more than one file system on one partition and to have transparent on-line encryption of all your data. The loop devices patch is relative to ALPHA 0.99pl10, but it'll probably work with 0.99pl9 and 0.99pl10 too. The DES patch should work with any recent kernel. This is a new implementation of loop devices by Theodore Ts'o, I'm just maintaining the code. Unlike my old loop devices, which are also in some versions of SLS, the new loop devices will continue to work after variable block sizes are added to the kernel. The DES code is derived from Eric Young's DES library. I originally wanted to use UFC crypt, but its memory requirements make it a bit difficult to handle. Maybe later. - Werner -- _________________________________________________________________________ / Werner Almesberger, ETH Zuerich, CH almesber(a)nessie.cs.id.ethz.ch / /_IFW_A44__Tel._+41_1_254_7213__________________almesber(a)bernina.ethz.ch_/

1 0