[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encryption Program (fwd)




(I had only sent this to the 'other' mailing list and not here - my
appologies to those who get this for a second time.  -Giff)


On Mon, 13 Oct 1997 [email protected] wrote:

> Hello. I just posted an encryption program on the web. It uses a key-
> generated pseudorandom stream of characters that get XORed with the 
> plaintext to produce the cyphertext. For decryption, the same stream 
> is run against the cyphertext. (Such is the nature of the XOR 
> operation.) You can download the program at:
> 
> http://www.brigadoon.com/~semprini/3dmx
> 
> I am interested in other people's views, comments, questions, etc. on 
> this program. Any questions, comments, etc. can be sent to me at 
> "[email protected]".
> 
> Thanks,
> 
> Dylan
> 

I have downloaded the program and read over it's contents (the .frm
files).  It's Visual Basic, which I am familiar with.

>From my reading of the code (assuming that the code I read was, in fact,
the code which does the encrypting) - the key supplied is not used - or at
least not directly.

The user apparantly supplies three keys which are padded with 'random'
stuff each to get them to 32 bytes in length.  Then these are placed into
a special array where each bit gets its own position and various scrambing
is done 'randomly' on the data.  This is dependent on the key values and
what bits are on or off at a given time.  During this process, the 'seed'
for the RNG is reset to some unknown value (I believe the effective range
for the seed is 0..65535) the entire time the bits are processed.

Then, amazingly, those bits are not used again.

>From the RNG, a 4 dimensional array (called a 'cube') is created with
elements 0..15 for each of the four sides.  The contents are filled from
the RNG with a value 0..255.

Then during the encryption process of a file, the program will choose four
random numbers 0..15 to use as indexes into the cube.  The number found
there is XORed with the datafile byte to get the encrypted/decrypted
answer.

*whew*  Hope you followed that, I'm trying to be complete and concise.

The upshot seems to be (and I haven't written any code to try this out
yet):  This method fails to the chosen plaintext attack where I ask the
opponent to encrypt a large file of (say) all zero bytes.  The encrypted
result I should then be able to XOR directly against the target file to
get the original contents.

A less efficient but more satisfing method is to simply try all seed
values for the RNG.  Even if I don't know the RNG process, if the seed
values are only 0..65535 (as I believe they are), trying all possible
decryptions by this manner will give me the correct answer.  If I know
something about the file (i.e. being English text) I should have no
problem finding the right answer programmatically.

If I am incorrect about my reading of the program or its operation, please
let me know.

-Giff