From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
To: cypherpunks@toad.com
Message Hash: 97fee38757ffbaf924705b947fec2da7692960b72a760a08a069b412b55dcd85
Message ID: <9403020153.AA09443@anchor.ho.att.com>
Reply To: N/A
UTC Datetime: 1994-03-02 02:33:45 UTC
Raw Date: Tue, 1 Mar 94 18:33:45 PST
From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 1 Mar 94 18:33:45 PST
To: cypherpunks@toad.com
Subject: Standards for Steganography
Message-ID: <9403020153.AA09443@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain
There are basically three classes of things you can hide
1) Plaintext easily-recognized payloads
2) Encrypted payloads with easily-recognized forms, e.g. PGP
3) Encrypted payloads that looks like random noise unless you have the key.
(e.g. stealth-PGP or other cryptosystems that don't self-identify.)
The definition of "easily-recognized" is obviously context-dependent,
depending on your threat model. The proposed stego programs are mainly
A) Programs that simply insert the payload, no frills except padding the ends
B) Programs that insert the payload with length-markers and checksums
C) Programs that encrypt the payload while inserting it
D) Mimic functions that adapt the real bits to a given set of statistics
Type A stego is fine for Type 3 data, as long as the statistics of
the file you're hiding data in make random bits believable.
It's obviously not much use for Type 1 data, and only some use for Type 2
data, if you're worried about the Bad Guys knowing that you're sending
secret messages (and you probably are, else why bother with stego?)
So if you're using Type A stego, make sure you use Type 3 random-looking
payloads.
Type B stego is a dead giveaway, like Type 2 payloads, if the Bad Guys
are looking for it. If you're using encryption programs that do
some kind of verification (at least if you have the right key),
then you don't need these functions. Sure, the Bad Guys have to
do the checksum themselves, which takes some work, but they now
have a 256:1 or 64K:1 or whatever certainty there's stuff there.
Type C stego programs are ok, if they're sufficiently high-quality,
but they have to provide most of the functions of a good encryption
program. It makes much more sense to use a software tools approach
and separate the encryption from the steganography -
if the encryption function doesn't advertise itself blatantly.
If you just use a wimpy encryption function (e.g. XOR all the data
with 10101010 or a PRNG), it stops wimpy Bad Guys at the cost of
annoying the rich competent Bad Guys. The main usefulness of this
is for Type 2 payloads, e.g. current PGP, but it's probably better to
use Stealth-PGP instead.
Type D stego can be useful for cases where the host material doesn't
look right if you throw in random bits, and you seriously
need to hide something. It's probably most effective with random-
looking data (Type 3 payloads); with Type 1 or Type 2 the steganized
message will tend to start the same way each time, which is bad,
and if you need the quality of data hiding that mimic functions give you,
you need a high-quality encryption program as well.
All this stuff is essentially saying that you should use simple stego
programs and stealthy encryption programs. Among other advantages,
it means that you *can* standardize on stego programs without risking
the attention of the Bad Guys, and it's much easier to agree on a standard
with almost no options than to waste time on the infinite choice of details
that you can haggle about with Type B stego - especially since
those systems really tend to need good stealthy encryption as much as
Type A stego does.
Bill
Return to March 1994
Return to “wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)”
1994-03-02 (Tue, 1 Mar 94 18:33:45 PST) - Standards for Steganography - wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)