Trouble decoding from server

hello i am having troubles decoding my messages from my server. i am having no troubles encoding in sl and decoding the message on my server however when i send a message back i cant seem to decode it.
here is my php functions to encode on my server

 function XorBase64Strings($s1, $s2){
 	$s1 = base64_decode($s1);
 		$s2 = base64_decode($s2);
 	while(strlen($s2) < strlen($s1))
 			$s2 .= $s2;
 	return base64_encode($s1 ^ $s2);
 }
 
 function cryptit($s1){
 	return XorBase64Strings(base64_encode($s1),base64_encode($pass));
 }
 

and my lsl function to decode it

 string decryptit(string mess)
 {
 	return llBase64ToString(llXorBase64StringsCorrect(mess,
 							llStringToBase64(pass)));
 }
 
 

Personally, I'd completely discard the 'encoding'. A polyalphabetic cipher like that is so weak as to be next to useless, and an attack model that has people able to intercept your messages in the first place (and the resources and determination that requires) would mean that cracking your 'encryption' is hardly a barrier.

Bear in mind that the only people that can read messages you transmit using email or http requests inside an LSL script are Linden Labs (who don't need to, since they could read your script directly and get the password anyway), whoever runs the server you host your site on (same issue, only at the other end), and anyone in between (who almost certainly doesn't care, because it's an insignificant amount of traffic on a router that carries far more important things). If you're really concerned about those people in the middle, sending it via HTTPS (with a self-signed certificate if need be) is a far better idea.

If you simply want to verify the message hasn't been altered in transit, or you want to publish the code but prevent anyone from spoofing messages to your server, look into HMACs - they can be calculated using the built in MD5 function, and are both more secure and easier to implement properly.

i really just need this to work to stop someone adding a script to my modifiable objects to read the incoming httpreply and compromise the system.

Hm. That's a situation I hadn't considered. Actually, I wasn't aware that the http_response event fired for scripts other than the one that sent the request in the first place. Are you sure that's the case?

If so, bear in mind that this method of 'encryption' is extremely weak. Worse, if you use the same key every time, not only does it become a lot easier to decode the message, but if someone successfully decodes one, they have your key and decode every single message you send.

Unfortunately, implementing _good_ encryption in LSL is not easy. Not impossible, but not easy either.

That is the case. I use this to monitor the communications between my web server and in-world scripts.

I'd still reccommend avoiding using the polyalphabetic cipher mentioned above. I can't provide much of an alternative right now, though - when I have time I intend to implement RC4 in LSL and PHP, though.
In the meantime, please, _please_ at the very least generate a random password in your request and store it and send it to the server to encode the response with. Ideally, if you know the length of the response, you can generate one as long as the response will be and be as secure as the RNG will let you be.

yes it does, i might have to give https a try thou i have no idea how to implement it. know of any helpful links? or even a better an encryption method that someone that is written in sl and php that is far more secure .

HTTPS won't help security at your endpoints - only in transit, which isn't much help.

Sorry, no, I'm not aware of any implementations of decent encryption algorithms in LSL. Which isn't to say there aren't any.

There is an implementation of RSA in the library but its author states that its rather slow.

Also, RSA is public key encryption, which, apart from being overkill for this sort of application, isn't really practical without a symmetric cipher to go with it.

It looks like the most practical symmetric cipher to implement in LSL is TEA - its state is a mere 6 32bit ints, so it should be doable without resorting to lists. The main difficulty is translating each 8 bytes of text into 2 ints - not easy in LSL.

hmm, apart from sorting out non printable ascii codes and any big and little endian issues something like this would work?

string characters = " !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~";


integer Asc(string str)
{
    string s = llGetSubString(str,0,0)
    integer index = llSubStringIndex(characters, s);
    if(index >= 0) index += 32;
    else index = 255;

    return index;
}

integer Str2Int(string str)
{
    integer val = 0;
    integer index;
    for(index = 0;index<4;++index)
    {
        val << 8;
        val += Asc(llGetSubString(str,index,index));
    }
    return val;
}

not in a position to try this in SL, and not really sure how LSL would cope as it doesnt support unsigned values but this a literal translation of the Tiny Encryption Algorithm.

integer delta = 0x9e3779b9; // a key schedule constant

list EncodeTEA(list vdata,list keys)
{
    integer y = llList2Integer(vdata,0);
    integer z = llList2Integer(vdata,1);
    
    integer k0 = llList2Integer(keys,0);
    integer k1 = llList2Integer(keys,1);
    integer k2 = llList2Integer(keys,2);
    integer k3 = llList2Integer(keys,3);
    
    integer sum = 0;
    integer n = 32;
    while (n-- >0) 
    { 
        sum += delta;
        y += ( (z << 4) + k0) ^ (z + sum) ^ ( (z >> 5) + k1);
        z += ( (y << 4) + k2) ^ (y + sum) ^ ( (y >> 5) + k3);
    }
    
    return [ y, z ]; 
}

list DecodeTEA(list vdata,list keys)
{
    integer y = llList2Integer(vdata,0);
    integer z = llList2Integer(vdata,1);
    
    integer k0 = llList2Integer(keys,0);
    integer k1 = llList2Integer(keys,1);
    integer k2 = llList2Integer(keys,2);
    integer k3 = llList2Integer(keys,3);
    
    integer n = 32;
    integer sum = delta << 5;

    while (n-- > 0)
    {
        z -= ( (y << 4) + k2) ^ (y + sum) ^ ( (y >> 5) + k3);
        y -= ( (z << 4) + k0) ^ (z + sum) ^ ( (z >> 5) + k1);
        sum -= delta; 
    }
    return [y,z]; 
}

I wrote these functions a while ago. They should handle any character you can throw at them.

integer UTF8ToUnicodeInteger(string a)
{
    integer b;
    if(a = llEscapeURL(llGetSubString(a,0,0)))
    {
        if(1 == b = llStringLength(a))
        {
            if(48 == (b = 48 + (integer)a))
                b = (!!b << 4) + 48 + b = llSubStringIndex("0ABCDEFGHIJKLMNOPQRSTUVWXYZ      abcdefghijklmnopqrstuvwxyz",a);
        }
        else if(!(b % 3))
        {
            a = (string)llParseString2List(a,["%"],[]);
            if(b == 3)
                b = (integer)("0x"+a);
            else 
            {
                b = ((b & 0x3f) |
                    ((b & 0x3f00) >> 2) | 
                    ((b & 0x3f0000) >> 4) | 
                    (((b = (integer)("0x"+llGetSubString(a,-8,-1))) & 0x3f000000) >> 6) | 
                    ((b & 0x3f) << 24) | 
                    (((b = (integer)("0x"+llDeleteSubString(a,-8,-1))) & 0x100) << 22)) &
                    (0x7FFFFFFF >> (30 - (5 * (b/3))));
            }
        }
    }
    return b;
}

string byte2hex(integer x) 
{
    string hexc="0123456789ABCDEF";
    return llGetSubString(hexc, x = ((x >> 4) & 0xF), x) + llGetSubString(hexc, (x & 0xF), (x & 0xF));
}
 
string UnicodeIntegerToUTF8(integer a)
{
    if(a <= 0) return "";//unicode & utf8 only support 2^31 characters, not 2^32; so no negatives.
    integer b = (a >= 0x80) + (a >= 0x800) + (a >= 0x10000) + (a >= 0x200000) + (a >= 0x4000000);
    string c = "%" + byte2hex((a >> (6 * b)) | ((0x7F80 >> b) << !b));
    while(b)
        c += "%" + byte2hex((((a >> (6 * (b=~-b))) | 0x80) & 0xBF));
    return llUnescapeURL(c);
}

The TEA implementation looks fine - the lack of unsigned ints shouldn't affect it, as the sign only affects the outcome of comparison operations - bit shifts and additions should work regardless.

The UTF8 converters won't work on the ciphertext, as it won't be UTF8, merely a string of bytes. We need one adapted to converting ints to plain-old binary octets. Alternately, we could encode them as hex, which may be easier.