Getting rednet distance with routers in between

Hello, fellow coders,

I am looking for some help / advice for a new project of mine.

What I want to do is to create a safe alternative for rednet. I thought of encrypting the messages and for the key I use the distance the message travelled. This should be very unique and could be used by programs like browsers to generate multiple different keys without transmitting them. The problem appears when the transmission runs over a repeater, in this case the distance is relative to the repeater.
The only way I could think of to bypass this problem would be to make my own rednet api and repeat program, which would be quite a bit of work I don't really want to do.

So here's my actual question: Do you can think of an easier way to do it or have any other idea to generate a unique encryption key? Whatever you think, I would be glad if you leave a response

~King

Distance is not something you'd want to use for that sort of thing. Turtles and pocket computers will be constantly changing their distances. The current version of the rednet API does not return the distance value at all (only modem_message events still feature this), and if you had rogue repeaters, it would be possible to spoof the total distance for repeated packets. As well, it is not uncommon for several computers to have the same distance to another computer.

This does intrigue me however since using the distance factor would mean that any other computer listening in could possibly not be correct distance and would thus not be able to grab the key. A repeater however would be not difficult to code, however it would be more vulnerable. As you'd have to send the total distance along with it to the next repeater or so, which would mean that the distance data is available to be used by anyone listening in, and would just have to be expanded on or you could read the other way and see the amount of distance the other way went through.
To say that a little clearer, say the client sends something to the server through repeaters. Those repeaters will continue to boost up the number with the distance of the previous repeaters. Lets say you grab one towards the end, and intercept it's message. You now know the distance it took to reach that repeater from one way. But then the server sends back the information that's encrypted, but it's distance is saved for each repeater. and so by the time it reaches your intercepted repeater, you know the amount of blocks it took to reach that repeater from the server. You just have to add the two numbers together and then you have the key and can read the message/data.

Of course you could attempt to send the data over protocols, but that would be different.

I have been thinking about this a lot lately.

That is, a way to send encrypted info between clients.

I have yet to come up with a good way to communicate with PUBLIC computers.

But if you are the only one using the computers, you can create a function to scramble the letters of a string, then another to unscramble them.

Of course, if you wanted the program to be public, you need to have it scramble them using a KEY.
Then anyone can look at the code and know exactly how it works, but be unable to unscramble any intercepted messages without the key

NOW the problem is, how do you communicate the key?

Perhaps it could be a password that the user needs to enter? This is where I'm stuck.
I tried researching how your browser does it, but I haven't found anything.


Anyone else have thoughts on this?

So I am rethinking the whole concept right now. How about the idea that the repeaters first decrypt the message and then encrypt it again?
Btw I like the idea of an user-generated key (password) but you would have to register at the server first. Maybe a concept useable for a vpn? Ill keep it in mind

HPWebcamAble, on 30 January 2015 - 02:19 AM said:

I tried researching how your browser does it, but I haven't found anything.

With SSL, each server has two keys - a private and public one. The server sends the same "public" key to each new client that attempts to connect to it, the clients make up a new "session" key, and use the public key to transmit that back to the server.

The encryption is rigged so that only the "private" key (which the server never reveals) can be used to decrypt the data encrypted with the "public" key - that is to say, not even the client can decrypt the client's own transmission, only the server can! The session key, on the other hand, can be used to both encrypt and decrypt data, and so once the client and server have agreed upon that they no longer need the private/public key system to communicate.

Bomb Bloke, on 30 January 2015 - 08:49 AM said:

-snip-

Yeah, that's the RSA cryptosystem.
A few months ago I've made a RSA proof of concept, and due to the limitation in Lua, could only generate a 60-bit keypair, which is far too short of something secure and is pretty much impracticable.

Bomb Bloke, on 30 January 2015 - 08:49 AM said:

With SSL, each server has two keys - a private and public one. The server sends the same "public" key to each new client that attempts to connect to it, the clients make up a new "session" key, and use the public key to transmit that back to the server.

This works fine in real life, but in Minecraft with CC, EVERYTHING you send can be intercepted, so assume it is.

I still believe the easiest way is for the user to enter a password on both ends.

