From: mlshew@dixie.com (Mark Shewmaker)
Date: Thu, 17 Jun 93 05:37:13 PDT
To: mlshew@dixie.com
Subject: Rude CryptoStacker Suggestion (LONG)
Message-ID: <m0o6EiV-0000BaC@dixie.com>
MIME-Version: 1.0
Content-Type: text/plain


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