Difference between revisions of "Talk:LlModPow"

From Second Life Wiki
Jump to navigation Jump to search
(New page: When, if ever, are we going to get anything remotely resembling tools to be able to implement some sort of real encryption? We have a small hand full of tools: ModPow, MD5, and a really tw...)
 
 
Line 14: Line 14:


==What Else==
==What Else==
Okay but what about something a little more off the wall? Well there is an odd little class of encryption algorithms that might work with the tools we have. Specifically, Rachoff-Luby implemented using MD5 (Rachoff-Luby can be thought of as using some special chaining algorithms that let you use hashing algorithms to generate one-time-pads from passp-hrases and an initialization vector). Well, no significant research has happened in this area to see how strong this idea is but lets go with it anyway. Oh darn. Still a no-go. In order to use Xor we need to convert our strings into Base64 encoding. But the MD5 string is encoded in HEX. We could convert the 128 bit HEX into 4 32-bit integers and generate the BASE64 of that except we can only convert a single 32-bit integer, not a list of them. Can't concatenate the 4 BASE64 encoded integers because the 4 bytes of encoded data doesn't divide evenly by 3 which means we have two place holders at the end of the BASE64 string (which we can't get rid of). We would have to implement our own BASE64 subroutine and if we do that, performance goes out the window.
Okay but what about something a little more off the wall? Well there is an odd little class of encryption algorithms that might work with the tools we have. Specifically, Rachoff-Luby implemented using MD5 (Rachoff-Luby can be thought of as using some special chaining algorithms that let you use hashing algorithms to generate one-time-pads from pass-phrases and an initialization vector). Well, no significant research has happened in this area to see how strong this idea is but lets go with it anyway. Oh darn. Still a no-go. In order to use Xor we need to convert our strings into Base64 encoding. But the MD5 string is encoded in HEX. We could convert the 128 bit HEX into 4 32-bit integers and generate the BASE64 of that except we can only convert a single 32-bit integer, not a list of them. Can't concatenate the 4 BASE64 encoded integers because the 4 bytes of encoded data doesn't divide evenly by 3 which means we have two place holders at the end of the BASE64 string (which we can't get rid of). We would have to implement our own BASE64 subroutine and if we do that, performance goes out the window.


==What's left==
==What's left==
So, what do we do? We have script hacking to steal Lindens from people. We have no way to make prim-to-prim communications secure. What do we do? I don't suppose Linden Lab have time to implement something like "string LlAES(string key-in-hex, string data)" do they?
So, what do we do? We have script hacking to steal Lindens from people. We have no way to make prim-to-prim communications secure. What do we do? I don't suppose Linden Lab have time to implement something like "string LlAES(string key-in-hex, string data)" do they?

Latest revision as of 13:13, 20 June 2007

When, if ever, are we going to get anything remotely resembling tools to be able to implement some sort of real encryption? We have a small hand full of tools: ModPow, MD5, and a really twisted combination of Xor and Base64. But none of them are actually enough.

ModPow

This strange little combination of powers and modular arithmetic exists for the sole purpose of implementing RSA type public-key encryption. The only problem is that they have limited the encryption key size to 16 bit. The minimum size for RSA encryption keys with current technology is 1024 bits. So essentially, we should be able to crack a 16 bit implementation very quickly (think seconds of CPU time, if that).

MD5

MD5 is a hashing algorithm, not an encryption algorithm. Hashes serve two purposes in encryption. One is for message signing (to show the message was not altered in transit) and the other is to convert a pass-phrase (or password) into a usable symmetric-key. Useful but only if we have some sort of encryption algorithm.

Xor

Okay our last chance, Xor. Hey, we can implement one-time-pads with this. Here is a chance at actual encryption. Okay so we need to generate a random string that is the same size as the message. We can only use the random string once. Hmm have to communicate the string securely to our destination. Oh darn. how are we going to do that without real encryption? Darn.

xTEA

Hey wait a minute, what do you mean we don't have real encryption. TEA (Tiny Encryption Algorithm) is real encryption. Yes it is. But the GPLed xTEA implemented in LSL took 8 seconds to run on a sample 128 character message I tested on an empty SIM and 15 seconds for a 256 character message. It just isn't fast enough and I doubt it would be fast enough even with code optimization.

What Else

Okay but what about something a little more off the wall? Well there is an odd little class of encryption algorithms that might work with the tools we have. Specifically, Rachoff-Luby implemented using MD5 (Rachoff-Luby can be thought of as using some special chaining algorithms that let you use hashing algorithms to generate one-time-pads from pass-phrases and an initialization vector). Well, no significant research has happened in this area to see how strong this idea is but lets go with it anyway. Oh darn. Still a no-go. In order to use Xor we need to convert our strings into Base64 encoding. But the MD5 string is encoded in HEX. We could convert the 128 bit HEX into 4 32-bit integers and generate the BASE64 of that except we can only convert a single 32-bit integer, not a list of them. Can't concatenate the 4 BASE64 encoded integers because the 4 bytes of encoded data doesn't divide evenly by 3 which means we have two place holders at the end of the BASE64 string (which we can't get rid of). We would have to implement our own BASE64 subroutine and if we do that, performance goes out the window.

What's left

So, what do we do? We have script hacking to steal Lindens from people. We have no way to make prim-to-prim communications secure. What do we do? I don't suppose Linden Lab have time to implement something like "string LlAES(string key-in-hex, string data)" do they?