From: Jim Miller <jim@suite.suite.com>
To: steve@edmweb.com
Message Hash: 7b320c195957926b0cff55c5048181d877644396dc8aa8200b51c0e196c8755b
Message ID: <9609240307.AA02627@suite.com>
Reply To: <Pine.BSF.3.91.960918231937.568B-100000@bitbucket.edmweb.com>
UTC Datetime: 1996-09-24 09:35:18 UTC
Raw Date: Tue, 24 Sep 1996 17:35:18 +0800
From: Jim Miller <jim@suite.suite.com>
Date: Tue, 24 Sep 1996 17:35:18 +0800
To: steve@edmweb.com
Subject: Re: really undetectable crypto made somewhat practical
In-Reply-To: <Pine.BSF.3.91.960918231937.568B-100000@bitbucket.edmweb.com>
Message-ID: <9609240307.AA02627@suite.com>
MIME-Version: 1.0
Content-Type: text/plain
> I'm on FCPUNX instead of regular Cypherpunks, so please
> excuse me if I'm a little behind the thread.
>
Few on the cypherpunk list replied to my post, so you didn't miss
anything important.
> Instead of hashing just the word in an effort to get stego
> bits, you could hash a key along with the word. In order to
> get the intended hash you would need to know the key. Since
> you're probably hashing a whole block of 512 bits (or
> whatever's specified in the algorithm) appending a key
> should not affect the speed of the system. I'm certain
> that this would increase the security, possibly enough
> that you wouldn't need to use a regular encryption
> algorithm (but I wouldn't bet on it).
>
I like your suggestion, although not for the reason you suggested it
(although your use is a good idea, too). The use of keyed hashes solves
one of the problems I saw with my scheme. The main problem I saw with my
scheme was that it might be possible to detect that an innocuous message
was conveying a hidden encrypted message by analyzing the statistical
properties of the relevant hash bits.
Problem:
If the words in a message are chosen so some of their hash bits (say, 4
bits per hash) combine to form an encrypted message, then those combined
hash bits would be suspiciously cryptographically random, whereas the
combined hash bits of a message that was not created for the purpose of
conveying an encrypted message would not necessarily be cryptographically
random. It is conceivable that a program could be written that uses
this difference to test if a message is conveying a hidden encrypted
message.
Solution:
Rather than using an unkeyed hash, which gives Eve the ability to
generate the relevant block of combined hash bits and test them for
certain properties, use a keyed hash. Since Eve does not know the key
used to hash the words in the message, she will not be able to generate
the relevant block of combined hash bits and will not be able to perform
meaningful analysis of the properties of those bits.
Further analysis:
By hashing words and then using only the first 4 hash bits, what you are
really doing is sorting all words into 16 groups. Group 0 consists of
all words whose first four hash bits are 0000, group 1 consists of all
words whose first four hash bits are 0001, ..., group 15 consists of all
words whose first four hash bits are 1111.
If a message is constructed by selecting words so their first 4 hash
bits combine to form an encrypted message, then, if the message is long
enough or you send enough messages, you will probably select words
"evenly" from each of the 16 word groups. However, I can think of no
reason to assume the distribution of group selections would be "even" for
normal messages. Maybe, by some weird fluke, normal messages are mostly
constructed from words in groups 1, 3, 4, 9, and 14, for example.
By using a keyed hash, your not stuck using a fixed set of word groups.
A different hash key will sort the words into different groups. Hash
keys effectively prevent Eve from knowing which words in your message
came from which groups, thus preventing her from determining if words
were chosen "evenly" from each group.
Jim_Miller@suite.com
Return to September 1996
Return to “Steve Reid <steve@edmweb.com>”