Prepare yourself for llRegionSay()

Any communication can be intercepted. No matter what. Email is considered one of the least secure methods of communication and even in SL the emails have to transverse unknown data paths between two servers inorder to be transmitted from one object in one region to another object in another region. for anyone sending sensitive information across a network there is a worry it may be intercepted by an automated ststem looking for particular paterns of data and relayed to someone who may use it for the wrong purposes.

As for trusting sensitive information to llXorBase64StringsCorrect().... Its considered the weakest form of data obscuring (not encryption) in SL. Maybe for just hiding non sensitive data then it may be ok to hide some activation codes.... but for any system that has information of a financial nature where it could be used to access someones funds either in L or real USD then this is worth about nothing.

BTW... Your method is not worth much since if the receiver looses a message then it will always be 1 passphrase out of sync with the sender.

Strong encryption between objects and between SL and a web server may not be for everyone.. but for businesses like SL Exchange and Ginko Bank then it has to be worth more than nothing.

Its up to each individual to decide how much protection they need to prevent thier data to be misused. For me I would be happier using a stronger encryption in objects that I use in giving permissions to access my account funds. SL is not the most secure system and you have to remember that over 80% of computer crimes are commited from internal sources than from external.

Of course this method of encryption is not to use for financial purpose, as llRegionSay() is!

Apart from this XOR operations are the only secure method of encryption from cryptologic theory, as long as the data stream and password stream have infinit length and the password stream is random. Any other method can in theory and mostly also in practice be broken, depending on the effort, analytical and computational, trying to do so.

But I would expect, people using llRegionSay() might just prevent simple sniffing and data collision. For such purpose the above described method is more than usefull and has only little effect to performance. For further optimization passwords might be kept already Base64-encoded within the script.

And I would not work for Microsoft, no matter how much they might pay.
But I actually do have something to do with computer science; I am a systems analyst and studied informatics in amsterdam with the focus on operating systems theory and design.

And to the case of loosing sync, you might provide an extra sync password, that is only used, when you expect sync has lost and decoded data is useless and does not contain the expected magic. When failing this way, send some request with the snyc password encrypted to resync the other side. When you never use it, expect in such a case, it will not be broken! If you expect a larger number of fails, exchange sync passwords regular time basis. There are many ways to have secure encryption in SL, with only little performance penality.

I work with computers as well and focused on computer security while at University. XTEA is a mathematically applied series of XOR and Shifts that do provide a strong protection. When using llXORBase64StringsCorrect() on data to obscure it it applies only 1 bit by 1bit XOR application from Key to String and repeats when it reaches the end of the Key... Not really very secure.

The reason I put together the code that I did though was that I am developing a new rental system that processes all payments to renters through 1 main board and so does not need the owner to be in the SIM to reauthorize payment permissions each time a new rental object is created or replaced. in this situation i needed something that I could securely send requests from the rental objects to the board from anywhere in the SIM (Originally done through renaming 2 communicating prims which read each others names along with the encoded data they contained) this however will now be replaced with llRegionSay() using encryption on specific channels. While checking the senders key is one way of ensuring the source of a request its not really something I would want to rely upon and don't want others to intercept plain text of these transactions.

PHP -> LSL encryption is also needed as some of these payments will be made by Paypal and the credits passed from a website as in world credit to rental objects.

We need now a SIANA (Second Internet Assigned Numbers Authority).

If you try the code example, I have written down extra for you and we expect you send all the time the very same data stream in a certain length, then we can tell from length how many tries someone might need from the number of passwords and the length of the password sequence list until it is not secure anymore.
So we know, the quality of our XOR implementation relys on the number of different passwords and their length, as well as it depends on entropy in our data stream in reality.

Or the question might be, how many passwords of which length will be the best for you and your purpose?

Well this might depend on the varity of tokens in your data stream and the quality and number of different passwords. But since your data is not always the very same, it would not make any sense to send such data exept for triggering something, for what we would not need encryption for, there is some kind of variation in the stream, which depends in case of accounting data on the position within the stream since some data might be redundant from time to time.

Anyway, as long as people do not send billing data with it, this is a good and very fast solution for communication within SL.

In your special case it might also be a good solution but very depended on the amount of passwords, their length and the length of the password sequence when using them.
Perhaps to much work to analyze where how much security it would give you in which setting. A long term sniffer with a good cryptoanalytical background will hack this as well as your XTEA and most other encryption standards anyway.
It's always just a question of effort that someone is willing to use.

Well, here some sniplet of code for those who do want to have some fast security coding, but do not expect from it to use it for transfering money or billing data:

