June 1993 - cypherpunks-legacy

good day
by Timothy Newsham 03 Jun '93

03 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 03 Jun '93

03 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

Re: CryptoStacker, long term vision
by Mark 03 Jun '93

03 Jun '93

>A related topic to encrypted disk drives. Anybody who has a desire to >see their data around long term makes backups of their drives. At >least one of these backups is usually physically near the drive in >question. > >What good it is to have an encrypted disk if the backups are not also >encrypted? > >Backups occur at the file system level, where an encrypted file system >does not appear encrypted, so that work here does not directly >leverage to encrypted backups. This problem is most easily solved by copying the entire partion/file that is encrypted as blocks. These blocks are size according to the destination media. If you use floppies you break the encrypted fs/file into (e.g.) 1.44 meg chunks, if you use tape you can throw the whole block at the media, similarly with another hardisk. The unix/linux/386bsd 'dd' program is especially useful for this purpose and I assume there are similar utils for dos. For replacement you simply dump the whole lot back as one encrypted file system. This method should be faster than grabbing individual files and backing them up as the program just has to seek to a specified place and start reading a defined amount of [encrypted] data. Mark mark(a)coombs.anu.edu.au

1 0

Secure transport layer paper
by fnerd＠smds.com 03 Jun '93

03 Jun '93

There's a paper in the Feb. '93 _IEEE Transactions on Software Engineering_: "Trust Requirements and Performance of a Fast Subtransport-Level Protocol for Secure Communication" by P. Venkat Rangan It's about a protocol called Authenticated Datagram Protocol, and issues about using it in a "subtransport level." He's tried it on Suns. The work was done at Berkeley in 1990, the guy's at UCSD now. -fnerd

1 0

the right platform for these projects
by Stanton McCandlish 03 Jun '93

03 Jun '93

I agree wholeheartedly that a commandline, portable, version should come first. Porting that separately to X, Win, Mac, etc will not be nearly the chore that porting a Windows app to Unix will be. Re: the ubiquity of Windows: LOTS of people have Windows. But... The idea that new machine sales are mostly Windows machines is given the lie somewhat by the fact that they are also all DOS machines, and that Windows is just bundled. Many people don't install it due to the disk space leeching. And a LOT of people with Windows don't use it for comm stuff because Windows + comm = nightmare. So yes, make a Windows version. NO don't start with a windows version. One of your biggest markets will be the BBS crowd, 90+% of whom use DOS, not Windows, for comm apps. And I still heartily recommend tackling this from several different angles. Sure make a new term, but also get Telix, et all to go along with it. Get Fido-tech mailer makers to support the ^ENC "standard", etc. -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton(a)hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:)

1 0

Clipper on CNN HN
by RYAN Alan Porter 03 Jun '93

03 Jun '93

The current CNN Headline News has a spot on the Clipper chip airing after the Sports section, I just barely caught it by accident. I have to leave now to do some consulting, but I have my VCR set up to record it the next time around. Summary of the tape: ____BEGIN SUMMARY____ The Clinton Administration is developing, along with the NSA and the NIST a chip which will ensure private communications between telephones and fax machines and such. Current plans are for the keys to be held in escrow by two seperate (unnamed) government agencies. Much was made about the objections made by people at the NIST hearings about the questionable constitutionality of the chip and a direct quote was aired by a woman saying during the hearings that 'the chip would expand the powers of the government to invade the privacy of citizens to even greater than what it already is' (paraphrase) and also about the objections of companies who are afraid of being blackballed and prevented from doing business unless they use the chip. There was a small hint of a fear that the 'voluntary' status of using the chip would not last for long. Also, AT&T (surprise) has apparantly announced that it is already developing a system using the chip and showed a prototype on the air. It seemed to be a lot larger than necessary, a huge black box with a little LCD display saying 'secure' and whatnot when you activated clipper security. There was an interview with a fed type who repeated all of the old stale arguments about making conversations secure for him but not for the criminals. ____END SUMMARY____ I think that the spot was definitely leaning toward exposing the objections that people have toward the chip, even if the people at CNN didn't really understand for sure what those objections are. The whole thing might have been a little unclear for the average Joe as to what the real problem is with this newfangled system, and I think that more uninformed coverage like this is likely to turn people against us; they may start to see us as the bad guys, a bunch of people who are against privacy by our objection to this thing. Anyway, now that it has hit CNN, it is officially mainstream and it may well become a hot, trendy news item. What we need now are hoardes of people who will volunteer to be consulted with as 'experts' on the issue for local news and such. Gotta go now, gotta write some code... Try to catch the spot. -Ryan the Bit Wallah

