Jump to content




Encryption help


  • You cannot reply to this topic
14 replies to this topic

#1 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 28 November 2014 - 11:36 PM

Hello people of the interwebs! I could use some help finding a good encryption API to use. I've already tried SquidDev's AES encryption, but it wasn't very useful, due to the fact that it doesn't yield. So when I tried it on a large file, it crashed the computer. So I could really use your guy's help finding a computercraft encryption API (Not hashing. I need to be able to read it back later) that periodically yields.

Thanks in advance!

Edited by Jiloacom, 28 November 2014 - 11:37 PM.


#2 Exerro

  • Members
  • 801 posts

Posted 29 November 2014 - 12:03 AM

Well, RC4 is one that comes to mind. First link on google after searching "RC4 lua" was this. Next one I found was this which was actually written for computercraft.

Other than that, I wrote my own a while back, which Nova uses. It's pretty secure I believe, but I've never actually tried to break it. If you'd like to use it, just ask and i'll put it on pastebin and send the link.

(my one yields automatically, but for the others, you'll probably have to add that in)

Edited by awsumben13, 29 November 2014 - 12:07 AM.


#3 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 November 2014 - 12:36 AM

View Postawsumben13, on 29 November 2014 - 12:03 AM, said:

Well, RC4 is one that comes to mind. First link on google after searching "RC4 lua" was this. Next one I found was this which was actually written for computercraft.

Other than that, I wrote my own a while back, which Nova uses. It's pretty secure I believe, but I've never actually tried to break it. If you'd like to use it, just ask and i'll put it on pastebin and send the link.

(my one yields automatically, but for the others, you'll probably have to add that in)

I tried to add it in on AES encryption, but failed horribly. So I'd prefer if it was already added in by the creator.

#4 Exerro

  • Members
  • 801 posts

Posted 29 November 2014 - 12:56 AM

Spoiler

This mine. Not the fastest or most secure I'm sure, but it does yield so it won't TLWY and I can't see any major floors with it. It took about 5 seconds to encrypt a 1KB file I think, although I can remember being impressed, so it might be a bit better than this. The cipher will always be double the length of the text, which is probably a security floor or something, I'm not entirely sure. You'll have to ask an expert.

For you experts...
It is an xor cipher, that shifts the key a random amount before xoring each character of the text with a corresponding character from the key (no the key doesn't have to be the same length, it loops back round). I think this is quite secure, but I really don't know. I'd love to see someone try to hack it though and put it to the test.

Edit: it takes about .1 seconds to encrypt 1KB actually.

Edited by awsumben13, 29 November 2014 - 05:08 PM.


#5 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 November 2014 - 01:23 AM

View Postawsumben13, on 29 November 2014 - 12:56 AM, said:

Spoiler

This mine. Not the fastest or most secure I'm sure, but it does yield so it won't TLWY and I can't see any major floors with it. It took about 5 seconds to encrypt a 1KB file I think, although I can remember being impressed, so it might be a bit better than this. The cipher will always be double the length of the text, which is probably a security floor or something, I'm not entirely sure. You'll have to ask an expert.

For you experts...
It is an xor cipher, that shifts the key a random amount before xoring each character of the text with a corresponding character from the key (no the key doesn't have to be the same length, it loops back round). I think this is quite secure, but I really don't know. I'd love to see someone try to hack it though and put it to the test.

I'll try it. ;)
Using the functions, not trying to break it.

Edited by Jiloacom, 29 November 2014 - 01:23 AM.


#6 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 November 2014 - 01:33 AM

str = str .. n % 2

Got attempt to perform arithmetic __mod on nil and number when I tried to decrypt (Sorry, I said encrypt the first time) the Quest (by oeed).

EDIT: I also get it when I just try to decrypt the word "Test" with key "Test"

EDIT EDIT: Okay, the only reason the above 2 situations didn't work, was because apparently your system doesn't like it when I try to decrypt programs that you haven't already encrypted using said system.

Edited by Jiloacom, 29 November 2014 - 01:46 AM.


#7 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 November 2014 - 02:16 AM

Okay, still on the look out for encryption algorithms. Sorry, awsumben, but your encryption algorithm is just too slow.

#8 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 29 November 2014 - 11:21 AM

Just out of interest, how large files are you using? RainbowDashDC re-wrote the bit library so it should be quicker now. Adding yield support is on my todo list.

#9 Exerro

  • Members
  • 801 posts

Posted 29 November 2014 - 11:32 AM

You can change the yield time to speed it up. Right now, it yields every .1 seconds (so in Nova the UI can still function) but if you dont need that put it up to 2 or something.

#10 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 November 2014 - 02:38 PM

View PostSquidDev, on 29 November 2014 - 11:21 AM, said:

Just out of interest, how large files are you using? RainbowDashDC re-wrote the bit library so it should be quicker now. Adding yield support is on my todo list.

well... Depends on how large the user's system is.. :P

Maybe 1 to 30 KB? As long as the user doesn't have a huge OS installed (Cough ONEOS Cough), there shouldn't be too much data on it.

And in case the moderators are wondering, NO, this has NO malicious intent. And in fact, is a program trying to prevent malicious intent.

#11 jaredallard

  • Members
  • 124 posts
  • LocationSeattle, WA

Posted 29 November 2014 - 04:53 PM

View PostJiloacom, on 29 November 2014 - 02:38 PM, said:

View PostSquidDev, on 29 November 2014 - 11:21 AM, said:

Just out of interest, how large files are you using? RainbowDashDC re-wrote the bit library so it should be quicker now. Adding yield support is on my todo list.

well... Depends on how large the user's system is.. :P

Maybe 1 to 30 KB? As long as the user doesn't have a huge OS installed (Cough ONEOS Cough), there shouldn't be too much data on it.

And in case the moderators are wondering, NO, this has NO malicious intent. And in fact, is a program trying to prevent malicious intent.

aeslua as of right now can do 15 kb in around 3 seconds, which is below the yielding requirements. So, I'd say around 20 kb is the max for now until yielding is properly implemented

#12 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 29 November 2014 - 05:54 PM

I've pushed a pre-release with yielding enabled. This massively drops the performance (6 to 5 kb/s) on my computer. I can handle 50kb now.

#13 jaredallard

  • Members
  • 124 posts
  • LocationSeattle, WA

Posted 29 November 2014 - 07:04 PM

View PostSquidDev, on 29 November 2014 - 05:54 PM, said:

I've pushed a pre-release with yielding enabled. This massively drops the performance (6 to 5 kb/s) on my computer. I can handle 50kb now.

Still better than before, prehaps it can be slighly enhanced.

#14 Anavrins

  • Members
  • 775 posts

Posted 29 November 2014 - 11:12 PM

View Postawsumben13, on 29 November 2014 - 12:56 AM, said:

Spoiler

This mine. Not the fastest or most secure I'm sure, but it does yield so it won't TLWY and I can't see any major floors with it. It took about 5 seconds to encrypt a 1KB file I think, although I can remember being impressed, so it might be a bit better than this. The cipher will always be double the length of the text, which is probably a security floor or something, I'm not entirely sure. You'll have to ask an expert.

For you experts...
It is an xor cipher, that shifts the key a random amount before xoring each character of the text with a corresponding character from the key (no the key doesn't have to be the same length, it loops back round). I think this is quite secure, but I really don't know. I'd love to see someone try to hack it though and put it to the test.

Edit: it takes about .1 seconds to encrypt 1KB actually.
That is effectively the same thing as the Vigenere Cipher, and is weak, see https://www.youtube....h?v=P4z3jAOzT9I

Edited by Anavrins, 29 November 2014 - 11:18 PM.


#15 AgentE382

  • Members
  • 119 posts

Posted 06 December 2014 - 05:39 AM

View Postawsumben13, on 29 November 2014 - 12:03 AM, said:

Well, RC4 is one that comes to mind. First link on google after searching "RC4 lua" was this. Next one I found was this which was actually written for computercraft.
<snip>

View PostJiloacom, on 29 November 2014 - 02:38 PM, said:

View PostSquidDev, on 29 November 2014 - 11:21 AM, said:

Just out of interest, how large files are you using? RainbowDashDC re-wrote the bit library so it should be quicker now. Adding yield support is on my todo list.

well... Depends on how large the user's system is.. :P

Maybe 1 to 30 KB?
<snip>

I wrote the ComputerCraft RC4 implementation awsumben13 mentioned, and it's extremely optimized for Lua and CC. On my PC, it encrypts about 100KB/s. If you really need to encrypt more than 400KB (too long without yielding), you can encrypt the data in chunks. Since RC4 is a symmetric stream cipher, and my functions save state, you literally just break it into chunks, call the encryption function on each chunk in order, and combine the chunks. It will produce exactly the same ciphertext as if you had fed it all as one chunk.

Edited by AgentE382, 06 December 2014 - 05:40 AM.






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users