🚀 go-pugleaf

I've been working with the following encryption scheme and am wondering
how hard it would be (or if it's even possible at all) to devise a method
of "reversing" it.  Someone has told me this is an "NP-Hard" problem,
but I thought I'd ask all you net.gods.  Here's a description:

The system works by encrypting the data in 8 byte chunks.  So repetitive
data (8-byte aligned) always appears the same way in the encrypted data.

In other words, if the data contains the bytes
 :00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:
the encrypted data might be (as an illustration)
 :01 23 45 67 89 ab cd ef:01 23 45 67 89 ab cd ef:01 23 45 67 89 ab cd ef:
But the sequence
 :ff 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:
might encrypt to
 :11 22 33 44 55 66 77 88:01 23 45 67 89 ab cd ef:

Again, this is just to illustrate the fact that data aligned to the same
eight-byte boundary, and then repeated, has the same encrypted data on
eight-byte boundaries.

This particular encryption method uses an 8 byte key, which is in turn 
passed to a routine to generate a (unique) sequence of 32 bytes used in
the actual [en|de]cryption.

My question is this:  Assuming you know for a fact that a certain eight
bytes of encrypted data decrypt to a known set of eight plaintext bytes,
can you find the original key and decrypt the rest of the data?  The only
information you have is the decryption routine written in C, the eight
encrypted bytes, and the eight plaintext bytes.  The decryption routine
is _not_ the same routine used for encryption.  (i.e., feeding the plaintext
and a key to the decrypter does not generate the encrypted data.)

A brute force approach does work (I've verified that, but it takes a long
time to try all 2^32 possible combinations, even on a relatively fast RISC
machine.)  This is probably acceptable because the number of keys will be 
very high and would take a long time to find them all.  Assuming that
                  Plaintext + Key = Data
it follows there should be some way to then apply
                  Data + Plaintext = Key
I want to know if this logic holds, or if this system is "immune" to that 
sort of approach.

If it matters, the decryption algorithm consists of the routine to generate
a 32 byte "subkey" from the original 8 byte key and another routine with an 
8-cycle loop that exclusive ors, rotates left and adds byte-sized
operands.

Any thoughts, comments, or ideas would be greatly appreciated.

If anyone's interested in trying to "reverse" the decryption algorithm,
I could consider mailing/posting my C code decryption algorithm and some 
sample data.

Best regards,
Ed

--
Ed J. Gurney  N8FPW       Hewlett-Packard Company      Vancouver Division
egurney@vcd.hp.com                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak