integrating GPG with deniable steganography

[tftp]

--- Andrew Marlow <apm6674 at apmsoftwareltd.alkazar.co.uk> wrote:

> The encode program takes a file containing GPG ASCII-armoured
> text and a file containing chaff, which it just considers to be
> a series of words.

That is good. Shakespeare wrote enough, and it is legal for you to
send me any of his works, one scene at a time :-)

> It rewrites the chaff, separating words with
> a single space to encode a zero and two spaces to encode a one.

??? That's bad. Use a known hash function on the word, and determine
the bit by XORing the 1space/2spaces bit with the hash. This does
not really improve secrecy but greatly improves deniability. The more
obscure calculations need to be done in court the less probable it
will be that the text is not what it seems to be.

The very hash function can be dependent on the hash of entire chaff.
It is easy to recover just by applying known conversion to the stego
stream. For example, all spaces can be removed.

What if you FULL-JUSTIFY the text, then it will be clearly full of
spaces! Like this:

!-------------------margins--------------------!
I  thought   the king   had  more   affected the
Duke    of   Albany   than    Cornwall.   It did
always    seem so   to     us:   but    now,  in
the division    of  the    kingdom,  it  appears
not      which  of the    dukes  he values most;
for  equalities     are  so     weighed,    that
curiosity  in   neither    can  make   choice of
either's moiety.
!-------------------margins--------------------! 

This also gives you not binary but larger base system to encode
data, and you will need less chaff. Full-justified texts are not
something unusual.

> The GPG data is the bit stream to be encoded, minus the header
> and trailer. When the GPG data is exhausted, the remaining chaff
> is encoded with random data using the standard linear congruential
> algorithm (drand48).

Again, if you have the hash of the chaff you can apply some known
conversion to position the encrypted content within the random filler.
Furthermore, you can use that hash to choose between one of several
algorithms which interleave bytes (or bits) of encrypted content with
bytes (or bits) of random content. You can easily generate such
pseudo-random stream by, for example, starting at Nth binary digit
of PI (or use one of other 10,000 known pseudo-random sources.)

All these permutations GREATLY complicate Wendy's task of clearly
explaining how to convert the stego stream into crypto stream.
Most of key points in her testimony will be like "Let's take number
13987298792837490293488023 base 19 and multiply it by 874723ehh398foo93
base 36..." - hard for jury to grok and easy for defense to attack.

The stego s/w can be as large as you want, and also if you want you
can omit some important data from the stego stream. By doing that you
create "Bible Code" problem for Wendy because she must just invent a
number at some point instead of taking it from the stego stream.
For example, if the offset of the crypto stream is not known then
Wendy says: "Let's assume that the crypto starts here..." and that's
the end of her testimony because you do not assume anything on a stand.
The defense will just ask "where this number came from?" and the trial
is over. Alice, however, does not care, and she can easily wait 30 more
seconds while the decoder tries all possible offsets until checksums
start to make sense, and then the missing data is found. Alice does not
need to _prove_ anything, especially beyond a reasonable doubt. If there
are two programs, one that finds the missing number and another that asks
for that number before extracting crypto stream then Wendy will need to
prove that Alice actually used that first program to determine missing
pieces.

> Bob and Alice have to be careful
> that the chaff files they use look like innocent meaningful
> communication. People that know each other generally don't sent
> garbage to each other via email.

If you use the full justification approach as I suggested above
then this problem is gone. The stego stream will be valid text.
All you need is to figure out how to encode bits that you want.
Possibly you will want error-correcting codes - which are easy and
fast to implement, usually, but a nightmare to explain in court how
they work :-) Wendy would need to say "Ok, this number is 3, but
this other number says that it can't be 3, so then it must be 5" :-)

Cheers,
Dmitri



__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/