XOR Compare result?

vining

First let me say I hate using AMX modules. I got this duet module for an HAI system since I want to use IP comms but it doesn't give me features I want so I PASSTHRU and PASSBACK but this stupid module sends back the encrypted data it receives not the decrypted it processes and of course the comm module doesn't share the session ID or the encryption key it generates from the session_ID and the known to both parties Private Key. This is all in hex and the encryption is 128 bit AES so for tasks that could have been very easy if the module was written properly or the comm module open this has turned into a real PITA!

Now for my encryption key I need the MSB 88 bits of the private and the XOR result of the LMB 40 bits of the private key compared to the 40 bits of the session ID. My problem is sometimes my XOR is right when compared to a calculator at which time the controller sends me an ack but often the XOR result is wrong and I get nothing.

//locals only for use in debug
LOCAL_VAR CHAR cSessionID_5b[5];
LOCAL_VAR CHAR cPrivKeyMSB_11b[11];
LOCAL_VAR CHAR cPrivKeyLSB_5b[5];
LOCAL_VAR CHAR cSessionXOR_5b[5];

cSessionID_5b  is  7B, 63, 68, A6, 67
cPrivKeyLSB_5b is  8E 30 DB F9 54

for(i=1;i<=5;i++)
             {
             cSessionXOR_5b = "cSessionXOR_5b,(cPrivKeyLSB_5b[i] ^ cSessionID_5b[i])";
             }

When the XOR works the subsequent AES encrypt/decrypt works fine so I need figure out why my XOR code might work xOR might not. I hate this binary BS so I'm hoping some of you smarter coders who do right shift, left shift stuff might enlighten me.

vining

This seems to work reliably but I'm too burnt to know or care why!

for(i=5;i;i--)
             {
             cSessionXOR_5b = "(cPrivKeyLSB_5b[i] ^ cSessionID_5b[i]),cSessionXOR_5b";

richardherman

If you restrict your test to 5 bits and actually run with the example values you give above (cSessionID_5b is $7B, $63, $68, $A6, $67 and cPrivKeyLSB_5b is $8,E $30, $DB, $F9, $54) you get different outcomes when you run this multiple times?

It's not really clear in what context this runs (seeing the local scope) and how things are initialized, but I made a function with both the 'up count' and 'down count' variant and compared the results. I ran this 1000 times in a loop and kinda as expected got identical results all the time.

Seems to be an expensive operation: took minutes to complete the '1000 times loop' on a NX-1200

vining

The 5 byte session ID I get when connecting to the device so I only have to XOR this once to the LSB 40 bits of the 128 bit private key. Then this result combines with the MSB 88 bits of the private to become the 128 bit AES encryption key. Later I do have to XOR two different bytes and then do the AES encryption every time I send or receive a message.

The session ID is randomly generated by the controller upon each connection and I’m pretty sure there were several occasions when the up/down variants didn’t produce the same result. I can’t imagine why especially if it just does 1 byte at a time.

If the XOR of the 5 bytes works properly then I have the proper AES encryption key and everything works but with the ++ loop there was a high failure rate so I assume it has something to do with what value session ID I get from the controller. I don’t know enough about bitwise operations to have any reason why this happens but maybe going from left to right and the first byte is $10 (16) or less it takes the the first 4 bits of the next byte in order to grab a full 8 bits. I don’t know if that makes any sense at all cuz I don’t know bitwise ops but thats why I tried looping down so it grabs from right to left. Of course if that first byte under $10 (16) I guess the same would happen if that theory is correct. Actually probably not since they would need the 0,0,0,0 but on the left side they often leave off those four zeroes.

Is there a better way, a proper or preferred way to do and XOR operation on 5 bytes?

richardherman

So this is probably not very useful, but just for the fun of it, I changed the loop to use a randomly generated 5Byte hex SessionID each run of the loop. By accident this ran 1million times (...), so 1 million times it generated a 5 byte session id and XOR'ed with the 'private key' with both the 'up count' and 'down count' variant and it came out the same all 1 million times. So. Probably need to get a life.

vining

Well its quite possible something else was going on and my var wasn’t populating properly. I didn’t have time to dwell on it and once I saw the backwards loop seemed to be reliable on just moved on. Thanks for running the tests that I was too lazy to do so I now feel more certain the code will work without a random hiccup.