integrating GPG with deniable steganography

tftp tftp@yahoo.com
Sat Mar 17 22:54:08 2001


--- Andrew Marlow <apm6674@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/