3 2

Hardware vs software
by hkhenson＠cup.portal.com 03 Jun '93

03 Jun '93

RE this topic, there are methods (Merkle's for example) where you can get multiple megabytes per second through a good encryption algorithm in a CPU. DES is kind of optimised for doing it in hardware, so don't take how slow it is in software as the limit for good encryption. Keith (Gnu posted the paper a long time ago in sci.crypt, but I don't know if I can find it on my newer system.)

2 1

Pc environ (fwd)
by Mark 03 Jun '93

03 Jun '93

For those others that insist on living in 640K... :) Forwarded message: >From mark Wed Jun 2 20:29:47 1993 >Subject: Pc environ >To: 74076.1041(a)compuserve.com >Date: Wed, 2 Jun 1993 20:29:47 +1000 (EST) >>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. >Hey Hal, >Um although I abhor dos, I happen to know something of it... you might want >to put the line: >shell=c:\command.com /e:1024 /p >in your config.sys... that will give you a K of environment space instead >of the usual (256bytes?) they usually give you. Increase the 1024 as >needed. >Mark >mark(a)coombs.anu.edu.au

1 0

[comp.os.linux.announce] New loop devices, even with DES encryption
by eichin＠cygnus.com 03 Jun '93

03 Jun '93

If you actually want to see the linux loopback code I mentioned, here's the real announcement. _Mark_ ------- Start of forwarded message ------- From: almesber(a)nessie.cs.id.ethz.ch (Werner Almesberger) Newsgroups: comp.os.linux.announce Subject: New loop devices, even with DES encryption Keywords: loop devices, DES, mount regular files Date: 1 Jun 93 20:13:47 GMT Followup-To: comp.os.linux Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH 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_/ ------- End of forwarded message -------

1 0

Unix Crypto File System paper
by mab＠vax135.att.com 03 Jun '93

03 Jun '93

Hi, Some of you have sent me mail asking about my cryptographic file system for Unix; it was the subject of a work-in-progress presentation at the January Usenix conference. I have a draft of a paper that you may find helpful; I just got off the phone with our lawyer and finally have the release to send it out, so if you'd like a copy of the draft, send me your email (for postscript) or physical (for dead trees) address. Before you ask: the software also may be released, but that's a longer process and it isn't really "ready for prime time" yet anyway. The paper is just a draft, and also has some bugs in it, but some of it seems relevant to the discussion here on similar projects for PCish machines. Here's the abstract: ======== Although cryptographic techniques are playing an increasingly important role in modern computing system security, user-level tools for encrypting file data are cumbersome and suffer from a number of inherent vulnerabilities. The Cryptographic File System (CFS) offers an alternative to ad hoc user-level encryption for protecting file data. CFS supports secure storage at the system level through a standard Unix file system interface to encrypted files. Users can associate a cryptographic key with any directories they wish to protect. Files in these directories (as well as their pathname components) are transparently encrypted and decrypted with the specified key without further user intervention; cleartext is never stored on a disk or sent to a remote file server. CFS can use any available file system for its underlying storage without modification, including distributed file systems such as NFS. System management functions, such as file backup, work in a normal manner and without knowledge of the key. This paper describes the design and implementation of CFS under Unix. Encryption techniques for file system-level encryption are described, and general issues of cryptographic system interfaces to support routine secure computing are discussed. ======== -matt mab(a)research.att.com

1 0