Earlier I talked about some amiga programs I had that did compression and encryption. I've uploaded some to soda. As I've said, most of them are amiga-specific, but of course the encryption-only bits of code can still be educational to other-machine users. If not, Eric can erase them, or not make them public, which is of course okay. It's his site and all that. I figured I'd go through these files here to explain a bit of what they are and do, if nothing else, with liberal amounts of plagiarism from the readme files. This should at least prevent people from downloading interesting sounding titles for nothing. First, the list of files. Although I don't know where they'll end up, The full list of things I uploaded are: ************************************************* * * rdes.lha 25K DES encryption program * idea.lha 31K File encryption tool using IDEA * Crypt.device-1.8.lha 23K Crypting handler * crypdisk.zoo 55K Sector oriented disk encryption * xpk25dev.lha 141K Compression package, developer's additions * xpk25usr.lha 215K Compression package, user's edition * XFH134.lha 135K (De-)compressing handler, uses Xpk. * xPack_1.5.lha 9K OS 2.x Shell Interface for XPK * ************************************************* Now for the individual descriptions: ************************************************* * * rdes.lha 25K Another DES encryption program * ************************************************* Any collection of encryption programs should of course include a version of DES, so I'll start off with one. The following is taken from the RDES man file. Note the -x option. *********** * * The usage for RDES is * * RDES [-e | -d] [-x] [-b] [-m mode] [-k key] [in_file [out_file]] * * where: * * -e => encrypt the file (default) * -d => decrypt the file * * -x => add n random bytes to the end of the file, where n is * a random integer between 0 and 7 inclusive (used in * encryption mode only). * * -b => use straight DES (default is to use cipher block chaining). * -m => set `mode' bits (see below for details). * -k => set key string * *********** ************************************************* * * idea.lha 31K File encryption tool using IDEA * ************************************************* This is another one that should be easily recompilable on multiple platforms--it's straight C, and it even includes the original unix code. It is small, does IDEA encryption/decryption, and that's all. Here's the top of idea.doc. If it looks interesting you'll probably just want to get it anyway. *********** * * NAME * idea - encrypt and decrypt using IDEA * * SYNOPSIS * idea [ -e | -d ] [ -ecb | -cbcN | -cfbN | -ofbN ] * ( -k keyString | -K keyHexString ) * [ inputFile [ ouputFile ] ] * * idea [ -h | -H ] [ -tan | -abr ] * [ -k keyString | -K keyHexString ] * [ inputFile [ [ ouputFile ] hashvalFile ] * *********** ************************************************* * * Crypt.device-1.8.lha 23K Crypting handler * ************************************************* This is a device driver that you can use to mount an encrypting virtual partition as a file in top of an existing AmigaDos device. It says it's based on fdev.device -- "filesystem in a file". You can edit the virtual partition parameters however you want (such as sectors/cylinders/filesystem etc.) The encryption method is IDEA in cbc mode, which is written in 68000 assembly. ************************************************* * * crypdisk.zoo 55K sector oriented disk encryption * ************************************************* This is a sector based disk- (or AmigaDos device-) based encryption program. It works a bit differently from crypt-device, and also uses a 68000 handcoded IDEA algorithm, and it's not limited to cbc mode. It's a modification of the xpkIDEA library assembler source which will be mentioned in the next section. ************************************************* * * xpk25dev.lha 141K Compression package, developer's additions * xpk25usr.lha 215K Compression package, user's edition * XFH134.lha 135K (De-)compressing handler, uses Xpk. * xPack_1.5.lha 9K OS 2.x Shell Interface for XPK * ************************************************* * * Note: The bottom two files are updates to subparts of the top two. * (Obviously, I didn't want to modify the original distribution.) * ************************************************* The easiest way for me to describe the xpk???.lha files is to cheat, and mostly just include the overview file. Here it is, with a lot of deletions: (Including the list of way-cool authors.) *********** * * THE XPK DATA COMPRESSION PACKAGE * ================================ * * * 1. What is XPK * -------------- * * For a long time, there have been various compression programs for different * purposes on the Amiga. But every application supported only one compressor, * and most compressors were only supported by one application. XPK wants to * put an end to this: Every application with XPK interface can use very packer * with XPK interface. An XPK packer is a library with a four letter library * name. * * * 3. XPK-Compressors * ------------------ * * First a general overview of the most important packers and crypters and * their uses. [...] * - FEAL encrypts data at reasonable speed with very high safety, ie. it has * not yet been broken in the higher-round modes. Any kind of private data * is safe in the hands of FEAL. ===> [Is this still true?] ===> [Also: On the chart below, A3000 means a 25Mhz 68030 machine.] * Now for the complete overview of all existing compressors. You may not have * all of them. The meaning of the fields: * * Name: 4 letter name of the packer. * CSpd: Compression speed in K/sec on an A3000 * USpd: Decompression speed in K/sec on an A3000 * CF : Compression factor in % * Mo : This packer supports modes * Cry : This packer can encrypt * Desc: Description of the packer * * Name CSpd USpd CF Mo Cry Desc * ---- ---- ---- -- -- --- ---- * BLZW 139 364 32 + - Fast compression & decompression, usable CF * CBR0 410 1918 3 - - Byte run encoding, only for simple files (Gfx) * DLTA 104 1265 - - - Pre-processor for packing of sound samples * ENCO 393 393 - - + Sample library for cryptors * FEAL 109 109 - + + Encryption with selectable safety * HUFF 88 138 24 - - Huffman coding, low CF and speed * IDEA 90 90 - + + Safe Encryption, not too fast, many variations * IMPL 6 280 44 + - Imploder, good CF, slow compression, fast decomp * NONE 1918 2477 0 - - Do-nothing packer * NUKE 36 630 45 - - Very fast decompression, good CF & fast compression * RLEN 170 1351 4 - - Sample library for packers * SHRI 5 9 52 + - Excellent CF but low speed * VERN 861 874 - - + Less safe but very fast Vernam encryption * ---- ---- ---- -- -- --- ---- * * Also, XPK supports powerpacker.library for decompression. * *********** Note that there are multiple encrypting "compressors" there, including a blank one for an example. The distribution also contains two handlers to allow one to use these compression/encryption libraries transparently instead of semi-explicitly. One of these, XFH, (the one that Urban mentions), has been upgraded since this distribution. The latest version of which I am aware is 1.34, so I uploaded XFH134.lha also. Now to discuss some of the individual encryption libraries within this XPK distribution. I recall people having asked about what the speed of doing on-the-fly encryption would be. For Vernam encryption (Has anyone heard of this???), not only are the benchmarks not included but neither is the library nor the docs. Maybe the author didn't contact Urban for inclusion in the master archive, I dunno, I don't even have an xpkVERN.library. However, I do have numbers for FEAL and IDEA. Here are the speeds for the FEAL encryption, from a speed chart from its docfile. (I believe this is for a 25Mhz 68030 machine.) *********** * * Speed and Memoryusage * --------------------- * * Rounds Memory En-/Decryptioncryption * Usage Speed * ------ ------ ---------------------- * 4 1K 190 K/sec * 8 1K 144 K/sec * 16 1K 96 K/sec * 32 1K 58 K/sec * 64 1K 33 K/sec * *********** Here are the IDEA speeds: *********** * * The xpkIDEA implementation uses the following XPK modes for different * encryption methods: * * XPK Mode Encr. Method Nr. States 68030/25 68000/7.14 * -------- ------------ ---------- -------- ---------- * 0..25 ECB / 90 K/s 12 K/s * -------------------------------------------------------------------------- * 26 CFB 1 * . . . 87 K/s 11 K/s * . . . * 50 CFB 25 * -------------------------------------------------------------------------- * 51 OFB 1 * . . . 84 K/s 11 K/s * . . . * 75 OFB 25 * -------------------------------------------------------------------------- * 76 CBC 1 * . . . 84 K/s 11 K/s * . . . * 100 CBC 25 * -------------------------------------------------------------------------- * *********** Rather obvious possibilities for those wanting to do similar things on other machines: o Forget it, your machines are inferior pieces of... Oh sorry, I'm supposed to be being polite. Scratch that. o Scavenge source code from some of the above packages and use it in the skeletons of DOS 'redirectors' (?) o Go the whole way and implement the XPK standard on other machines. (You might want to bring get with Urban and the others though. By the way, when quoting sections of the XPK overview, I didn't inlcude the partial author list of nine people. Anyone interested in these projects do have lots of other people to talk with about the standard.) o Disassociate from the mediocritins and.. oops, there I go again. And finally, o Keep part of your mind still thinking about standards for secure data links. I have my own ideas on the subject, which should translate to other machines mostly. They are as follows: On the amiga, I think it would be best to write a driver one would use instead of the default of serial.device or whoever, to handle the encryption. It would then call serial.device or whoever to actually transmit the data. The advantage here is the modularity of having any terminal program work with this device driver, so you could at any time bring up its window on the workbench screen or a public screen, to adjust its parameters in a way independent of whatever terminal programs you might have running, if need be, or controlled with ARexx scripts or from other programs. The neat parts here are that (a), it could do compression as it goes, too, but more importantly, (b), it would be transparent to any other binary transfer protocol you'd be useing, except for speed. (Although it could somewhat make up for that by making them slightly more efficient--seeing as the encrypting device would have to do it's own error checking, dynamic transfer protocols used by the term programs would tend to use larger and larger window sizes), and (c) this could be standardized across machines, so it would also be neat if (d) the standard allowed for multiple concurrent sessions transparently, as well as file transfers, all dynamically configurable. (Not just multiple resident invocation of the same code, but one link turned into 12, like uwm, or dnet on amigas and unix.) (I'm almost making it into a terminal program itself.) One of the main things would be to make it very transparent to the other programs running--so that even if you were on some weird (but somewhat secure) network, you could run a program on this standard between your telnet on your machine and it's connection to the network. (I may be speaking nonsense here.) Whether you were really using kermit, telnet, ftp, or zmodem, the underlying connection would be secure. Anyway, I was just thinking that this might be especially cool if it were compatible across platforms. I figured I'd share those thoughts with any others thinking about secure links, to help maximize the spread of ideas. (And then Timothy Newsham uploads something along those lines even before I can post this. Sheesh! Okay, here's a way to make money by taking bets on this phenomenon: Pick a random person and a cypherpunk, and let them race, with the random person describing a neat program he'd like to have, and the cypherpunk writing it. I'd place my bets on the cypherpunk finishing first. :-) ) Hoping to add to the general confusion, -Mark Shewmaker