// In SL fast encryption is only enhanced through the use of Base64 encoded data,
// since there is only one function to XOR data really fast and that is based on
// Base64 encoded data streams.
// So we use Base64 encoding and decoding to be able to make use of the
// function "llXorBase64StringsCorrect()" for XOR encryption purpose.
// The quality of the securness of XOR encryption is only dependend on the quality
// of randomness and varity of your passwords and sequence we use them.
// The following rules might take in account when filling the gaps in this
// code sniplet:
//
// a) A small number of passwords and long sequence using them is
//	 very unsecure!
// b) A large number of passwords and minimum length sequence is most secure
//	 in this sense!
// c) A password should be at least as long as the average length of the
//	 data that has to be encrypted with it, while it would be optimal to have
//	 passwords that have teh same length as the data stream that has
//	 to become XOR combined with!
// d) The sequence of using passwords should not be simply monoton incremental
//	 or decremental or monoton in any other way
 
// a list of clear text passwords, but it would be less byte consuming to
// precode them and only have a list of base64 encoded passwords instead
// of cleartext + encoded in sim memory
list gClearTextPasswordList = [ "secretsecretsecretsecretsecretsecretsecret",
										"secretsecretsecretsecretsecretsecretsecret",
										"secretsecretsecretsecretsecretsecretsecret",
										.
										.
										.
										.
										.
										"secretsecretsecretsecretsecretsecretsecret",
										"secretsecretsecretsecretsecretsecretsecret",
										"secretsecretsecretsecretsecretsecretsecret" ];
 
// "gBase64PasswordList" contains a number of passwords.
// CHANGE THIS TO A NUMBER OF "Base64" PRE ENCODED PASSWORD VALUES
// OF YOUR CHOICE IF YOU WANT TO LOWER MEMORY USAGE OF THE SCRIPT !!!
list	gBase64PasswordList;
 
// contains the position of the latest used position in "gPasswordSequenceList"
integer gPasswordSequencePos = 0;
 
// contains the maximum available number of passwords in "gPasswordList"
// CHANGE THIS VALUE TO THE NUMBER OF VALUES IN
// "gPasswordSequenceList" !!!
integer MAX_PASSWORDS = ... ;
 
// contains the maximum available number of passwords in "gPasswordList"
// CHANGE THIS VALUE TO THE NUMBER OF VALUES IN
//"gPasswordSequenceList" !!!
integer MAX_PASSWORD_SEQUENCE = ... ;
 
// "gPasswordSequenceList" contains a list of number referencing
// the passwords in gPasswordList in some random fashion
// CHANGE THIS TO A SEQUENCE OF NUMBERS BETWEEN 0 AND THE MAXIMUM
// NUMBER OF PASSWORD VALUES FROM YOUR CHOICE !!!
list	gPasswordSequenceList = [ ..., ..., ..., ... ];
 
// we fill the password list with pre encoded Base64 values
create_base64_password_list()
{
	integer i = 0;
	for(i = 0; i < llGetListLength( gClearTextPasswordList ); i++)
	{
		gBase64PasswordList = gBase64PasswordList + llList2String( gClearTextPasswordList , i);
	}
	// empty "gClearTextPasswordList" now to save memory space ???
}
 
string encrypt(string data)
{
	// increment to next number in the sequence for next time using this function
	gPasswordSequencePos++;
 
	// retrieving a password in a sequence of passwords from a passwordlist
	// the sequence is stored in "gPasswordSequenceList" and the passwords
	// in "gPasswordList"
	// "gPosPasswordList" represents the actual position in the sequence of
	// "gPasswordSequenceList" indicies
	// it is expected that the passwords in "gPasswordList" are already encoded
	// to Base64 values
	string pwd64 = llList2String( gBase64PasswordList, llList2Integer( gPasswordSequenceList, gPasswordSequencePos ) );
 
	// make sure we do not try to use passwords we do not have in the list
	gPasswordSequencePos = gPasswordSequencePos % MAX_PASSWORD_SEQUENCE;
 
	// now we encrypt data with passord, both based on Base64 encoding
	return llXorBase64StringsCorrect( llStringToBase64( data ), pwd64 );
}
 
string decrypt(string data64)
{
	// increment to next number in the sequence for next time using this function
	gPasswordSequencePos++;
 
	// retrieving a password in a sequence of passwords from a passwordlist
	// the sequence is stored in "gPasswordSequenceList" and the passwords
	// in "gPasswordList"
	// "gPosPasswordList" represents the actual position in the sequence of
	// "gPasswordSequenceList" indicies
	// it is expected that the passwords in "gPasswordList" are already encoded
	// to Base64 values 
	string pwd64 = llList2String( gBase64PasswordList, llList2Integer( gPasswordSequenceList, gPasswordSequencePos ) );
 
	// make sure we do not try to use passwords we do not have in the list next
	// time
	gPasswordSequencePos = gPasswordSequencePos % MAX_PASSWORD_SEQUENCE;
 
	// decrypt the Base64 data with the Base64 encoded password
	return llBase64ToString( llXorBase64StringsCorrect( data64, pwd64 ) );
}

