Strategies for getting encryption in widespread use QUICKLY
I recently sent a version of this message to Stanton McCandlish in response to EFF's call for support on the Cantwell bill; he said you people would probably be most interested in the idea. I was planning to sit quietly for a few weeks, watch the list, and make sure it's not just old news here before opening my big mouth. But seeing the volume of the list I may not last that long, so I'll post now. :-) --- It seems like the most effective way to fight Clipper would be to ensure that by the time the government has a chance to impose any effective controls, strong public encryption is in wide enough use to make such controls completely unenforceable. While encouraging people to always encrypt their E-mail might seem the most straightforward way to do this, most people just aren't interested enough and don't see a threat in leaving their mail open, and encryption is still inconvenient. An approach introducing encryption into some other aspect of information transfer, where it is more immediately and obviously useful, might be more successful in the short term. One of the most popular uses of the Internet is for distribution of free software, both in binary and source form. It would make the lives of many people much easier if the downloading and installation process could be made more automatic. Right now if I want to always have the latest version of GCC on my Linux box at home, I have to watch the right newsgroup for announcements, FTP to the right site, download the new version, unzip, untar, and install it (not to mention compiling it if I get a source code distribution). This is not too bad by itself, but it gets inconvenient on a "real" system containing hundreds of packages to be kept up-to-date, a new version of one coming out every day or two. It shouldn't be too difficult to automate this monitoring, downloading, and installation process, especially for binary distributions that require no complicated configuration or build sequence. But suggest this to most anyone, and they'll immediately get jittery with fear about trojan horses, viruses, and every other attach known. This is where encryption technology (specifically, public-key-based signatures) could come in. Unlike with E-mail privacy, where most people don't get a really tangible benefit, in this case encryption could be a real enabling technology: it would allow people to do what they couldn't (or wouldn't dare) do before. If it was done right, in a way that people can trust, people _would_ use it because it would make their lives easier, not more complicated. Before I get into any more detail, I want to hear what you all think about the general idea, so I'll leave it at that for now. Thanks! Bryan Ford --- Bryan Ford baford@cs.utah.edu University of Utah, CSS `finger baford@schirf.cs.utah.edu' for PGP key and other info.
Hmm... Well, having a program that will auto install segments only if they are signed by trusted public keys is a good one... but then again, most of the non-techies just want to have a program that works and that they're happy with. Many people would rather just keep a stable, working, but older version instead of going to the trouble of trying to always have the latest. But perhaps we could have a system such that only authenticated program upgrades could be installed, to combat against trojan horses, virii, bombs, etc. I would be wary of an auto-update system because of possible bugs in the software. Even if you only allowed updates from completely trusted public keys, even the best of us make mistakes and screw something up... but public-key protection against viruses and trojan horses would be a good thing. Perhaps we just need something that would make using encryption easier. Tell me what you all think of this as a project for cypherpunks: Does anyone want to develop an encrypted term program? On-the-fly encryption over a modem. This would allow everyone to encrypt very easily. It could support plug-in modules (with signatures) to support automatic pgp signing/verification, additional cipher modules (ie DES, IDEA, MPJ2). When logging on to you favorite BBS, instead of typing your password in, you enter your account, and then set your encryption on your terminal to your password, and if it's right, then you can decode the transmission and you are logged on. That way nobody could steal your password (or anything else) by tapping your transmission. Encrypting two way modem transmissions would be a problem, but it could probably be solved by packaging the data into manageable packets with an error-correction protocol and then encrypting those. Error-correction would be vital, as line noise can wreak havok on encrypted data. (Although you could reduce the impact of the errors by weakening the cipher somewhat.) I do have several ideas as to how to do this... What do you think? Anyone want to take this on as a project? If I'm going to do it, it would be for MS-DOS systems, tho if there's enuff interest, it might be possible to develop multi-platform support concurrently. Let me know...
"mjg" == Matthew J Ghio <mg5n+@andrew.cmu.edu> writes: [ auto-install comments deleted...] mjg> Does anyone want to develop an encrypted term program? On-the-fly mjg> encryption over a modem. This would allow everyone to encrypt very mjg> easily. It could support plug-in modules (with signatures) to support mjg> automatic pgp signing/verification, additional cipher modules (ie DES, mjg> IDEA, MPJ2). When logging on to you favorite BBS, instead of typing mjg> your password in, you enter your account, and then set your encryption mjg> on your terminal to your password, and if it's right, then you can mjg> decode the transmission and you are logged on. That way nobody could mjg> steal your password (or anything else) by tapping your transmission. If the machines to which you want to connect are in a kerberos realm and you can run TCP/IP (ala PPP or SLIP) on your end, then kerberized telnet will offer you the ability to a) connect to a host without sending your password over the connection using a standard kerberos ticket-granting ticket. b) encrypt the connection (DES using the session key), so that you can, among other things, klog on the remote host without the password being sent in the clear. It should be possible to add other encryption options into ktelnet. One might be able to adapt this for BBS use either by modifying kerberos or by using something like s/key. There's no need for cleartext passwords to be flying across the wire. michael
I'm currently developing a Mac BBS. (I don't know when I'll finish it but I've been working on it for the last 3 years!) I can put patches in to connect to whatever crypto terms will be out there, however, on the Mac, it's far easier to simply build a CommToolbox connection tool which ANY Mac BBS or Mac terminal could interface itself with. The BBS would have to specifically know about the encryption tool as it would need to link some key to a user... But other than that, the ability is already there. If we come up with a standard for encoded TCP/IP and serial communications and adapt existing programs to use them.... The serial communications would be much easier I suspect as most unix machines can simply have device drivers written for them that map an existing port to/from an encryption pipe and on to a virtual device. Ie: for every /dev/tty* you could have /dev/etty* It'll be harder for DOS, but not impossible. If anyone has the sources to a fossil driver, there are plenty of BBS software that use the fossils... Perhaps there would be some term programs that do this too? On Amiga???? (BTW: I've put off the Mac BBS for a while as I just stumbled on something far more important: a crypto-stacker for the Mac!!! I hope to get something up in beta in the next few months. I won't do the actual encryption routines, but will provide plenty of hooks for adding your own. I'm going to have it actually compress/decompress and have some hooks...)
rarachel@prism.poly.edu (Arsen Ray Arachelian):
On Amiga????
Should be reasonably easy to implement depending on at what point. A drop in replacement for serial.device (most all term programs and BBS's would most likely support this) wouldn't be healthy as at the handshaking would have to be done unencrypted until a session-key was established. Perhaps if the serial.device were written to use the normal serial.device and except a certain escape sequence that could be sent to the serial.device as normal output that would be intercepted as a key of some sort. Other options include a shared library that an application would have to look for and use. (This would of course involve a rewrite of all the term soft, etc.) In any case, a sorta standard using pgp to exchange session keys seems like a good idea. Something worth noting though, the internet is a packet network and most bbs via modem just stream things don't they? I suppose you might have to use a stream cipher or just have the BBS/Term soft wait until you have an IDEA blocks worth, or a certain time limit then crypt and send.
Hmm... Well, having a program that will auto install segments only if they are signed by trusted public keys is a good one... but then again, most of the non-techies just want to have a program that works and that they're happy with. Many people would rather just keep a stable, working, but older version instead of going to the trouble of trying to always have the latest.
That's actually another reason such a system could be valuable. If multiple signatures could be attached to a particular version of a program, different versions of a program could be distributed simultaneously, each at a different "stability level". New versions would start with only the signature of the author, indicating that the author "thinks it works." Then as the alpha testers test the version, they sign it if they consider it stable. If "enough" signatures are attached to a particular alpha test version, it becomes a beta version and released to the much broaded beta test audience, who then similarly sign it only if they think it's stable, and finally it might become a release version. A particular user might configure the downloading/installation system to accept new versions of the software only after a certain number of signatures are attached to it. In addition, the user would probably specify some number of specific signatures that must be present - the author's, presumably, possibly other well-known beta testers, the maintainer of the primary FTP site it's being distributed from, etc. Essentially, the "specific signatures" check would be for security, while the "number of signatures" check would be only to keep track of the stability of the software. On the author's (distributor's) side, there might have to be some additional security provisions to ensure, as much as possible, a "one tester, one signature" rule, so tons of bogus signatures don't get accepted and added to the main distribution. But only the author/distributor should need to worry about this; normal users/ receivers of the software shouldn't need to be concerned.
I would be wary of an auto-update system because of possible bugs in the software. Even if you only allowed updates from completely trusted public keys, even the best of us make mistakes and screw something up...
The same goes for PGP, anonymous mailers, etc. Any software system like this can only command trust as more and more people scrutinize it and test it and decide it's OK for them.
Perhaps we just need something that would make using encryption easier. Tell me what you all think of this as a project for cypherpunks:
Does anyone want to develop an encrypted term program? On-the-fly encryption over a modem.
This is another good application, but I think it suffers from the same problem as encrypted E-mail messages: as long as it's even a little less convenient than no encryption, most people just won't care enough to use it. The motivation for my suggestion was not so much to present a neat new idea (in fact, I'm sure the idea is not new at all), as to present a _strategy_ for achieving other social and political goals. The strategy I'm proposing is to find a way to make encryption an _enabling_technology_, not just a mostly-unnecessary inconvenience in the eyes of ordinary people. However, with that in consideration, don't let me discourage you from doing some kind of encrypted terminal program. In fact, one common denominator between it and any automated downloading/installation system would be the necessity of interfacing with existing encryption systems, probably more than one. A useful sub-project, whatever the bigger project(s) turn out to be, might be an easy-to-use, standardized "encryption interface library" that could be used in other programs to interface with other encyrption programs and modules. Bryan
probably be solved by packaging the data into manageable packets with an error-correction protocol and then encrypting those. Error-correction would be vital, as line noise can wreak havok on encrypted data. (Although you could reduce the impact of the errors by weakening the cipher somewhat.) I do have several ideas as to how to do this...
Look at the code for Layers and Multisession(??) they both have sources for the unix end. If you base your code on that it should be fairly stable as we know the above products work. (Beware of Layers though, on the Unix end, it supposedly leaves opened ports after you log out which could be used to hack in, or look like they were used to hack in. I got my account pulled one day for running it, because some hackers were breaking in and leaving open ports as part of their footprints....)
What do you think? Anyone want to take this on as a project? If I'm going to do it, it would be for MS-DOS systems, tho if there's enuff interest, it might be possible to develop multi-platform support concurrently. Let me know...
If you're going to do this, try to write some VERY generic code. Don't assume the size of a char, int, long, etc. Instead, use stuff like: #define CHAR char #define INT int etc. That way, if an int happens to be 32 bits on some weirdo machine, it can be redefined on that machine by simply modifying the headers... (better yet, use typedef, not #define.) Another thing, don't use any dos i/o functions to actually send the packets across, instead, do everything you can without calling on DOS or whatever C language library/compiler calls directly. Call the DOS functions to read/write to the serial port from one single place so that they can be easily modified. You really don't have to do too much for the packets and stuff... Basicallly each packet is composed of a header, data, and some sort of check. There are CRC codes out there already. Pull the 32 bit version out of some Zmodem program and use that... Your header should contain some packet id#, the size of the packet (no need to send 1024 bytes if the user just pressed one key :-), the CRC for the packet, and the packet itself... A good thing might also be to include a couple of special bytes at the begining and end of the packet so that the receiver can try to resynch itself if it gets hit by line noise... Say, 0x55,0x55,0xAA,0xAA, packetid#, packetsize, packetcrc, packet, 0x00,0x00,0xff,0xff for example. (while this is longer, the other side can look for 2 zeroes, followed by two 255's, followed by possibly some time before it sends a request to resend the packet. Or if you want to make things simpler, do as Xmodem (yuck!) send a small tiny header, the packet, and wait for an ACK from the other side before proceeding to send the next packet. That ACK would be after/before a packet that the other side sends of course... :-) Better yet, maybe you can just hack some source code for SLIP or UUCP or something...
I'm new to the list, but after reading the article in Wired I felt I needed to hear all this, Nazi flames aside. I run linux myself and I'd like to see your idea take root. The Kind
participants (6)
-
Adam Dace -
Aran Christopher Cox -
Bryan Ford -
Matthew J Ghio -
michael shiplett -
rarachel＠prism.poly.edu