Easy Encryption API [Broken]

The used encryption algorithm has been cracked by immibis! It's insecure and could also be buggy. I would not recommend to use it in your Programms.


Hey guys,

i got bored, so i've written my own encryption API called "Multiple Encryption 1". It's very simple to use:

encrypt(string, password) — Encrypts a string. Returns false if password < 3.

decrypt(string, password) — Decrypts a string. Returns false if password < 3 or sometimes when the password is incorrect. But mostly it just returns rubbish.

The encryption is very secure, because every letter of the password needs to be correct. Example:

Encrypted string: "xgyQz[1]3e"

Decrypted with correct password (abcd123): "Hey guys!!"
Decrypted with wrong password (abcd124): "Fcw}eswq~~"

You can download it here or watch it at Pastebin (DdH8naJ7).

Have fun!

This is just what I was looking for!
Do you think it would be possible for you to add comments to explain how it works for people who are new to lua? (Like myself)
Thanks. :)/>

Draktharis, on 28 February 2013 - 03:23 AM said:

add comments to explain how it works

Wouldn't be a very secure encryption system then would it :P/>

If you really want a good introduction to Lua read this or apply to the ComputerCraft University (CCU)

Adding comments would be hard, because I played around with encrypting until it was safe. So i try to describe what the API does.

Every letter has a Byte. ComputerCraft uses the ASCII-Table. For example the P is byte 80. The difference between Computercraft and real Computers is, that CC-PCs can't handle letters which aren't printable. (like byte 27, which is the ESC-Key) It just replaces them with a ? which is byte 63. If I add the bytevalue of the key to the bytevalue of the letter, I must look that the result stays between 32 and 126. So I played around with the bytes to keep them between 32 &amp; 126.

The "enc"-Function takes the key, converts it into bytes, subtracts 31 from it and puts every byte into an Array.
Then every Letter of the String gets converted to bytes. These are added to one byte of the key. If the last letter of the key was used, it begins again with the first letter. If the result is bigger than 126 it gets substracted by 126 and then added by 31. So it stays in the range of the printable letters. The result gets returned to the "encrypt"-Function.

The "encrypt"-Function just messes around with the key and the string to make the encryption safe. Before i did this, the encrypted String was a bit readable even with a key with one wrong letter. I'm to lazy to explain it more accurate.

The "decrypt" and the "dec"-Function is basically the same than the encryption, but backwards.

Wow, just written so much… Sorry if i have written crap, english is not my native language. Hope I helped you.

@TheOriginalBIT – Explaining the encryption doesn't make it less save. You need to bruteforce the string with every possible password. And even then you need an algorithm or a person which observs the bruteforce to distinguish an successfully decrypted string from crap, because the decryption doesn't tell you an error, it just returns something what could be right (or wrong).

Awesome, thanks man. :)/>

TheOriginalBIT, on 28 February 2013 - 03:25 AM said:

Draktharis, on 28 February 2013 - 03:23 AM said:

add comments to explain how it works

Wouldn't be a very secure encryption system then would it :P/>

Actually the definition of an encryption protocol is that you CAN know every detail about how it works and that will not affect the encryption strength at all. This is even known as Rule #2 of Encryption.
Any protocol that works by hiding how it functions is by definition not "encryption" but just security through obscurity.

Only the encryption key should make any difference as to the cyphers strength.
If that is not the case, either the protocol is not encryption in the first place, or some mistake was made in the code causing an unintended side effect.

Not to mention security isn't binary, but a scale between "secure" on one side and "convenient" on the other.
The protocols strength mainly only depends how long it takes to brute force a cypher back into plain text. This gives you a value of time.
If that value is longer than you need the data to be protected for, then the strength is good enough.

For preventing real-time interception of rednet communications, this is definitely good enough.
To prevent someone from recording the encrypted communications and brute forcing it offline, perhaps it is and perhaps not, depending on the communications. Even assuming a "weak" strength of one month to brute force, then if you rotate your password/key every two weeks then it is certainly good enough.

Of course without trying and measuring how long it would take, that last one is harder to estimate. But at the very least it should show that the situation of setting a key once and never changing it again would never be a valid situation.

When are people going to learn that homegrown "encryption" algorithms are a terrible idea? :P/>

What's your stance on me including this in my Security card API? I will give you credit for making it relatively secure :)/>

Wait, if they look at the code won't they just see the encryption function and the password and decode it?

Malte, on 28 February 2013 - 07:50 AM said:

I must look that the result stays between 32 and 126.

When I was creating an encryption program I did that too at first, but after some weird errors every now and again I took a closer look and noticed that the range of printable character is actually split in two.
Byte 96 is not printable, ergo the ranges are [32-95] and [97-126].

Edit:
Btw. with "When I was creating an encryption program" I didn't mean creating my own encryption algorithm, but just implementing an already proven, secure one.^^

thanks man, i am gonne use it in my program, its a cloud service on a server.

if you dont like it, just say it and i wil search for another api,
and of course i wil credit you in my program.

thanks
-oedze

btw, whats the difference between encrypt() and enc()??????

Really, you're going to use an encryption algorithm I made an automated cracker for?

i had some trouble with this api. It didnt work at first, and it said attempt to index number. I realized that you can't use local in your code for other programs to use his functions. I removed all the local of the variables and it worked. I know that this is outdated but its the best to everyone know.

Rodmastercraft, on 29 March 2014 - 09:07 PM said:

i had some trouble with this api. It didnt work at first, and it said attempt to index number. I realized that you can't use local in your code for other programs to use his functions. I removed all the local of the variables and it worked. I know that this is outdated but its the best to everyone know.

the two important functions are not localised, you're wanting to use function encrypt(str, key) and function decrypt(str, key) which aren't, there is no need to unlocalise the other functions. however this being said

Malte, on 27 February 2013 - 09:07 AM said:

The used encryption algorithm has been cracked by immibis! It's insecure and could also be buggy. I would not recommend to use it in your Programms.

theoriginalbit, on 29 March 2014 - 11:30 PM said:

Rodmastercraft, on 29 March 2014 - 09:07 PM said:

i had some trouble with this api. It didnt work at first, and it said attempt to index number. I realized that you can't use local in your code for other programs to use his functions. I removed all the local of the variables and it worked. I know that this is outdated but its the best to everyone know.

the two important functions are not localised, you're wanting to use function encrypt(str, key) and function decrypt(str, key) which aren't, there is no need to unlocalise the other functions. however this being said

Malte, on 27 February 2013 - 09:07 AM said:

The used encryption algorithm has been cracked by immibis! It's insecure and could also be buggy. I would not recommend to use it in your Programms.

Sure. I do realize that the program is buggy and cracked. Thanks for the reply anyways.