From: hughes@ah.com (Eric Hughes)
Date: Fri, 4 Feb 94 10:45:10 PST
To: cypherpunks@toad.com
Subject: STEG: a real-life use for steganography
Message-ID: <9402041840.AA21942@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


I had an extremely interesting conversation with a fellow last night,
say, X.  A mutual friend of ours had steered him towards me.

X has contacts in a country C which will remain nameless.  The
government of C is extremely repressive and has a large internal
police force.  The situation, evidently, is one similar to the old
USSR, where masks behind masks were used in daily life, little is
exactly as it appears, and the default discourse is sideways speaking.

The scenario is almost worst-case.  There is a need for steganography,
since the use of cryptography is grounds for suppression; likewise
there is a need for covert channels.  There is a need for
double-blinding of identities, since one's friends may be difficult to
detect.  And so on.  

The aspect that _is_ good is that C is not the whole world, and there
are plenty of us not in C.  The first most useful facility to set up,
X thinks, is simply news from outside of C as a bypass of the media in
C--wire service articles about C, for example, as well as a feed of
the newsgroup "soc.culture.<C>".

Here's the technique we came up with last night.  C has an indigenous
music M which is periodically performed in the United States.  We were
thinking about pressing short-run CD's of these live performances.  We
all know where the news feeds go.  The CD's would be distributed via
standard music channels and would be surprisingly brisk sellers.  The
costs of the project can evidently be footed by willing members of the
M industry in C.

Now let me address the standard comment "Oh, steganography completely
solves that problem."  Please.  That's like saying, "Oh, just use an
internal combustion engine to solve your long distance transport
problems."  Such statements are a failure of imagination and
seriousness.

A practical system to carry this project out is quite large.  I see at
least the following pieces needed:

 -- A facility to gather the data being put on the disks.  This by
itself is no trivial task, since it involves the collection of many
disparate sources.

 -- An authoring system to arrange the data, once collected, into a
usable structure.

 -- An encryption system for the arranged data.  Such a system can't
treat the data as one long stream, because of the segmented nature of
the data.  The ability to mount the CD as a file system would be good
leverage for other programmers.

 -- A mastering system to combine a music master CD (done separately)
and a data master (in some format) into a new music master CD.  This
will, at the least require a machine with a CD reader and writer.
Blank media, FYI, for a CD writer are about $20/disk.  The CD writer
is about $5K.  These numbers are approximate and falling rapidly.

 -- A CD pressing facility.  These are commercially available at quite
reasonable cost in quantities in the 100's.

 -- A CD distribution system.  This will likely be the M industry, and
thankfully the details of international shipping and customs will be
taken care of, as well as retail distribution.

 -- A decryption system to get the data off the CD.

 -- Client software to make use of the information.  It need not all
be in text format.

 -- A key distribution system.  A secret key per CD and word of mouth
may be sufficient.  A system to make rememberable sentences out of an
arbitrary 128 bits (and the inverse) would be useful to facilitate
word of mouth.

This is no small task.  Those interested in participating may start
working on any of the above.  The tasks are fairly separable.  Here
are some that I can identify as critical.

 -- A standard for encoding data into the low bits of an audio CD.
This will likely require a lot of specific knowledge of the low level
encoding and error correction systems used in CD's.  I do know that
they are not simple, being much more than bit-correcting linear codes.

 -- A standard for the encoding of file system data onto these low
bits.  This should be a separate document, even though the design of
this will be influenced by the bit encoding standard.  Some adaptation
of existing file system standards may be appropriate.

 -- A standard for the encryption format for the file system.  It may
be that Matt Blaze's CFS cryptograpy can be lifted wholesale.

 -- Multiplatform software support for all of the above.

I am pleased to have a real example to work on, rather than a lot of
wixering about hypotheticals.

I welcome discussion of this topic.  

Eric