From: jim@suite.suite.com (Jim Miller)
To: peter.allan@aeat.co.uk
Message Hash: c2dfb980eb2b08ec9d25540efc5f46aff7bb74e6c0e02ccc7da340aa9718586d
Message ID: <9609132008.AA08893@suite.com>
Reply To: N/A
UTC Datetime: 1996-09-14 00:05:26 UTC
Raw Date: Sat, 14 Sep 1996 08:05:26 +0800
From: jim@suite.suite.com (Jim Miller)
Date: Sat, 14 Sep 1996 08:05:26 +0800
To: peter.allan@aeat.co.uk
Subject: Re: really (?) undetectable crypto
Message-ID: <9609132008.AA08893@suite.com>
MIME-Version: 1.0
Content-Type: text/plain
> What about Walter making insignificant changes to the
> cleartext and replacing the hash with the new hash?
> Because you are using an unkeyed hash (and not a sig) he can
> do that and foul up the stegomessage
>
> Walter can still play silly spooks with your stego if he breaks the
> 40-bit encryption.
True. The examples was just illustrative. Given unkeyed hashes or 40 bit
encryption, Walter could also frame you by replacing your bits with ones
that combine into a very incriminating encrypted message and then leaking
the key.
> The cyphertext/plaintext ratio looks like getting
> really huge too. Your messages must all arrive, and
> retain the right order.
>
Hey, I never claimed it was efficient. :-)
Actually, the messages don't have to arrive in order. The correct order
can be discovered by trial and error (e.g. does this combination decrypt
into something readable? No. How about this one?).
Depending on the cryptographic protocol, there may be other, more
efficient means for sending hidden encrypted messages. If, for example, a
protocol requires a cryptographically random confounder to be appended to
the front of the plaintext before encryption, you could use chunks of you
secret encrypted message for the entire confounder.
Jim_Miller@suite.com
Return to September 1996
Return to “jim@suite.suite.com (Jim Miller)”
1996-09-14 (Sat, 14 Sep 1996 08:05:26 +0800) - Re: really (?) undetectable crypto - jim@suite.suite.com (Jim Miller)