I did not test this code, since I wrote it here just to show how little computing power it will consume, what the major aspect for all who want some security when using the new functionality of "llRegionSay()" might be.

For most of us this might be the best solution for simple, fast and secure communication within one and the same region. How secure depends on the choice of passords, their count and the sequence using them. For many it might be enough to use one password, with a length eual to the maximum length of the data that has to be encrypted combined with some magic number to make sure you do not read messages of third parties.

For all who want to transfer sensible data, you might better make use of XTEA, 3DES or equivalent!

Why, are you hiring?



..and any script can be read, under the same circumstances. So any passphrase you use to encrypt any data, even with the most uber encryption algorithm out there, is no more secure than using llEmail between in-world objects, because anyone AT LL or their hosting facilities can glomp your scripts and read them just as easily as they can read internal emails.

When you send llEmail from one in-world object to another, the email NEVER LEAVES the internal LL network (and, yes, I know they have multiple datacenters; the links between them are dedicated circuits, more than likely with strong encryption). As such, no one outside of LL can get at it any easier than anything else in SL.

So, as far as the level of security you get for llEmail vs LSL encryption, it is identical.



Now, that is very true. Xor is about the weakest form of "encryption" there is, and can easily be broken as a high-school computer science exercise, unless you use something like a one-time pad.



If you are talking to an external webserver, you DEFINITELY do not want XTEA in LSL. Use SSL via https to your server, and get an actual SSL cert for your webserver.



In that case, NOTHING you do in LSL is secure enough. You have to trust LL, because they have access to everything you do.

Outside of that, use the level of security the application requires to protect your data. IE, using US$10,000,000 security facilities and equipment to protect data worth US$100 is overkill.

Sorry, but this is not true. XOR is the only way to have unbreakable encyption at all. How secure it is in practice depends on parameters when using XOR.

If I have two CD's with each exactly 600,000,000 bytes on it, one containing unknown english text (to know this might help you with your crypto analysis) and the other with true random bytes, and combine them with byte wise XOR to create a third cd, how do you want to break the code please?

If you can, I will work for the rest of my life just for you, and don't have a very small income as a systems analyst, I promise!

You would not even notice if all bytes would be the small letter "e" without me telling you!

While encryptions standards have mathematical gaps and create patterns, not unsimillar to pseudo-random number generators compared with true random number generators which do not create patterns, they all have their weakness, that crypto analysts would look for.
This is why a a data stream XOR byte wise combined with a random password stream is the only unbreakable form of encryption as long as both streams have same length. The only pattern you have here is the randomness of the password phrase which is hopefully of true randomness in such scenario.
Without any mathematical pattern there is no way to make any use of the knownledge that the original data stream contains an unknown english plain ascii-text of 600,000,000 bytes length!

So we see, it is dependend on the way we implement XOR based encryption, but not XOR encryption itself is the weakest method, it is the strongest of all depending on how using it and the only unbreakable one that holds proof in theory and practice.

So please, do not spread the false knowledge that XOR is weak in general. It is only depending on the way of use and is truly the only unbreakable form of encryption when used the way described above in the cd example.

And of course, you hit the point in all of this discussion, which was actually about the possible ways to use "llRegionSay()", all encryptions within LL are as secure as the script containing a password phrase is, no more and no less!

That is essentially a one-time pad scenario, which Talarus mentioned. It is the only known, provably unbreakable encryption method, but only as long as the pad is exactly (or at least) as long as the data to be encrypted, and then only if the pad is truely random, and then only if the pad is used at most once, and then only if the pad is not intercepted. Indeed the biggest problem is probably how to get the pad safely to the party who needs it for decryption, without it being intercepted.

Please be sure to read ALL my message next time before you respond. The scenario you describe is called a "one-time pad", and I CLEARLY SAID "unless you use something like a one-time pad".

As Murm said, while the use of a one-time pad makes XOR unbreakable in theory, it is VERY unwieldy in actual use. There are some seeded-random variants which still use some kind of key, but they are breakable. XOR encryption using the same, short, repeating key is trivial to break, which is what I was talking about.



The main problem you have with a generated one-time pad is that the algorithm used to generate it as well as the seed has to remain secret. That's always a bad plan, because good encryption algorithms do not depend on their algorithms remaining secret. The strength of the algorithm and, thus, the security of the data encrypted are thus solely protected by the secret key(s) alone.



