Re: steganographic trick

In a message dated 96-03-07 23:02:48 EST, vznuri@netcom.com writes:

>imagine an application where you freely admit that you have your
>cryptographic tools, and that you are even willing to tell the
>"feds" the key for your data. they run the crypto program, and
>indeed the file decrypts. however, unknown to them, you have given
>them a key that decrypts the file into something meaningful yet
>benign, such as a cookie recipe, not
>your plans for the overthrow of the state. in other words, 
>"interlaced" or "coincident" within the same file is your secret
>data. given one key, it decrypts into one set of data, and given
>another key, it decrypts into another set of data.

The only computationally feasible way to accomplish this would be to use a
variation of the one time pad (OTP) cipher, and use two keys:  the genuine
key, which is made by the random number generator of your choice, and a
specially cooked key generated by XORing the encrypted message with an
innocuous message.  Decrypting with the random key will yield the real
message, and decrypting with the cooked key will yield the innocuous message.
 The disadvantage to this system is that each key will be the same length as
the message.

The method you propose (using multiple RSA keys) is not workable.  Finding 2
RSA keys that will decrypt a given ciphertext block to any 2 meaningful
plaintexts is at least as difficult as breaking RSA, and expanding this
concept to messages longer than 1 block moves it into the realm of
impossibility.

Jonathan Wienke

>> given one key, it decrypts into one set of data, and given
>>another key, it decrypts into another set of data.
>
>The only computationally feasible way to accomplish this would be to use a
>variation of the one time pad (OTP) cipher, and use two keys:  the genuine
>key, which is made by the random number generator of your choice, and a
>specially cooked key generated by XORing the encrypted message with an
>innocuous message.  Decrypting with the random key will yield the real
>message, and decrypting with the cooked key will yield the innocuous message.
> The disadvantage to this system is that each key will be the same length as
>the message.

I don't agree that this is the only way to accomplish the problem I proposed.
I gave a scheme that is not equivalent to the one you state. you seem
not to address my actual technical description, although I admit it requires
a bit of inference on the part of the reader.

in the scheme I proposed, P1 and P2 are the two keys. an XOR or OTP
system has nothing to do with what I described.

one problem you do remind me of is that P1 and P2 are going to be
hard to "remember". of course the way PGP handles this is a pass
phrase that unlocks the encrypted key using the IDEA cipher. another
interesting approach would be to use a hash of the passphrase as
a random seed in the process to get the prime number. in other words,
the passphrase is the seed to the algorithm that hunts for the prime
number starting at some random location, and if fed the same seed
(the hash of the passphase) it will again find the same prime number....

>The method you propose (using multiple RSA keys) is not workable.  Finding 2
>RSA keys that will decrypt a given ciphertext block to any 2 meaningful
>plaintexts is at least as difficult as breaking RSA, and expanding this
>concept to messages longer than 1 block moves it into the realm of
>impossibility.

I believe you have misunderstood my description. I gave a feasible system.
I don't know precisely what you mean by "multiple RSA keys". my system
did not have any aspect of public key crypto to it. it is a single
key cipher.