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
