Inbuilt Encryption

It would be great to have an inbuilt way of encrypting data, with most of the widespread forms: sha1, md5 and some of the sha-2 ones.

Would be great if we could encrypt no matter what, so we could to this:

local table={}
table[0]="Encrypt me!"
local encryped=textutils.encrypt(table,"sha-512") --Returns a table

Would also go very well with the new improved serialization coming in 1.6.

Encryption is so utterly meaningless in cc, and there's already APIs for encryptions. Personally i think it's better this way cause it forces people to learn about encryption if they wish to use it. Well unless they use the API that is…

CometWolf, on 27 January 2014 - 12:35 PM said:

Encryption is so utterly meaningless in cc, and there's already APIs for encryptions. Personally i think it's better this way cause it forces people to learn about encryption if they wish to use it. Well unless they use the API that is…

I agree completely. People are always going on about how you need to encrypt passwords in your app. But, one, I can open your program and get the decrypting line of code. And two, why do you need a password for anything anyway?

oeed, on 27 January 2014 - 04:01 PM said:

I can open your program and get the decrypting line of code.

Although I agree that adding encryption to CC on its own isn't a great idea, and encryption in general isn't a necessary for CC usages, what you said there is generally incorrect. Passwords are encrypted via hashing so you can check against the hash for correct passwords, but you cannot decrypt that password.

Encryption is not the same as hashing:
Encryption: http://en.m.wikipedia.org/wiki/Encryption
Hashing: http://en.m.wikipedia.org/wiki/Cryptographic_hash_function

Anyway, I think that CC is more intended to control your world, rather than locking doors :P/> However, it is implementable by yourself, and there are API's out there.

ElvishJerricco, on 27 January 2014 - 05:02 PM said:

oeed, on 27 January 2014 - 04:01 PM said:

I can open your program and get the decrypting line of code.

Although I agree that adding encryption to CC on its own isn't a great idea, and encryption in general isn't a necessary for CC usages, what you said there is generally incorrect. Passwords are encrypted via hashing so you can check against the hash for correct passwords, but you cannot decrypt that password.

Yes, I am aware that they're different things. If hashing were used it'd be just as easy to get around it. Just edit the program.

oeed, on 27 January 2014 - 05:37 PM said:

ElvishJerricco, on 27 January 2014 - 05:02 PM said:

oeed, on 27 January 2014 - 04:01 PM said:

I can open your program and get the decrypting line of code.

Although I agree that adding encryption to CC on its own isn't a great idea, and encryption in general isn't a necessary for CC usages, what you said there is generally incorrect. Passwords are encrypted via hashing so you can check against the hash for correct passwords, but you cannot decrypt that password.

Yes, I am aware that they're different things. If hashing were used it'd be just as easy to get around it. Just edit the program.

Hashing is a one way deal. Even if you got the hashed password, you wouldn't know the actual password (ignoring rainbow tables).

But if you captured a hash of a password, then would you need to know what the actual password was?

Not necessarily, the program could look like this:

local pass = "heifnsjeoxhriei"
if sha256(read()) == pass then
  --# stuff
end

That way, when you try to do what oeed said, you would only see the hashed password, but not the actual one.

But this is sort of a moot point because if you were able to edit the program, you could just remove the password part of the code entirely :P/>.

Symmetryc, on 27 January 2014 - 08:35 PM said:

But this is sort of a moot point because if you were able to edit the program, you could just remove the password part of the code entirely :P/>.

That's what I was try to say :P/>

You could block out fs.open(<file>, "w") until they enter a password to prevent that :)/>

awsmazinggenius, on 27 January 2014 - 09:35 PM said:

You could block out fs.open(<file>, "w") until they enter a password to prevent that :)/>

Whack down a disk drive and a blank startup folder then reboot.

Security is essentially impossible in CC. Now, if you have a door lock 90% of people won't be able to open it. But those other 10% of people would be able to no matter what security you had (unless there was some block protection mod on the server and you hid the computer.)

But with the advent of the new PDAs I'm quite excited to see what will become of the door locks. Now you'll just need a hidden computer and a PDA. That's security.

Unless of course someone kills you and takes the PDA.

Everybody knows you can't have security without build protection, it's completely obvious. You know what's even easier than "hacking" a door lock? Chopping down the damn door. :P/>

