Allow users to update/'patch' scripts?

Typically, maybe, but that's a stereotype. I don't share my algorithms, and I assure you they use as robust a method as possible. I'm in the "industry" as well, and I know a good algorithm from a bad one, too.

As for "real" encryption technologies in SL; not practical. LSL is SO SLOW that it takes seconds to minutes to do any kind of basic "high grade" encryption. I wrote an XTEA implementation and, as fast as I could make it, encrypting/decrypting 100-character strings took from 8-16 seconds each. Not really good for heavy-duty use.



Actually, I think you might want to learn a bit about how LSL works before you say "easily" anything with regards to brute-forcing a channel. Random channels are actually "fairly" secure, if used on a temporary, one-time basis for each communication.



Security through obscurity actually gets a lot less credit than it deserves. The real axiom to use is "use as much security as you need to make it cost the attacker more to break than what the security mechanism is protecting". In many cases, especially in SL, obscurity is "good enough" for many applications. No, obscurity is not anywhere near as good as a real algorithm, but considering you are probably protecting a few cents' worth of information with it, and it takes dollars' worth of effort to break it, why worry about it? Many times, having "obscurity" heaped on top of industrial-strength cryptography makes it an order of magnitude more difficult to break. Attackers first have to figure out what the heck you are using and how you are using it, THEN they can attack it.



Good advice for a RL product, built on a real platform with a real programming language. It's not practical or feasible to implement strong cryptography in LSL within SL. It's just too limited and too slow. Maybe if the Lindens gave us hooks into OpenSSL or something, that would make it much better, but don't hold your breath on that one.

Encryption isn't really the main issue, especially now that SL can use HTTPS to communicate with sites, data doesn't technically need to be encrypted at all when going outside of SL. Any frequent data within SL as already said just needs a quick, dirty one-time thing such as a simple XOR that uses part of a message to change its key and/or comms channel. So payments are best handled with an outside HTTP server (it's also incredibly useful for detecting and fixing broken vendors or failed transactions anyway), and simple things for games where the time it could take to brute force would be time in which the key you're trying to crack has changed two or three times and is now using a different channel.

The main-issue was just being able to update a script inside an object much more easily. The ideal way would be to have the ability to use llRemoteLoadScriptPin() (possibly the wrong name there) grid-wide for objects. This way an object just checks every now and then with a remote server, if the response it gets back indicates that an update is available, then it creates a 'location key' for itself (which unlike current queues can be used to locate an object anywhere on the grid by containing an identifier for the current simulator), and a PIN which can be used to replace its current script. Some controller somewhere in-world can then download the PIN and location key from the outside web-server, and then send out the new script by calling the appropriate load script pin function, using the location key to locate the object, and the PIN to authorise the command.
My thinking here is that the script should inform it's owner when it is being replaced, and what object is doing it (and who owns that object), this allows a malicious use to be reported. e.g a vendor selling an item which then has its script replaced so that it becomes a griefer tool.