I didn't. Everything I said is 100% accurate. READ what was said, and compare: http://en.wikipedia.org/wiki/XOR_cipher

Sorry! I missed the one time key pad, because I was already a ltiile upset from the argumentation of the guy with this 15-30 second X TEA slowing only sims for the sake of little security, which can be brocken easily anyway, since X TEA is not that good cipher at all.
That XBoxes use TEA for hashing does not make it any better, while it remains slow in LSL here and is not any more secure than that TEA in such box stuff, where it isn't secure at all as it has verified in the past.

So, I am sorry Talarus. I should have read your post more carefully!

I think the main issue in this is for each person to decide how important and sensitive the information they are transmitting and how much trouble might be caused if its intercepted.

XTEA provides a solution to those who want to have a little more protection that the simple XOR provided in LSL.

While it is true that everything might be accessible by the lindens and the security of SL is very dependent on how much you trust the Lindens there is another group that should be taken into consideration.

Greifers are many and Varied. Sometimes its a personal issue and sometimes its a fundamental conflict of beliefs that cause these people to come out and cause mischief. But what cant be denied is that these people seem to have one thing in common.... their dedication to cause heartache for those they grief and they seem to think nothing to spending large amounts of time and resources to "Prove" their point.

Anything that can assist in helping to delay their goal can only be beneficial and for the most part I feel better having another tool that can forestall these individuals if they decide to target your information.

Griefers have no more or less access to the inner workings "behind the scenes" than any of us do. As such, they cannot intercept llEmail messages between objects any easier than they can steal script source code.

In fact, there have been numerous "holes" in the past which have allowed people to get access to script source code, and zero instances (that I know of) of llEmail (object<->object) interception.

What does that tell you?

As for XTEA being a weak algorithm, yeah, it is, but like I said earlier, use the proper amount of security effort to protect your data.

Well, according to wikipedia - http://en.wikipedia.org/wiki/XTEA - "As of 2004, the best attack reported on XTEA is a related-key differential attack on 26 out of 64 rounds of XTEA, requiring 2^20.5 chosen plaintexts and a time complexity of 2^115.15 (Ko et al, 2004)."

And as you can see here http://cist.korea.ac.kr/~wonil/papers.htm (one of the co-authors' profile) these are people with doctor degrees, and specializing in cryptography and cryptanalysis. I don't mean to underestimate the resourcefulness of griefers, but I think it is safe to say that cracking XTEA is beyond the average griefer's capability (it sure as hell is beyond mine). In fact (although I don't know if there have been more successful attempts since 2004), it seems that nobody has been able to break XTEA encryption with sufficient rounds yet. The problem is of course that every extra round of XTEA in LSL is going to add a notable time delay.

Extra layers of protection for object to object communication in SL, as for example with llRegionSay, could be to use random chat channels, changing the channels after each message or after some time interval, and splicing each transmission over multiple channels (sothat to intercept an entire message, a griefer would have to listen on all of those channels at the same time). Depending on the level of security you need, you might not even need to encrypt the message itself, or just use a simple XOR scheme, saving you a lot of sim performance (in exchange for the extra listeners of course).

To generate random channel numbers, a cryptographically secure PRNG can be used (xtea or xxtea could be used for that as well, or even just MD5). The seed wouldn't need to be known a-priori, any number will do, for example the time, or the traffic value of a plot of land (although the traffic stat will be taken out by LL, but just to name an example). So even if a griefer knows your algorithm, and knows where you get your seed from, they would not know what value is actually used for the seed.

The LSL wiki has a "protocol" page where you can list your chat channel number and the protocol if you wish.

Another glitch has come to light within the PHP script. This involves the decoding of the final Base64 string to get the plaintext of the message.

Thanks to Tobia Forcella for reporting this bug.

It affected charaters with Hex value patern of 0x?0 and was the last charater in the string when the string length was 2,5,8,11, ...etc. In this situation the last charater was not being decoded propery and was being dropped. This was due to the need for me to manualy add the padding charaters to the end of the string to allow PHP to decode to text. the "==" padding did not work in this case.

I have worked out a fix for this and have updated my code posts to reflect this.

in the "function xtea_decrypt_string()

 $i = strlen($result);
 $mod = $i%4; //Depending on encoded length diffrent appends are needed
 if($mod == 1) return base64_decode($result . "A==");
 else if($mod == 2 ){
  if(strlen(base64_decode($result . "==")) < strlen(base64_decode($result . "A="))) return base64_decode($result . "A=");
  else return base64_decode($result . "==");
 }
 else if($mod == 3) return base64_decode($result . "=");
  return base64_decode( $result );

just a small break in the seriousness.

i thought this said "llReligionSay() and i was desperately trying to think of a way to block it!