Encryption (again)

Sorry, I know this has been discussed a zillion times, but reading all the discussion has so far just made me aware of conflicting opinions (and granted, maybe that's as good as it gets...)

What do I use for encrypting passed messages in SL?

llMD5String is apparently weak:

/54/3c/78164/1.html#post807514


llXorBase64Strings (granted, deprecated in favour of llXorBase64StringsCorrect) is apparently also weak:

http://rpgstats.com/wiki/index.php?title=LlXorBase64Strings


_________________________________

Granted, I realize nothing is ever, ever 100% secure. It used to be burying your gold in a hole in the ground and posting guards around it used to be secure. But then over time both the guards and you died off :} and then it was free for the taking for whoever happened to be planting potatoes there and found it :} SSL is considered secure, but basically secure really just means how much is what you are trying to protect worth someone else trying to break that protection?

I have two supplementary questions:

(1) For my current purposes, I just need something that will be uncrackable by, say, 97.45% of the population, as no money is involved. It will only be read once, at start up, so response time not overly a consideration (though a response time less than a minute would be ideal, grin.) Based on that, what would be the appropriate method.

(2) Say, though, that money *were* involved. In that instance, what would be the appropriate method.

MD5 isn't encryption, it's a hashing function.

Hashing functions can be used in two ways to ensure data isn't tampered with.
1) simple message hash - Just hash the message
2) secret message hash - Do something secret to the message and hash that.

You use it for signing messages so you know they are valid. You hash the result of doing a secret manipulation on the message. For someone to change the message and produce a valid signature, they would have to determine what the secret manipulation was. MD5, SHA, etc. all make backtracking next to impossible.

To use the first method successfully, you keep the hash and the message separate. This way if someone modifies one, the pair don't match. The big problem with MD5 is that modern crypto analysis has produced ways of generating hash collisions. A collision is when two different messages produce the same hash. The goal of a good hash function is to making producing a collision for an arbitrary hash very difficult. There is source code available for producing MD5 collisions and rainbow tables.

llXorBase64Strings isn't encryption either, it just a bitwise xor. Through data analysis you can determine what the xor is. The more data collected that uses the same xor, the more certainty.

---

What to do?

It really depends if the message needs to be encrypted or just hashed.

If the message just needs to be hashed, then you use a sufficiently complex secret manipulation and MD5's weaknesses more or less go away.

If the data needs to be encrypted that is another issue. Data encryption in LSL is slow and complicated. If you don't need encryption you shouldn't bother.

Security is only as strong as the weakest link.

---

You need to tell us more about the communications so we can help you.

Aside from the security "strength" concerns, the first question would be are you trying to obfuscate or simply authenticate? IE, do you care if someone sees the data, or you just want to be sure it comes from a trusted source?

If you want obfuscation (ie, to hide the data itself), then you will have a severe speed vs security tradeoff in LSL. llXorBase64StringsCorrect is fast, but is almost trivial to break. Using a real cipher, like XTEA, is much slower, but is much more secure. MD5 is not a cipher, but a hash. IE, it is not useful for encryption (obfuscation) at all, but is still pretty good for authentication, even despite its weaknesses.

If you want just authentication, MD5 is fast and can easily be set up to provide a nearly bulletproof authentication mechanism.

As from my experience 99% of the ppl in SL aren't scripters, using a really huge random chat channel is probably all the security you need. But if you mean 97.45% of the scripters, that's a whole other thing.

I believe there is an XTEA script that is supposedly very very strong on the lsl scripting library. Remember not just to use a password, but also to modify it slightly/randomly, possibly using the date,object position, object key, time, etc.

You should NOT change the inner workings of an encryption/hashing function unless you know what the effect it will have. The functions are designed and evaluated by people who specialize in this area of math; these functions are thoroughly vetted. Making a random change to the math may very well introduce a hole that weakens the algorithm.

Funny you should mention XTEA, I was just working on a new LSL implementation that should be faster then all the others.

Really?I'd love to get a copy. XTEA appears extremely slow.

Would love to see it. Mine's about as fast as I think it can get, but I'm always interested in your crazy optimizations.

I have a preliminary version on the wiki. I think I have the math correct but I haven't put in place all the optimizations I want to. There are a number of helper functions that I have written but they won't be released until I have ported a couple more algs and package them as a single ESL library.

https://wiki.secondlife.com/wiki/XTEA

LOL! Yeah, fair enough, grin!!!!!!!

I read Bobby's comment differently, not as modifying the algorithm, but rather modifying the password dynamically. For example, a script can have a hardwired password, but then concatenate that with the object key - which will be different for each object using the script. That way, no two objects are actually using the identical password.

In theory, it's easier to crack a single password if you have a large set of data encrypted with the same password. This would reduce that risk. I'm not entirely sure it's worth it, though.

Ah yes, making the inputs dynamic is a very good idea and is something I advocate people should do.