Secret key transmission over rednet.

I am trying to make a lock program which can be communicated with via Rednet (for this example, a pocket computer), thus the transmission between the two needs to be secure (ie: you can unlock the computer via the pocket computer, just as you would via the computer itself - with the added obstacle of rednet).

To do this, I assume I need to generate a unique key for that pocket computer on the 'host' computer. Then, using a handshake get the same key to the pocket computer. This way, all messages are encrypted and decrypted with the same key.

My issue is that I don't feel this is as secure as the hash being used on the host computer. Right now, the users hashed password is stored in a file, along with the salt used to hash it. Then, when the user tries to 'login', their entry is hashed with the same salt.

However, using encryption opens up the possibility of the message being cracked, or others getting their hands on the secret key. My idea was that when a user entered a password on the pocket computer, it would be encrypted, sent to the host, decrypted, hashed and compared. Then, the host would respond with an encrypted message containing the status (ie: correct/incorrect). Is this the right way to do things?

I also thought that a better/more secure way would be to send the salt used to hash the password to the pocket computer. Then, when a value is entered it is hashed and sent to the host computer, and then a response is returned (correct/incorrect) - eliminating the need for a handshake as the salt doesn't really need to be kept secret (or does it, I don't really know).

This is my first time doing anything like this (hashing/encryption/handshakes/etc), so I may have a lot of core concepts wrong - any help would be appreciated.

Yes, the salt can be public. It's only there to prevent rainbow tables etc.

You could look into how some car keys work (independent key generators in key and car and when they connect they compare the next key it generates). Write a RNG (which allows you to set a seed), make it unique for every pocket computer and store it somewhere. Once the pocket computer is trying to connect you could even use Diffie-hellman to further secure the connection. Once a connection is established both devices generate the next random number from the RNG, encrypt the hash using the random number and compare them. If the encrypted string is the same the pocket computer shall pass.
After that it stores the last random number which is later used as seed to generate a new one, or you store the times you already generated a random number to know where you are in the random sequence.

This can't really be intercepted because, AFAIK, there is no way to jam modem messages do the attacker could only read the messages, but never replay them. The only downside would be that once they somehow get out-of-sync (because either the host or the pocket computer thought that were connected and generated the next number) you would have to synchronize them again by setting the seed/position in the RNG for on of them.

H4X0RZ, on 27 November 2016 - 10:04 AM said:

The only downside would be that once they somehow get out-of-sync (because either the host or the pocket computer thought that were connected and generated the next number) you would have to synchronize them again by setting the seed/position in the RNG for on of them.

I'm not a security expert but could you just cycle numbers every x second (e.g. every 10th second in a minute) instead of every request? The important thing is that they both know to change at the same time. Then you just need to make sure that both are activated within the change time. You could also send the amount of positions/numbers cycled instead.

The way that sort of "rolling code" system is typically implemented is to have the receiver assume it might be out of sync whenever it gets a message it can't decrypt with the "current" code, and automatically check against a dozen or so more codes in the sequence. This way if you push the button on eg a garage door opener a few times while it's out of range (thereby rolling the code on the transmitter but not the receiver), you don't break the system (though if you push it a lot of times… yeah, you will, because the receiver will only check X amount of extra codes in the sequence before assuming you used the wrong transmitter device).

RSA is also worth reading up on - this thread might be a good start.

I am trying to get my head around this, but I am not getting very far.

My idea is I can type the ID of the pocket computer in the host computer, and it will somehow sync the pocket computer to that host. I don't want someone being able to intercept the message, and copy the identification so they can mimic the pocket computer. I figured to do that all messages need to be encrypted, and the key needs to be created and sent via a handshake, is this correct?

If someone could give me a step by step process from scratch (ie: create the key, send to X using Y method, so on), ideally with names of some methods to do this so I can do more research for that particular method. I am likely missing some core understanding, so I won't be able to understand this process if anything is skipped out because it is 'common sense' or something of the sorts.

The first thing you could do is search for some BigInt (pure-) Lua library and implement the Diffie-hellman key exchange for rednet. If you finished that you can use any key based encryption to establish a secure connection, even though the initial connection wasn't secure.