TwoCrypt - Simple but very fast en-/decryption for strings

This is a very simple en-/decryption algorithm that is tailored to the specific restrictions of the ComputerCraft Lua language. It works with strings and is extremely fast.

Is this totally secure?
No. Anyone with good knowledge of cryptographic algorithms and some time on their hands can eventually crack the messages. But this is not designed to encrypt your bank account or super-important passwords, it is just a tool to prevent others from simply controlling your turtles or reading your messages, without forcing your turtles to spend most of their time on security. If it takes a few hours and good knowledge of cryptography to crack the encryption, most people would probably just don't even start. That's what TwoCrypt is made for.

Installation:

As always via pastebin then install as library:

pastebin get bxgAK8DY twocrypt
os.loadAPI("twocrypt")

Usage:

To decode or encode a message simply call crypt with your key and the message to encrypt. Example:

encodedMessage = twocrypt.crypt("secretKey", "My secret message")

If you run the code above, you will get a string with seemingly random bytes. If you run crypt again with the same key but the encoded message, you will get the original message back. Example:

decodedMessage = twocrypt.crypt("secretKey", encodedMessage)

Speed:

As Lua does not (yet) have fast bit-wise operations, most encryption algorithms are going to be super-slow. TwoCrypt however only uses one bit-operation per round, which reduces the time to en-/decrypt significantly.

I tested the speed on my machine and en-/decrypting a single message took about 0.08 milliseconds. This should have basically no impact on the execution speed of your code.

Security:

TwoCrypt has three possible security breaches:

• Your key is hashed to a 32-bit number, so anyone with a reasonably fast computer (read: not turtles) can just try every possible combination in a few minutes (depending on the hardware). They however only get the hashed number, not your original password/key. Getting that one is much more difficult.
• The stream cipher initialization problem: anyone who can read a few messages can XOR two encrypted messages and get the random numbers used to encrypt the message. I have a small initialization vector, but that only means that someone need to get about 16 messages before he can decode the next one with a pretty good chance (and some computation).
• The random number generator used is not random. Sophisticated decryption programs can crack this in probably a few minutes to receive the original message.

I welcome any suggestions, bug reports or ideas for improvement.

That's a neat programs for basic encryption, however…

Two, on 27 August 2014 - 09:39 PM said:

I have a small initialization vector, but that only means that someone need to get about 16 messages before he can decode the next one with a pretty good chance (and some computation).

You do not even have an IV.
"for i=0,len%16 do math.random() end – initialization vector" does literally nothing.
So this is even weaker than you think :P/>

It does. Computers can't really make random numbers, so they fake it with some kind of algorithm, typically using the previous generated number as an input. Calling math.random a few times runs the algorithm so the number is "extra" random.

flaghacker, on 13 September 2014 - 06:35 AM said:

It does. Computers can't really make random numbers, so they fake it with some kind of algorithm, typically using the previous generated number as an input. Calling math.random a few times runs the algorithm so the number is "extra" random.

This is not what an IV does.
Yes it will advance the pseudo-RNG 16 step forwards, 16 small little steps that will not affect a bruteforce in the slightest.
Calling math.random a few time won't make a predictable sequence more unpredictable.