RC4 Encryption API
NeverCast 13 Jan 2013
Hello CC Forums,
Just bringing you another API, it's the RC4 encryption algorithm re implemented for ComputerCraft, RC4 is a fast stream algorithm and is used in protocols like SSL and WEP.
Download Link: http://pastebin.com/rDUe5wGe
Each time you encrypt something, the internal state changes, so you have to decrypt the same amount of data as you encrypt for the sessions to stay in sync, Meaning that if you encrypt two messages, you need to decrypt both messages otherwise the decryption stream wont have the same key state as the encryption.
I'm not very good with documentation. So please just leave any comments here and I'll help the best I can. Thanks
Just bringing you another API, it's the RC4 encryption algorithm re implemented for ComputerCraft, RC4 is a fast stream algorithm and is used in protocols like SSL and WEP.
Download Link: http://pastebin.com/rDUe5wGe
Spoiler
Each time you encrypt something, the internal state changes, so you have to decrypt the same amount of data as you encrypt for the sessions to stay in sync, Meaning that if you encrypt two messages, you need to decrypt both messages otherwise the decryption stream wont have the same key state as the encryption.
I'm not very good with documentation. So please just leave any comments here and I'll help the best I can. Thanks
crazyguymgd 13 Jan 2013
Sounds cool. I'll probably never use it but I always like seeing people do things like this
NeverCast 14 Jan 2013
Thanks
The API's I typically post don't seem to get a lot of attention as they're normally technical and only have cliche use. But this would be good for anyone making an OS or some networking software. It'd be good to see some real encryption being used by some of the CC devs.
The API's I typically post don't seem to get a lot of attention as they're normally technical and only have cliche use. But this would be good for anyone making an OS or some networking software. It'd be good to see some real encryption being used by some of the CC devs.
NeverCast 16 Jan 2013
theoriginalbit 18 Feb 2013
Oh noes, I'm grave digging
How did I not see this earlier! Gotta love search
Just posting to say, 'tis awesome and needs to be used by people a lot more, and I'm gunna use it in my messenger program
How did I not see this earlier! Gotta love search
Just posting to say, 'tis awesome and needs to be used by people a lot more, and I'm gunna use it in my messenger program
GravityScore 18 Feb 2013
YES! I wanted an RSA or RC algorithm to use to encrypt Rednet messages!
Mind if I use this to encrypt sent messages in Firewolf?
Mind if I use this to encrypt sent messages in Firewolf?
theoriginalbit 18 Feb 2013
Jan 22 Feb 2013
AFAIK, rednet doesn't support characters higher than 127 very well.
Would this still work if I replaced all '256' for '128' ?
Would this still work if I replaced all '256' for '128' ?
NeverCast 24 Feb 2013
Yes that would work. I assume you're meaning with RedPower cables. Which are being retired from CC.
NeverCast 24 Feb 2013
ElvishJerricco 27 Feb 2013
I'll be honest Nevercast, your content is some of my favorite on the forums.
UselessFlaw 31 Jul 2013
I just came across this and, I'm impressed. I hope you don't mind if I use this to add some encryption to my accounts API (credit to you of course)
Edit: oops I revived something
Edit: oops I revived something
PixelToast 31 Jul 2013
verry nice, you can increase the efficiency of the encryption and key generation alot though
PixelToast 01 Aug 2013
just realized, this lacks public / private asymmetric key generation, atm its just symmetric encryption though i dont see a good way to generate large primes :/
might be vulnerable to plaintext attacks, but its more secure than what ive got
sorry for doublepost, wanted to bump
might be vulnerable to plaintext attacks, but its more secure than what ive got
sorry for doublepost, wanted to bump
AgentE382 09 Aug 2013
RC4 is a symmetric stream cipher. The key generation / exchange is up to you.
Do yourself a favor and discard the first 256-4096 bytes. Information about the key can be derived from the first bytes of the keystream.
Also, if you use a salt in your key-exchange, XOR it with the key or hash them concatenated to get the final key. Don't concatenate them and directly use that as the cipher's input.
Or you could wait until tomorrow afternoon when I add a more secure RC4 variant to my version.
Do yourself a favor and discard the first 256-4096 bytes. Information about the key can be derived from the first bytes of the keystream.
Also, if you use a salt in your key-exchange, XOR it with the key or hash them concatenated to get the final key. Don't concatenate them and directly use that as the cipher's input.
Or you could wait until tomorrow afternoon when I add a more secure RC4 variant to my version.