robhol, on 28 January 2014 - 12:43 AM said:

Everybody knows you can't have security without build protection, it's completely obvious. You know what's even easier than "hacking" a door lock? Chopping down the damn door. :P/>

Yes… now I think of it that'd be a lot easier :P/>

I have fun by using wireless rednet to pass signals to a centrally protected computer that then issues the necessary commands to other computers to open/close stuff for me. But then again, all you have to do is intercept the signals, and viola! – You have access to whatever you want. Minecraft is not built for security in game. It is built to have fun with your creations. If you are having problems with people breaking your stuff or constantly trying to hack you, sounds like you need to move to a new server or build your own. Just saying.

The only use I can see for encryption is as a teaching tool for those who use ComputerCraft to learn or teach about computer programming and networking constructs (consider Lyqyd's LyqydNet project). It is a very cool project, and one can learn a lot about networking from it. However, I do not believe Lyqyd's intent was to dominate the world of networking and build a impenetrable firewall or router with it. It is useful, and cool. I could see encryption projects in this same vein. Coolness, not security.

You actually can have security. All you need is insurance against physical tampering, (read: basic block protection that's been around for years) and then you can implement encryption. It's slow (because Lua) and cumbersome (because Lua), but it's certainly possible.

robhol, on 28 January 2014 - 03:17 PM said:

You actually can have security. All you need is insurance against physical tampering, (read: basic block protection that's been around for years) and then you can implement encryption. It's slow (because Lua) and cumbersome (because Lua), but it's certainly possible.

If you have block protection then you don't need encryption. If you want security you need to use a touch monitor with the computer hidden.

That depends on whether or not you wish to use wireless communications. Sure, if you can wire everything up and hide it in your base, then encryption is a non-issue, but the moment you bring wireless modems into it…

Network traffic cross server can certainly be encrypted, but what on earth are you sending on a server that needs to be encrypted? I'd rather stick some wired modems in my base with block protection.

Always an educational exercise though.

Bomb Bloke, on 28 January 2014 - 05:40 PM said:

That depends on whether or not you wish to use wireless communications. Sure, if you can wire everything up and hide it in your base, then encryption is a non-issue, but the moment you bring wireless modems into it…

Hmm, this'd be the one use for it really. But unless you're at nuclear war with someone I can't see it becoming to much of an issue.

oeed, on 28 January 2014 - 03:22 PM said:

If you have block protection then you don't need encryption. If you want security you need to use a touch monitor with the computer hidden.

Wut? Yes you do. It's just that no matter what kind of security you have, it's pointless if people can chop their way through your walls. If you're planning on communicating without eavesdropping or tampering, you WILL need some kind of protection.

robhol, on 29 January 2014 - 02:06 AM said:

oeed, on 28 January 2014 - 03:22 PM said:

If you have block protection then you don't need encryption. If you want security you need to use a touch monitor with the computer hidden.

Wut? Yes you do. It's just that no matter what kind of security you have, it's pointless if people can chop their way through your walls. If you're planning on communicating without eavesdropping or tampering, you WILL need some kind of protection.

If you have block protection then people can't chop through walls.

Bomb Bloke, on 28 January 2014 - 05:40 PM said:

That depends on whether or not you wish to use wireless communications. Sure, if you can wire everything up and hide it in your base, then encryption is a non-issue, but the moment you bring wireless modems into it…

You still don't need encryption to stop people from sending wireless messages in to "hack" your system. You just have to code your programs to where they are smart enough to only receive rednet messages from your computers and no others.

Block protection is really the only form of securing your systems that you need, since it stops the whole drop a disk drive and stick in a floppy with a blank startup trick which is the main thing you should worry about.

Luanub, on 29 January 2014 - 02:41 AM said:

You still don't need encryption to stop people from sending wireless messages in to "hack" your system. You just have to code your programs to where they are smart enough to only receive rednet messages from your computers and no others.

How exactly will you differentiate from "your" computer or someone else computer that is masquerading as "your" computer?
You can't trust sender id cause that is easy to fake. Only way i know for "secure" communication is encryption of message(and that still can be broken when someone knows your algorithm).

Luanub, on 29 January 2014 - 02:41 AM said:

You still don't need encryption to stop people from sending wireless messages in to "hack" your system. You just have to code your programs to where they are smart enough to only receive rednet messages from your computers and no others.

Modems use channels… rednet uses modems… rednet is no longer a secure way to make sure you're sending messages to only specific IDs.

For example take the following code, assume running on an old version of ComputerCraft.

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

rednet.open('left')
print(rednet.receive()) --# does not get the message EHLO

Now lets make one small change, as well as upgrade to a version of ComputerCraft that has the modem api

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

local modem = peripheral.wrap('left')
modem.open(2)
local event, side, sChannel, rChannel, msg = os.pullEvent("modem_message")
print(msg) --# oh look the message EHLO

theoriginalbit, on 29 January 2014 - 04:34 AM said:

Computer ID: 3

local modem = peripheral.wrap('left')
local event, side, sChannel, rChannel, msg = os.pullEvent("modem_message")
print(msg) --# oh look the message EHLO

You forgot to open channel 2 in modem ;p

wojbie, on 29 January 2014 - 04:40 AM said:

You forgot to open channel 2 in modem ;p

Whoops, thanks. I knew I was missing something.

So, I think we can conclude after various examples and discussions that security without block protection is pretty much impossible, and even if it weren't, pointless.

oeed, on 29 January 2014 - 05:05 AM said:

So, I think we can conclude after various examples and discussions that security without block protection is pretty much impossible, and even if it weren't, pointless.

But encryption will still be interesting as a challenge and something fun to work on ;p Not 100% useful but interesting ;p

wojbie, on 29 January 2014 - 05:09 AM said:

oeed, on 29 January 2014 - 05:05 AM said:

So, I think we can conclude after various examples and discussions that security without block protection is pretty much impossible, and even if it weren't, pointless.

But encryption will still be interesting as a challenge and something fun to work on ;p Not 100% useful but interesting ;p

Oh of course, if you want to do it as a challenge go right ahead. It's just in the grand scheme of things it's not going to prevent much. But by all means, have at it.

Spoiler

theoriginalbit, on 29 January 2014 - 04:34 AM said:

Luanub, on 29 January 2014 - 02:41 AM said:

You still don't need encryption to stop people from sending wireless messages in to "hack" your system. You just have to code your programs to where they are smart enough to only receive rednet messages from your computers and no others.

Modems use channels… rednet uses modems… rednet is no longer a secure way to make sure you're sending messages to only specific IDs.

For example take the following code, assume running on an old version of ComputerCraft.

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

rednet.open('left')
print(rednet.receive()) --# does not get the message EHLO

Now lets make one small change, as well as upgrade to a version of ComputerCraft that has the modem api

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

local modem = peripheral.wrap('left')
modem.open(2)
local event, side, sChannel, rChannel, msg = os.pullEvent("modem_message")
print(msg) --# oh look the message EHLO

This even supports my statement even more.

There are 65535 channels, and any one given computer can only open 128 channels at a time. That means in order to be listening to every single channel at any given point in time you would have to have 512 computers on recording the messages.

With a little work you could make finding your ID's(or even catching one of your messages) very unlikely.

Luanub, on 29 January 2014 - 05:21 AM said:

Spoiler

theoriginalbit, on 29 January 2014 - 04:34 AM said:

Luanub, on 29 January 2014 - 02:41 AM said:

You still don't need encryption to stop people from sending wireless messages in to "hack" your system. You just have to code your programs to where they are smart enough to only receive rednet messages from your computers and no others.

Modems use channels… rednet uses modems… rednet is no longer a secure way to make sure you're sending messages to only specific IDs.

For example take the following code, assume running on an old version of ComputerCraft.

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

rednet.open('left')
print(rednet.receive()) --# does not get the message EHLO

Now lets make one small change, as well as upgrade to a version of ComputerCraft that has the modem api

Computer ID: 1

rednet.open('left')
rednet.send(2, 'EHLO')

Computer ID: 2

rednet.open('left')
print(rednet.receive()) --# gets the message EHLO

Computer ID: 3

local modem = peripheral.wrap('left')
modem.open(2)
local event, side, sChannel, rChannel, msg = os.pullEvent("modem_message")
print(msg) --# oh look the message EHLO

This even supports my statement even more.

There are 65535 channels, and any one given computer can only open 128 channels at a time. That means in order to be listening to every single channel at any given point in time you would have to have 512 computers on recording the messages.

With a little work you could make finding your ID's(or even catching one of your messages) very unlikely.

You forget that one computer can have more that one Modem - that lowers scanner side to measly 86 computers. This becomes possible ;p
In the end this discussion is pointless because for each trick there is counter-trick.

Luanub, on 29 January 2014 - 05:21 AM said:

This even supports my statement even more.

There are 65535 channels, and any one given computer can only open 128 channels at a time. That means in order to be listening to every single channel at any given point in time you would have to have 512 computers on recording the messages.

Haha, no it really doesn't support your statement :P/>
Also I count 86 computers, not 512. 65535/128/6=85.3

Luanub, on 29 January 2014 - 05:21 AM said:

With a little work you could make finding your ID's(or even catching one of your messages) very unlikely.

*yawn* here is just a simplistic method that I've not even bothered to think more than 2 seconds about and I already know it would work on most servers, with a little bit more work it would work on all servers!

Step 1. Place down computer
Step 2. Make program with following on a disk

local max = os.computerID()
local modem = peripheral.wrap("left")

for i = 1, max do
  modem.open(i)
end

local _, _, sChannel, rChannel, msg = os.pullEvent("modem_message")

print("#"..rChannel.." sent a message to #"..sChannel.." saying: "..msg)

Step 3. Every few days re-place the computer (make sure not to label the computer, we want a new ID, hence suggesting the floppy in the previous step)
Step 4. ???
Step 5. Profit

Luanub, on 29 January 2014 - 05:21 AM said:

With a little work you could make finding your ID's(or even catching one of your messages) very unlikely.

You've actually kinda got something there. I tried to write an API for something like this a while back but ultimately I didn't want to spend the time to implement a cryptographically secure pseudo random number generator (CSPRNG for short). The idea is that you and another computer establish a common seed that no one else knows. Then you use that seed for the CSPRNG, which spits out numbers. Every time one of you sends a message, you both switch to the channel given by the next number from the generator. Because you share a seed, you will always be on the same channel. And because no one else has that seed, they won't be able to predict what channel you will be on.

Of course if you're going through all that effort, you might as well just use public/private key encryption instead. More secure and doesn't require a shared secret.

ElvishJerricco, on 29 January 2014 - 05:57 AM said:

And because no one else has that seed, they won't be able to predict what channel you will be on.

The seed has to be shared at some point, plus the generators would have to have some other factor to them to make sure that both the computers get the same channel — since they cannot share the new channel info with each other — meaning that it will be some kind of formula, one that can easily be 'hacked'; as long as the initial seed message is received…

theoriginalbit, on 29 January 2014 - 06:04 AM said:

ElvishJerricco, on 29 January 2014 - 05:57 AM said:

And because no one else has that seed, they won't be able to predict what channel you will be on.

The seed has to be shared at some point, plus the generators would have to have some other factor to them to make sure that both the computers get the same channel — since they cannot share the new channel info with each other — meaning that it will be some kind of formula, one that can easily be 'hacked'; as long as the initial seed message is received…

And if seed is static then system becomes predictable (first message is always on channel x next on y) and can be cracked given time and some cute program that captures this preset - as i said for each trick there is counter-trick.

I would propose a system which opened all 128 channels for a minute or so, then closes them and opens the next 128 channels and repeats until all channels are covered at which point it loops back (additional modems could speed this up). Any channels with activity are logged to a file. Leave it there a few days and eventually it will pick something up. A variation of the program could then carry on monitoring the channels you think are being used to confirm communications before you finally get in and attempt to hack the system. Although this is why next time I find myself on a computercraft server none of my base systems will be available on wireless. Wired connection requires physical tapping into the network cable which can easily be prevented with block protections.

6677, on 29 January 2014 - 06:27 AM said:

I would propose a system which opened all 128 channels for a minute or so, then closes them and opens the next 128 channels and repeats until all channels are covered at which point it loops back (additional modems could speed this up). Any channels with activity are logged to a file. Leave it there a few days and eventually it will pick something up. A variation of the program could then carry on monitoring the channels you think are being used to confirm communications before you finally get in and attempt to hack the system. Although this is why next time I find myself on a computercraft server none of my base systems will be available on wireless. Wired connection requires physical tapping into the network cable which can easily be prevented with block protections.

Better yet - code it into Portable PC - run it in background and get location from GPS each time you captured something - with x tries you could triangulate position and get id of every talking computer in areas you walk in ;p … You know what? i am gonna code it for myself ;p

As for wireless access? Make a firewall/repeater computer that sits between Wireless and Wired ;p Only one source of communication - easier to code some kind of access system ;p

On that note i think this discussion is getting more into discussion territory than suggestions one.

Minecraft is not built for security in game.

You know what else is not built for security? The Internet. Not the way it was originally designed. But smart people have built ways around this vulnerable architecture. Likewise we can with Minecraft. Encrypt or hash everything going over rednet and you'll be off to the races.

I vote no: if you want encryption or hashing, write your own SHA implementation. Easier: write your own ROT-13 ;)/> The 10% that oeed said can get in? This will easilly throw 90% of them ;)/>

Yes, encryption and hashing are great ideas in CC: CC is for more than door passwords; encryption can protect your rednet. And writing your own encryption, authentication, and authorization are great learning tools!

wojbie, on 29 January 2014 - 06:08 AM said:

theoriginalbit, on 29 January 2014 - 06:04 AM said:

ElvishJerricco, on 29 January 2014 - 05:57 AM said:

And because no one else has that seed, they won't be able to predict what channel you will be on.

The seed has to be shared at some point, plus the generators would have to have some other factor to them to make sure that both the computers get the same channel — since they cannot share the new channel info with each other — meaning that it will be some kind of formula, one that can easily be 'hacked'; as long as the initial seed message is received…

And if seed is static then system becomes predictable (first message is always on channel x next on y) and can be cracked given time and some cute program that captures this preset - as i said for each trick there is counter-trick.

CSPRNGs are a well researched field. These algorithms are not simply "cracked" given time and "cute programing." The only way to get the same sequence is to have the seed, which cannot be reverse engineered by the definition of the term CSPRNG. The only problem is getting the seed shared, but that's why you'd only use this if you and another person already shared the secret.

theoriginalbit, on 29 January 2014 - 06:04 AM said:

plus the generators would have to have some other factor to them to make sure that both the computers get the same channel

No. PRNGs are deterministic. They just look random. Given the same seed, you will get the same sequence. CSPRNGs are the same, just with much more secure algorithms.

So if both sides know the seed beforehand, they will never be on a predictable channel from someone else's POV and they will always be on a predictable channel from each others' POVs, again, by the definition of CSPRNG.

Even a disk drive with a startup file doesn't work for accessing your files if you use a modified version of the fs API that encrypts all files every time they're saved and requires the password on every launch. I will try making this but it will be more of a proof-of-concept than something really advanced.

Also you don't have to implement crypto algorithms yourself, just google for an implementation which already exists(for example google "Lua rsa" and you will find some implementations of rsa in Lua) and eventually you need to modify it a little bit to work with CCLua, but it's still a lot easier than implementing it yourself.

Problem with that, is a lot of those "boxed" implementations are based on C and thus, useless in CC.

Static seed + transmission time skew of seed == generation of next seed which is not static.
Encryption is entirely possible, and unique seeds that others cannot possibly know is also possible, provided they are not there to eavesdrop the initial static handshake. I've written at least two encryption apis on these forums. But at the end of the day, there is no point in encryption or hashing in CC, that is without block protection. Because whatever you're protecting, can just be smashed down.

But it's always a fun game of skills to create a computer with security and battle your friends to hack it and re-secure it again.

I support this suggestion, because CC is missing a lot of the essential components of an encryption algorithm without having to write horrifyingly slow implementations. A java-side implementation of at least one encryption algorithm would reduce the strain encryption can have on a server.

Putting aside that inbuilt security of any sort would totally take the fun out of it, wouldn't it be easier to just throw in secure point-to-point communications - eg make it so that when you rednet.send() something to a given ID, only the computer with that ID gets it, while other computers listening on that channel either get nothing or an unrelated randomised string - rather then go to the trouble of actually encrypting and decrypting data using code the user's never going to see anyway?

It is unlikely that rednet will be reverted to that behavior. Prior to the change to frequencies/channels, that is how rednet worked.

Lyqyd, on 15 February 2014 - 08:42 PM said:

It is unlikely that rednet will be reverted to that behavior. Prior to the change to frequencies/channels, that is how rednet worked.

Also, this is much more realistic in a real-world example. A wireless modem sending a message just sends out a signal to everything and hopes that it gets to the right place.