HPWebcamAble, on 30 January 2015 - 11:57 PM said:

This works fine in real life, but in Minecraft with CC, EVERYTHING you send can be intercepted, so assume it is.

You can assume the same thing with real life…

The method is still valid.

Client > Attempt to connect
Server > Sends public key
Client > makes session key
Client > encrypts session key with public key
Client > sends encrypted key to server
Server > decrypts session key with internal key corresponding to public key - it is not revealed to clients
Server/Client > uses session key to encrypt data.

KingofGamesYami, on 31 January 2015 - 12:04 AM said:

Client > Attempt to connect
Server > Sends public key
Client > makes session key
Client > encrypts session key with public key
Client > sends encrypted key to server
Server > decrypts session key with internal key corresponding to public key - it is not revealed to clients
Server/Client > uses session key to encrypt data.

I guess the part I'm missing is how the client can send the encrypted session key, but only the server's 'internal key' can decrypt it.
Why can't someone use the public key to decrypt the encrypted session key?

I'm assuming the code is public so anyone can figure out how the key is used to encrypt the info.

I suppose its possible I don't understand encryption very well?

Bomb Bloke, on 31 January 2015 - 01:23 AM said:

http://en.wikipedia....cryptosystem%29

Wow encryption is complicated :P/>

HPWebcamAble, on 31 January 2015 - 10:23 PM said:

Wow encryption is complicated :P/>

Really the maths and proofs of security are hard, but the concepts of it is very easy to understand.

After much thought, I have determined the problem with encryption in CC.

KingofGamesYami, on 31 January 2015 - 12:04 AM said:

Server > Sends public key
Client > makes session key
Client > encrypts session key with public key
Client > sends encrypted key to server

This is fine in real life, because the server can verify who the client is using the client's IP.
In CC, ANY computer could intercept the public key, and pretend to be the intended recipient.

It's possible IRL to change your IP to make it appear that your computer is someone else's, but it is MUCH harder than in Computer Craft.

I believe that if there was another way to verify a client's identity, it would be possible to use public key encryption

