Pseudo-Random Text Encryption & Decryption with Cipher

This is a Encryption / Decryption API I made that encrypts and decrypts text. It works fine without a cipher but it is highly recommended to use a cipher. It is theoretically impossible to decrypt an encrypted message without knowing its cipher.

How to Get It:
- Using Computercraft

pastebin get AP6eqKNm crypt

- Manually
Download file from: pastebin.com/AP6eqKNm
Copy into a computer in the world's save folder

How to Use It (Example):

os.loadAPI("crypt")

message = "test"
encrypted = crypt.encrypt(message)
encryptedWithCipher = crypt.encrypt(message, "cipher10274")

print("Original Message: " .. message .. "n")

print("Encrypted: " .. encrypted)
print("Encrypted With Cipher: " .. encryptedWithCipher  .. "n")

print("Decrypted: " .. crypt.decrypt(encrypted))
print("Decrypted With Cipher: " .. crypt.decrypt(encryptedWithCipher, "cipher10274"))

Result:


For those who do not beleive this

Note: The cipher can either be an integer or a string, if anything else is used, it will not use a cipher.

This is what the function of the encryption algorithm looks like graphically (without a chipher), where "x" is the position of the character in a string, and where "y" is the offset value;


For those who do not believe that this encryption is secure, I have encrypted a message for those who think they can crack it; pastebin.com/AR2fTaAw

time to make some brute force tables :)/>/>
verry, VERRY easy to generate

EDIT:
checksums arent included in the encrypted string, that prevents the password from being authenticated D:
that makes it harder for me to crack as there will be many false positives

EDIT2:
your offset algorithm dosent do much at all, i can just make a brute force table for that too :D/>/>

PixelToast, on 05 November 2012 - 01:33 PM said:

time to make some brute force tables :D/>/>
verry, VERRY easy to generate

Yes, it is possible to brute force this encryption, but you can't really brute force an encrypted message without knowing the original message. Also, Why would it help to know the cipher if you already know the contents :)/>/>

You can bruteforce and get X results, and then scanning for something meaningful is relatively simple.

Nice try, but I really wouldn't use this for anything important :P/>/>

robhol, on 05 November 2012 - 08:56 PM said:

You can bruteforce and get X results, and then scanning for something meaningful is relatively simple.

Nice try, but I really wouldn't use this for anything important :P/>/>

Ok, if you believe you can decrypt it here is a link to an encrypted message; pastebin.com/AR2fTaAw.

Not a cryptanalyst - I'm just saying that home-grown encryption algorithms are generally a bad idea. No need to get butthurt.

robhol, on 06 November 2012 - 09:58 AM said:

Not a cryptanalyst - I'm just saying that home-grown encryption algorithms are generally a bad idea. No need to get butthurt.

I am not butthurt, I just wanted to see if someone was able to decrypt it so I would know what to improve on.

This is interesting.

MetaDark, on 05 November 2012 - 01:31 PM said:

It is theoretically impossible to decrypt an encrypted message without knowing its cipher.

Not really. Perfectly secret encryption is possible if and only if the key is at least as long as the message. Integers are 32 or 64 bits, so a message of more than 4-8 characters is going to be longer. DES can be cracked in a few days on consumer hardware, and if the integers are 32-bit (depends on lua and the platform), that's a smaller key by many orders of magnitude. You don't actually have to know the plaintext to do a brute force, you just have to know enough. In a typical message typed by a human, you're generally only going to have bytes from 0x20-0x7f.

One-time pads are unbreakable when properly used, because their message length is limited to that of the key (which is very long). However, one-time pads can't be used twice without compromising that security, hence the name. If you have two messages sent with the same pad, you can find out what relationship there is between the two messages, which is called a known-plaintext attack.

Your cipher has a similar problem. Encrypt two similar messages with the same key, e.g. "attack enemy base 1 at dawn" and "attack enemy base 2 at noon". Then for each pair of bytes in the two ciphertexts, subtract one byte from the other and mod 256. In this case, {a bunch of zeros… 0, 255, 0, 0, 0, 0, 246, 241, 8, 0}. You'll get a difference map that you could use to convert one of the messages into the other. This is basically the same vulnerability as one time pads. You could deal with this by transmitting a random integer salt with the message. Add or subtract (or whatever) the salt and the key before doing the encryption and decryption.

When I was fiddling around, I also noted some periodicity. I was using a python implementation, so it may not be exactly the same, but I'd be surprised if the problem went away entirely in lua. When decrypting a given ciphertext using a bunch of keys, I noticed that keys that were 36210 apart gave similar results, with a couple of bytes off by one. To demonstrate this, use a similar technique as above, but encrypt the same message with a key and then that key + n * 36210, where n is an integer. For n = ±1, you should get mostly zeros but with some 255's and 1's in there. The further away you get, the more different the messages become. For n = 10, I got mostly 1-3 deltas, and for n = 100, mostly in the range 0-20, but one as high as 60. One might be able to use this to get an approximate decryption and then go up and down in steps of 36210 to find the correct key. Picking a random integer from the full 32 or 64 bit range as your key would probably make this attack impractical. In light of this, I would strongly advise against using string keys, since they have a fairly small range unless the string is very long.

And one more oddity: an encrypted message should look like random data, but yours doesn't—0xa5 occurred 47 times, 0xe0 14, 0x81 12, 0x39 10, 0x41 9, and the other 93 unique bytes 7 or fewer times, 71 of those only once. And 93 is also strange, since out of 267 bytes, you only hit 98 unique bytes. This can't really be used for simple frequency analysis because of how your algorithm works, but it may reflect a cryptographic weakness. Compare 98 to how many unique bytes you have in your original message, and see if there's any similarity in the distribution.

Is it secure? Probably not. Is it secure enough for Minecraft? It may well be.

MetaDark, on 06 November 2012 - 09:47 AM said:

robhol, on 05 November 2012 - 08:56 PM said:

You can bruteforce and get X results, and then scanning for something meaningful is relatively simple.

Nice try, but I really wouldn't use this for anything important :P/>/>

Ok, if you believe you can decrypt it here is a link to an encrypted message; pastebin.com/AR2fTaAw.

can you please post a hex version?
my phone hates copying it

PixelToast, on 14 November 2012 - 03:28 PM said:

can you please post a hex version?
my phone hates copying it

Here is hex and b64: http://pastebin.com/kMfb2x59

im not a pro cryptographer but i am a pro coder :s
ill see what i can do

can you give me a hint on the password?

first step: optimize the crap out of your existing code
second: brute force c:
third: sort all the values that contain the most recognized characters