From: “Gary Jeffers” <CCGARY@MIZZOU1.missouri.edu>
To: cypherpunks@toad.com
Message Hash: 787437f3d5da8e695b8452d5e6f38067328a298ac28797ef0dcc11f9fce5e493
Message ID: <9403030457.AA05934@toad.com>
Reply To: N/A
UTC Datetime: 1994-03-03 04:57:24 UTC
Raw Date: Wed, 2 Mar 94 20:57:24 PST
From: "Gary Jeffers" <CCGARY@MIZZOU1.missouri.edu>
Date: Wed, 2 Mar 94 20:57:24 PST
To: cypherpunks@toad.com
Subject: Standard for Stenography?
Message-ID: <9403030457.AA05934@toad.com>
MIME-Version: 1.0
Content-Type: text/plain
Firstly, congratulations for Sergey Goldgaber's stubborn pushing of
this topic, for Bill Stewart's observation: "simple stego-programs,
stealthy encryption programs", & for Norman Hardy's notice of the
possibility of non-randomness in the low order bits of pixels.
Here are my proposed standards & suggestions for stenography.
1. The stenography module is just a simple program for inserting data
into a picture. The data is not plaintext! Ideally, stealth pgp is
the encryption method. There should be no clever variable positional
stenography. No security through obscurity. No "TOWERS of BABBLE".
It must be standardized for easy conversation.
I agree with Bill Stewart on this: simple stego programs, stealthy
encryption programs.
2. The 1st position of the stenography is defined as the 1st pixel
transmitted or received. The 1st several pixels should make up the
header. The header should be of a fixed size with fixed sized &
positioned fields. The header follows:
1____6 7_________17 18>>>>>>>
checksum; "STENOGRAPHY"; the encrypted text
The numbers refer to pixels. One bit of encrypted data per pixel.
The 1st field is a checksum particular to that RSA key. The 2nd field
consists of the word "STENOGRAPHY" in caps. The remainder is devoted
to the encrypted msg. itself.
The checksum is a standardized checksum method that has the same
checksum as the RSA key. You need this in case you have given out
several public keys. The checksum may also be an integral multiple
of the RSA key. The reason for the checksum is in case the recipient
has multiple keys, this will help him select the correct one without
using huge numbers of cycles. Only 6 bits are used since that would be
all that would be necessary & to eliminate the possibility of a huge
number that would be large enough to constitute a legal proof. Also, by
using a small number, investigators are not given much of a clue. By
allowing integral multiples, you allow a fairly large number of keys
but also stop small numbers from popping up a lot - no statistical
suspensions!
The reason for the "STENOGRAPHY" field is to assist your computer in
determining if this is a stenography file & that the correct key was
chosen without attempting to decrypt the whole file. I know that this
presents the possibility of a small "known plaintext attack", but a good
encryption system should stand up to such an attack. RSA can ...
can't it?
3. No "lossy" picture methods! Two methods immediately suggest them
-selves: JPEG & GIF. JPEG is ordinarily a lossy method but I am told
that it has a no loss option. GIF is not a lossy method. I hear that
JPEG has the ability to carry more bits per pixel than GIF so I would
suppose JPEG. Also, while earlier I suggested 1 bit of encrypt per pixel
it may be cool to use more.
4. Norman Hardy has suggested something that I have wondered about: are
low order bits of pixels really randomly distributed? You graphic/
statistic ace's out there need to check this out & inform us. Possibly,
some methods do & some don't? Inquiring cypherpunks need to know!
I don't know too much about graphics, so I could use a lot of help.
5. What are the best pictures to use? I would suggest soft focus pin-
up girls, mountain ranges, clouds, fields of grain, dense vegetation.
Would soft focus help in all these types? note: I think kiddie-porn
would be a bad idea.
The above suggestions support the stealth method- strong encryption-
simple stenography- public key- standardized model.
If I have missed anything or you have a better idea, please let us
know.
Yours Truly,
Gary Jeffers
Return to March 1994
Return to “tcmay@netcom.com (Timothy C. May)”