This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Exerro's profile picture

Encryption

Started by Exerro, 13 August 2015 - 11:24 AM
Exerro #1
Posted 13 August 2015 - 01:24 PM
After failing to get the other encryption APIs on the forums to work (probably me being stupid), I wrote my own. While I agree it's generally a bad idea to make your own encryption algorithms, I figured all the secure encryption algorithms out there didn't start by someone going "let someone else do it, they're better at it", so gave it a go.

Install: pastebin get BQZfkgFk encryption

By using dofile() to load this, you get the table with the functions encrypt() and decrypt() inside. The usages are as follows:



local encryption = dofile( "path_to_API" )

E​​ncryption.encrypt()
 string cipher = encryption.encrypt( any_serializable_value value, string/number key ) 
- encrypts the value given with the key given
- by serializable, this means something that can be serialized using textutils.serialize() (no functions or coroutines, even in nested tables)

Encryption.decrypt()
 any_serializable_value value = encryption.decrypt( string cipher, string/number key ) 
- decrypts the cipher given with the key given
- if the key is equal to the key which encrypted the value initially, what this returns will be equal to the thing passed to encrypt()

In an effort to make the cipher transmittable over modems and able to be put on pastebin, the cipher will be a string of hexadecimal characters [A-F, 0-9]. In addition, to add security to the cipher, random sections of garbage characters are added after each 'block' (5 character section). This means the cipher is significantly longer than the value put in (2.4x average iirc).

This is meant to be quick: 890KB/s on my computer. The reason I wrote my own key generator rather than using math.random is because math.random is very slow, and takes its performance down hugely. There's still some optimisation to do, such as localising some of the math functions, but I want to see if it's secure enough to use first.

I'd really appreciate it if people find issues with this (security issues/bugs). It seems there are some crypto-know-it-all people on the forums so it would be great to have some feedback on this.
SquidDev #2
Posted 13 August 2015 - 03:23 PM
I'm no cipher expert but here are some initial thoughts:

Garbage is trivial to deal with. Garbage of varying lengths makes it even harder. However you are seeding the random number generator every time you generate it: math.randomseed(os.clock()). If you are operating at 890Kb/s then that should produce the same garbage characters every time - I haven't checked this though. As we know the block lengths, we could probably spot a pattern quite quickly, and remove the garbage.

The other thing I noticed is that each block is encrypted with the same key. I guess this isn't too much of an issue as the block lengths are only 5 letters long and are non-sequential letters.

Looks like I have several encryption methods I need to try to break now :)/>/>/>. That would kinda be a fun forum game - people write encryption algorithms and post the code and ciphertext, then the next person has to break it. Maybe I just have an odd sense of fun :)/>/>/>.

Edit:
Another bug I found: Gabage doesn't work.

garbage[i] = f(seed) and 0 -- This will always be 0 as (true and 0) evaluates to 0.
Therefore, the length of garbage is always 0.

To prove my thing about os.clock, here is my code with the above point fixed.
[0000001C]CFC2CBCBC8D7D7756D706E66.776B6A706AD7D7D7D7F5E7F4E7E8D7D7D7D7D7616A68716D.B7B0B9D7D7D7D7D7
Edited on 13 August 2015 - 01:38 PM
Exerro #3
Posted 13 August 2015 - 05:33 PM
I think the 'and 0' was a debugging thing. Thanks for pointing that out. Also, yeah, that garbage generator is pretty derped, I'm amazed I did that. I moved it into encrypt() now so it should function a lot better.

Thanks for the response.