Like I said (or maybe didn't, but meant to), I believe it is impossible to send a message from a single computer to another computer using public code and wireless modems without another computer being able to decrypt the message in some way.
Remember, the code is PUBLIC so using set keyss is out. The client and server have to be able to make the keys up when they want to communicate.


Perhaps the modems could return the sender's ID. That would solve the problem.

I don't think you're getting the point of a public key - it doesn't matter who has it. The server will give it to anyone who asks for it. But any clients who want to hold a conversation with the server have to devise a session key, which they share with the server using an encrypted message which can only be read with the private key (which only the server holds). The public key can't be used to decrypt anything.

Thus it doesn't matter who eavesdrops on the conversation - only the server can read what each client's suggestion for a session key is, and only the client that created a given session key can read subsequent messages which make use of it.

Don't make the mistake of thinking that "computer identity" on the internet is any more "trustworthy" than in ComputerCraft. These techniques are used online precisely because you cannot trust the identity of a given online host, and nor can you be certain that your transmissions aren't being intercepted or altered. An IP address isn't trustworthy. A MAC address isn't trustworthy. Spoofing these things is trivial. So how does online security work?

Let's say you want to log in to a secure site online, eg paypal.com. You go to open the page, get redirected to the https version. The server sends your browser its public key, your browser makes up a session key, sends that to the server encrypted with the public one, which the server decrypts. Further transmissions - such as you actually attempting to login to your account - are performed via encrypted communications, using the session key. The site simply won't let you login without first performing a secure handshake.

Let's say someone decides to interfere. They either somehow tap an ISP, paypal's network, or (and this is far more likely), your local connection. They sniff your network traffic, they get your IP and MAC, then they start using them to generate packets of their own - masquerading as you. What can they do from there?

Let's say they get the public key off paypal (which is available to anyone), make up a session key of their own, and send it off to the server. Great. They've opened the homepage and are being asked to login. Same as anyone else who opens the homepage. Not a great accomplishment.

Let's say they grab a copy of the session key your browser sends to the server. To bad! It's encrypted with the public key, which can't decrypt anything. That information's useless to them - only the server can read it.

Let's say they try to intercept packets encrypted with your session key. Since it was never possible for them to obtain that key, they're still sitting there scratching their heads.

Your browser is free to allow you to login to the server, make a new account, whatever. All information that actually "matters" is sent over the encrypted connection.

Putting aside programming errors like Apple's recently discovered "goto fail" bug, there's still a loop-hole in that the client needs a way to know that the public key it's been given comes from the server it actually wants to communicate with. Only the real server can decode messages using its own public key, of course, but what if a fake server has its own public/private key combo? How does the client know that it's developing a connection with the right system?

On the internet, this is dealt with using certificate authorities - third-party companies who can verify who a given public key belongs to. If a server gives you a certificate for paypal.com with a certain public key, and a quick check with the certificate authorities says it doesn't match what they've got on file, then up come the warning messages telling you that the target server can't prove its identity. But how do you know a certificate authority is who it says it is? Well, most web browsers have certificates for most certificate authorities "built in", meaning that they don't have to ask for a public key to connect to them (as they've already got local versions of those keys which they know are correct). In ComputerCraft, you'd skip this business and simply code the server's public key directly into the client.

Bomb Bloke, on 05 February 2015 - 09:41 AM said:

Spoiler

I don't think you're getting the point of a public key - it doesn't matter who has it. The server will give it to anyone who asks for it. But any clients who want to hold a conversation with the server have to devise a session key, which they share with the server using an encrypted message which can only be read with the private key (which only the server holds). The public key can't be used to decrypt anything.

Thus it doesn't matter who eavesdrops on the conversation - only the server can read what each client's suggestion for a session key is, and only the client that created a given session key can read subsequent messages which make use of it.

Don't make the mistake of thinking that "computer identity" on the internet is any more "trustworthy" than in ComputerCraft. These techniques are used online precisely because you cannot trust the identity of a given online host, and nor can you be certain that your transmissions aren't being intercepted or altered. An IP address isn't trustworthy. A MAC address isn't trustworthy. Spoofing these things is trivial. So how does online security work?

Let's say you want to log in to a secure site online, eg paypal.com. You go to open the page, get redirected to the https version. The server sends your browser its public key, your browser makes up a session key, sends that to the server encrypted with the public one, which the server decrypts. Further transmissions - such as you actually attempting to login to your account - are performed via encrypted communications, using the session key. The site simply won't let you login without first performing a secure handshake.

Let's say someone decides to interfere. They either somehow tap an ISP, paypal's network, or (and this is far more likely), your local connection. They sniff your network traffic, they get your IP and MAC, then they start using them to generate packets of their own - masquerading as you. What can they do from there?

Let's say they get the public key off paypal (which is available to anyone), make up a session key of their own, and send it off to the server. Great. They've opened the homepage and are being asked to login. Same as anyone else who opens the homepage. Not a great accomplishment.

Let's say they grab a copy of the session key your browser sends to the server. To bad! It's encrypted with the public key, which can't decrypt anything. That information's useless to them - only the server can read it.

Let's say they try to intercept packets encrypted with your session key. Since it was never possible for them to obtain that key, they're still sitting there scratching their heads.

Your browser is free to allow you to login to the server, make a new account, whatever. All information that actually "matters" is sent over the encrypted connection.

Putting aside programming errors like Apple's recently discovered "goto fail" bug, there's still a loop-hole in that the client needs a way to know that the public key it's been given comes from the server it actually wants to communicate with. Only the real server can decode messages using its own public key, of course, but what if a fake server has its own public/private key combo? How does the client know that it's developing a connection with the right system?

On the internet, this is dealt with using certificate authorities - third-party companies who can verify who a given public key belongs to. If a server gives you a certificate for paypal.com with a certain public key, and a quick check with the certificate authorities says it doesn't match what they've got on file, then up come the warning messages telling you that the target server can't prove its identity. But how do you know a certificate authority is who it says it is? Well, most web browsers have certificates for most certificate authorities "built in", meaning that they don't have to ask for a public key to connect to them (as they've already got local versions of those keys which they know are correct). In ComputerCraft, you'd skip this business and simply code the server's public key directly into the client.

Thank you, I understand the whole concept much better now.