This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
ETHANATOR360's profile picture

rednet frequencies

Started by ETHANATOR360, 06 August 2012 - 12:26 AM
ETHANATOR360 #1
Posted 06 August 2012 - 02:26 AM
i think that rednet.send should be change from computer ID to the frequency the message is on to make it hackable but hard to hack.
example code
rednet.send ("msg, 351")
rednet.open ("top, 351")
rednet.set ("423")
Sxw #2
Posted 06 August 2012 - 02:53 AM
That would be AWESOME!!!!!!!!!!!!!!!!!!
Zalerinian #3
Posted 06 August 2012 - 04:04 AM
i think that rednet.send should be change from computer ID to the frequency the message is on to make it hackable but hard to hack.
example code
rednet.send ("msg, 351")
rednet.open ("top, 351")
rednet.set ("423")

I second this motion!
Sxw #4
Posted 06 August 2012 - 04:40 AM
… This calls for..
I am Sxw1212 and I approve this message.
:P/>/>
Pharap #5
Posted 06 August 2012 - 07:53 AM
I like the idea, but I don't think it should replace the computer id, perhaps be an additional feature.
It would also add semi-privacy since you could broadcast to everything on the one frequency, but not to every computer listening for rednet messages.
The hacking thing is also, dare I say it a good idea. Not only would trying to hack a frequency be a challenge to the hacker, but stopping the person from hacking the network would be a good challenge for the person in charge of the network.
wilcomega #6
Posted 06 August 2012 - 09:34 AM
very nice! i am gonna have to expand my rednet listener to support all 5 million frequencies

PS: a little bug in ur code, i should be like this:

rednet.send(3, "msg")
rednet.set( 512 )
ETHANATOR360 #7
Posted 06 August 2012 - 04:18 PM
I like the idea, but I don't think it should replace the computer id, perhaps be an additional feature.
It would also add semi-privacy since you could broadcast to everything on the one frequency, but not to every computer listening for rednet messages.
The hacking thing is also, dare I say it a good idea. Not only would trying to hack a frequency be a challenge to the hacker, but stopping the person from hacking the network would be a good challenge for the person in charge of the network.
and mabye this will start hackers acually hacking instead of making a 3 line virus
Pharap #8
Posted 06 August 2012 - 05:24 PM
I like the idea, but I don't think it should replace the computer id, perhaps be an additional feature.
It would also add semi-privacy since you could broadcast to everything on the one frequency, but not to every computer listening for rednet messages.
The hacking thing is also, dare I say it a good idea. Not only would trying to hack a frequency be a challenge to the hacker, but stopping the person from hacking the network would be a good challenge for the person in charge of the network.
and mabye this will start hackers acually hacking instead of making a 3 line virus
Which would be a bonus, since it means you'd actually need a bit more more intellect to work on, which means less chance of griefers taking advantage.
Plus there's a way to stop people getting into your rednet server(the computer managing the network) after the session has commenced, as well as allowing others to join.
Plus it would make a nice little 'community' style thing. Only issue is preventing player's computers operating on the same frequency without it being intended eg one player starts a network on frequency 178, and another player, about 2 or 3 chunks away, uses the same frequency. Without there being a way to tell one user the frequency is taken or there being a password to use a frequency, it's going to cause conflict.
ElvishJerricco #9
Posted 08 August 2012 - 10:00 PM
i think this idea is absolutely brilliant. As a guy making an internet like system, i can tell you uncrackable networks are VERY easy right now. This could be a very fun change.
Sebra #10
Posted 12 August 2012 - 08:40 AM
Intended holes in security is quite a BAD thing.
All, you are glad here, is a commit or prevent BAD behavior.
Can you imagine any positive use of this?
Pharap #11
Posted 12 August 2012 - 09:03 AM
Intended holes in security is quite a BAD thing.
All, you are glad here, is a commit or prevent BAD behavior.
Can you imagine any positive use of this?

It's harder to hack and easier to implement than the current system (from a user's point of view).
dimitriye98 #12
Posted 13 August 2012 - 01:10 AM
It allows more flexibility. If I want to send to computers 1, 2, 3, I can do it in one command rather than three. For three computers this isn't much of a difference, but for 10, for example in a rednet irc chat, it makes a significant difference in speed.
Cloudy #13
Posted 13 August 2012 - 01:15 AM
It allows more flexibility. If I want to send to computers 1, 2, 3, I can do it in one command rather than three. For three computers this isn't much of a difference, but for 10, for example in a rednet irc chat, it makes a significant difference in speed.

rednet.broadcast?

And you'll find the speed difference is negligible.

Having said that we do want to make rednet more realistic.
dimitriye98 #14
Posted 13 August 2012 - 02:59 AM
rednet.broadcast is insecure. If I synchronize all the computers taking part in the "conversation" to a certain channel, I can communicate between them fairly privately considering that there would be likely hundreds of frequencies. And if someone can intercept the messages, that just adds to the fun/realism. Also, if I can monitor private conversations between computers over bundled cable, it should be even easier with wireless, since logically, if the signals are in the air, I should be able to monitor them, provided I'm within range.
Cloudy #15
Posted 13 August 2012 - 09:50 AM
rednet.broadcast is insecure. If I synchronize all the computers taking part in the "conversation" to a certain channel, I can communicate between them fairly privately considering that there would be likely hundreds of frequencies. And if someone can intercept the messages, that just adds to the fun/realism. Also, if I can monitor private conversations between computers over bundled cable, it should be even easier with wireless, since logically, if the signals are in the air, I should be able to monitor them, provided I'm within range.

As I said, it is something we want to look into.

Point taken about broadcast - but sending a message to 10 computers at once won't cause a speed loss the way you're describing it, considering it is mostly Java side code.
Sammich Lord #16
Posted 13 August 2012 - 11:34 PM
Well this stuff could be possible with somebody making a API and have servers setup that when sent to that server the server sends it to the computers connected to that "frequency". I will start getting working on some code in see how easy the API will be to make.
kamnxt #17
Posted 14 September 2012 - 12:19 PM
Awesome idea!
The rednet could be open, so hackers could read your messages…
It would be a nice challenge, because if you don't want hackers to read your messages (and send new) easily, you can just secure it! ROT13, base64…
And… broadcasting like APs: you could make the rednet modem broadcast it's name and frequency, and you could find them on other computers! And maybe mac addresses… and ip addresses…
And you could add auth systems!
immibis #18
Posted 14 September 2012 - 12:21 PM
secure it! ROT13, base64…
Please tell me you're joking.
KaoS #19
Posted 15 September 2012 - 06:34 AM
I like the idea, but I don't think it should replace the computer id, perhaps be an additional feature.
It would also add semi-privacy since you could broadcast to everything on the one frequency, but not to every computer listening for rednet messages.
The hacking thing is also, dare I say it a good idea. Not only would trying to hack a frequency be a challenge to the hacker, but stopping the person from hacking the network would be a good challenge for the person in charge of the network.
and mabye this will start hackers acually hacking instead of making a 3 line virus
Which would be a bonus, since it means you'd actually need a bit more more intellect to work on, which means less chance of griefers taking advantage.
Plus there's a way to stop people getting into your rednet server(the computer managing the network) after the session has commenced, as well as allowing others to join.
Plus it would make a nice little 'community' style thing. Only issue is preventing player's computers operating on the same frequency without it being intended eg one player starts a network on frequency 178, and another player, about 2 or 3 chunks away, uses the same frequency. Without there being a way to tell one user the frequency is taken or there being a password to use a frequency, it's going to cause conflict.

I don't think operating on the same frequency is a problem, at the moment we all operate on the same frequency and we must adapt to do so, in order for it to be realistic I think anyone should be able to use a frequency. I think it would be awesome because you could make a frequency algorithm based on the os time or anything to keep cycling, it's an amazing idea
thepowdertoy #20
Posted 19 September 2012 - 02:34 PM
I agree with this, not just because this makes this harder to hack, but because I don't need to change the send id every time I change my computer
JJRcop #21
Posted 19 November 2012 - 09:26 AM
I don't know if bumping is allowed, but I want to bring more attention to this from the forum community.
Cloudy #22
Posted 19 November 2012 - 11:13 AM
Already planned, and no bumping isn't allowed :)/>/>
billysback #23
Posted 19 November 2012 - 11:52 AM
but spam isn't?
so technically if you bump a thread with a one-word post then the bump is not allowed?

(I do like this suggestion though)
Cloudy #24
Posted 19 November 2012 - 12:36 PM
but spam isn't?
so technically if you bump a thread with a one-word post then the bump is not allowed?

(I do like this suggestion though)

What?
Orwell #25
Posted 19 November 2012 - 02:33 PM
secure it! ROT13, base64…
Please tell me you're joking.
Well I don't wanna keep going on this thread, but I just HAVE to say that this remark is brilliant. :(/>/>
billysback #26
Posted 19 November 2012 - 08:53 PM
but spam isn't?
so technically if you bump a thread with a one-word post then the bump is not allowed?

(I do like this suggestion though)

What?
wait, nvm what I said, I thought you said bumps are allowed, because I thought they were o.o
Dlcruz129 #27
Posted 29 November 2012 - 06:38 PM
but spam isn't?
so technically if you bump a thread with a one-word post then the bump is not allowed?

(I do like this suggestion though)

What?

The funny thing is that was a one-word post. :P/> SPAMMER!
Tiin57 #28
Posted 30 November 2012 - 12:40 AM
-snip-
The funny thing is that was a one-word post. :P/> SPAMMER!
You bumped it.
Which allowed me to show my appreciation of this idea. :P/>
KillaVanilla #29
Posted 30 November 2012 - 02:25 AM
I've actually made a version of this that actually works with the current version, and i runs as an API. It's also slightly less secure than what you're describing.
PixelToast #30
Posted 30 November 2012 - 03:48 AM
.-.
this is scary
whatever, ill make some sort of protocol to authenticate a two way connection
cryptography ftw
KaoS #31
Posted 30 November 2012 - 03:53 AM
there is no way of securing this without denying access to the normal rednet function or anyone can mimic whatever you do
PixelToast #32
Posted 30 November 2012 - 04:33 AM
there is no way of securing this without denying access to the normal rednet function or anyone can mimic whatever you do
http://en.wikipedia....an_key_exchange
where the public key is a checksum of your computers id
and private key is a large random number

problem solved :3
9000 times harder to crack

well, this is just a means of ensuring a secure connection between two computers
not to authenticate ids

i think it is prone to man in the middle attacks but you will have to send data fast in order for it to work
KaoS #33
Posted 30 November 2012 - 04:58 AM
but in that case you have to manually set up a connection between 2 IDs in order for it to work don't you
… might as well rn.send(id,msg) for secure transfer
PixelToast #34
Posted 30 November 2012 - 05:11 AM
but in that case you have to manually set up a connection between 2 IDs in order for it to work don't you
… might as well rn.send(id,msg) for secure transfer
not sure if there is a way to authenticate ids :s
because you can always just overwrite os.getComputerID

so, i think rednet.receive sould atleast return the actual id
GopherAtl #35
Posted 30 November 2012 - 05:13 AM
overriding os.getComputerID does NOT affect the id attached to rednet messages.

Also, this discussion is in the frequencies thread; send(id,msg) is going to become send(freq,msg), so send will not be secure anymore once the frequencies change is implemented, hence the sudden need for encryption.
Cranium #36
Posted 30 November 2012 - 05:23 AM
overriding os.getComputerID does NOT affect the id attached to rednet messages.

Also, this discussion is in the frequencies thread; send(id,msg) is going to become send(freq,msg), so send will not be secure anymore once the frequencies change is implemented, hence the sudden need for encryption.
I don't think that's how it's going to happen. Removing an already implemented feature to make room for a more customizable feature(while losing security) would not really make sense. At most, I think that rednet.send() would simply take another optional argument. So it would most likely need to be rednet.send(id, message, frequency). That way, existing services and programs are not broken with this update.
GopherAtl #37
Posted 30 November 2012 - 05:27 AM
that is how dan said it was going to happen on irc. He may have changed his mind, it's been a while and there were some people objecting to losing the secure way of sending to id, but this was the plan he described then…

rednet.send() will use a frequency or frequency range as the first parameter. On the recieving end, you will be able to set a frequency or frequency range to listen on. By default, the listen range use the id of the computer as it's listen freqency.

So existing programs would continue to work, as by default they listen on only their own frequency so sending on that frequency will send to them. But other programs would be able to listen in on these same frequencies, making send no longer a secure, private way of sending data.
Cranium #38
Posted 30 November 2012 - 05:32 AM
Yeah, I don't like that iea. Making it have an additional argument at the end would make much more sense
PixelToast #39
Posted 30 November 2012 - 05:40 AM
i dont like the idea of another parimeter :s

the method he is describing is VERRY hard to crack (especially using the method above)
i like the idea alot ^_^/>

but, i think it sould be optional as cryptologists and verry good programmers will have a huge advantage over people who arent really good at securing their programs
OmegaVest #40
Posted 30 November 2012 - 06:09 AM
Middle ground:

rednet.cast(freq, msg).

Broadcast would sow across all frequencies to all computers, cast to all computers listening to a single frequency, send to a specific computer, no frequency. I don't really see a use for it yet (that would be widely used), but I see it as necessary.
Cloudy #41
Posted 30 November 2012 - 07:21 AM
Broadcast will probably die. It is horribly misused anyway.
PixelToast #42
Posted 30 November 2012 - 08:25 AM
Broadcast will probably die. It is horribly misused anyway.
i already used frequency 0 to negotiate a random frequency to use with other client
the only thing i use broadcast for is to locate network hosts nearby, wich can also just be send to freq 0
ChunLing #43
Posted 30 November 2012 - 08:41 AM
As long as you can still access the same functionality by using rednet.send(nil,message), I don't have any objection to deprecating rednet.broadcast(). But if you actually disable the rednet.send(nil,message) function, then you're just going to get a bunch of "clever" workarounds involving large for loops and such, which strikes me as counterproductive.

Really, rednet.send already works so well (properly used) that it's hard to justify "improving" it. Though the point of the original post was making it easier to hack, which isn't an improvement. And what the heck is wrong with the old trick of sneaking to a node and reprogramming it (particularly since you can do it remotely using a turtle with a floppy and disk drive)? It's just a little harder, it isn't fundamentally impossible (unless they've arranged some kind of anti-turtle defenses around the target computers, in which case props to them and step up to the challenge).
GopherAtl #44
Posted 30 November 2012 - 08:49 AM
I think one of the goals of the frequency system is to allow sending to multiple computers without looping or using broadcast. Take gps as an example, instead of broadcast you would choose a gps frequency which you could send to and receive from all gps hosts on. In general this means that new computers can be added to existing systems without hard-coding any ids anywhere. This sort of thing, not the "easier hacking," is the improvement.
Cranium #45
Posted 30 November 2012 - 09:17 AM
Broadcast will probably die. It is horribly misused anyway.
I just have a question about existing programs that make use of rednet.broadcast. Will there be an option for backwards compatability where any call to rednet.broadcast would simply default to frequency 0?
tom2018 #46
Posted 30 November 2012 - 09:57 AM
well it would not be hard to hack… you have it automatically scan trough all possible frequencies.
in this example rednet.set is frequency setter

start = 1
range = 1000
c = start
r = range + 1
while true do
if c == r then
c = start
end
rednet.set(c)
rednet.broadcast("ping")
x = nil
x,y,z = rednet.receive(.05)
if x ~= nil then
print(x..": "..y.." :distance to ["..z.."]".."on frequency:"..c)
end
c = c + 1
end
JJRcop #47
Posted 30 November 2012 - 10:18 AM
I like the idea with frequency. I do not like the current system with computercraft being impossible to hack. You cannot listen into data, you can easily
prevent spoofing. It's terrible.

I do not like what people are saying about this being optional. Computercraft in multiplayer servers will be so much more fun if everyone is required to use this. Otherwise nobody will use it.

(Cranium, I want to come over to where you live and yell at you, telling you how selfish you are..)
EDIT: I thought cranium liked having CC's bulletproof rednet, and I was mistaken; he was talking about backwards compatibility.
Edited on 30 November 2012 - 09:37 AM
Cranium #48
Posted 30 November 2012 - 10:29 AM
I like the idea with frequency. I do not like the current system with computercraft being impossible to hack. You cannot listen into data, you can easily
prevent spoofing. It's terrible.

I do not like what people like Cranium are saying about this being optional. Computercraft in multiplayer servers will be so much more fun if everyone is required to use this. Otherwise nobody will use it.

(Cranium, I want to come over to where you live and yell at you, telling you how selfish you are..)
I see wut u did thar….
But I only meant that for existing programs being able to run as they previously did. I have a mail system that broadcasts a ping, listens for a response, then homes in on that response and uses that ID to send to from that point on. My suggestion was just to say that if someone uses rednet.broadcast(), it would just do the same thing, like sending on all frequencies. I know that there are several systems that rely on broadcast in one form or another, and I don;t think that everyone wants to recode just so they can keep using ther programs. (since it's usually something one person wrote, and modifying it might screw things up). It would only be a modification of rednet.broadcast.
JJRcop #49
Posted 30 November 2012 - 10:36 AM
I didn't think of that. I had the wrong idea. I thought you were one of those people that didn't want this because you liked how CC's rednet was unhackable.

I apologize and I am sorry.
GopherAtl #50
Posted 30 November 2012 - 10:57 AM
cranium, with the system dan proposed and I described earlier, all existing code would still work without modification, it just wouldn't be perfectly secure anymore. removing broadcast would break code that uses it, but if you can send on any arbitrary range, as I believe was also planned, you could just send on all frequencies to achieve the same effect - which of course makes removing broadcast a symbolic victory at best…
tom2018 #51
Posted 30 November 2012 - 11:17 AM
I like the idea with frequency. I do not like the current system with computercraft being impossible to hack. You cannot listen into data, you can easily
prevent spoofing. It's terrible.

I do not like what people like Cranium are saying about this being optional. Computercraft in multiplayer servers will be so much more fun if everyone is required to use this. Otherwise nobody will use it.

(Cranium, I want to come over to where you live and yell at you, telling you how selfish you are..)
I see wut u did thar….
But I only meant that for existing programs being able to run as they previously did. I have a mail system that broadcasts a ping, listens for a response, then homes in on that response and uses that ID to send to from that point on. My suggestion was just to say that if someone uses rednet.broadcast(), it would just do the same thing, like sending on all frequencies. I know that there are several systems that rely on broadcast in one form or another, and I don;t think that everyone wants to recode just so they can keep using ther programs. (since it's usually something one person wrote, and modifying it might screw things up). It would only be a modification of rednet.broadcast.
my idea is that it would just run on the default frequency of 0
and not on all
ChunLing #52
Posted 30 November 2012 - 11:42 AM
The current system is not unhackable. If you think it is, then you don't have any cred as a hacker anyway, so why bother?

I do like the idea of having an interface that lets you add a frequency parameter to rednet messages, so that only receivers with that frequency set on a modem can get that message. But it is physically possible (and necessary, in modern telecommunications) to beam messages so that only the intended receiver gets them. Hackers who want to break into such systems have to deal with proximity issues all the time, how to get physically close enough to a vulnerable part of the network.
Cranium #53
Posted 30 November 2012 - 12:16 PM
my idea is that it would just run on the default frequency of 0
and not on all
So If you use rednet.broadcast, it would just be on frequency 0, and rednet.receive with no parameters would also listen only on 0. That way, existing programs would still be able to run as they were.
Lyqyd #54
Posted 30 November 2012 - 03:16 PM
my idea is that it would just run on the default frequency of 0
and not on all

No, broadcast would be basically rednet.send("0-65536", "message") or whatever the maximum frequency ends up being.
PixelToast #55
Posted 30 November 2012 - 05:12 PM
well it would not be hard to hack… you have it automatically scan trough all possible frequencies.
in this example rednet.set is frequency setter
-snippy pixel-
not using my method above ^.^
after you get a shared key you can use a symmetric encryption algorithm using the shared secret as the key

thats why i said this sould be optional as people who dont know anything about those types of things will be prone to people spying on their port
Doyle3694 #56
Posted 30 November 2012 - 08:15 PM
I definetly second this idea.
Cloudy #57
Posted 30 November 2012 - 08:55 PM
I personally don't like the idea of sending on a range - broadcast was for when you couldn't communicate with more than one computer at once. Once frequencies come in, you will be able to.
JJRcop #58
Posted 30 November 2012 - 09:17 PM
Cloudy, can you tell us if this may be optional or not? We would really like to know.
I would personally prefer it to not be optional.
D3matt #59
Posted 30 November 2012 - 09:37 PM
If we're going to have it possible to listen in on frequencies now, I think we need LAN cables added to the game, similar to using RP2 cables, but not so horribly slow and laggy.
Sebra #60
Posted 01 December 2012 - 12:57 AM
Oh, I'm afraid developers going to break working things :(/>
Now it is impossible to protect computers from external startup :(/> Soon no link will be safe :(/>
Do not force other players to play the way, you want. Crypto-programs is unneeded load for servers and problems with trust. -> less fun
KaoS #61
Posted 01 December 2012 - 01:10 AM
problems with trust. -> less fun

I d'no about that, that is what PvP is for, if you want a friendly server that is great (I think you should be able to choose that) but factions and Pvp bring a lot to the game, competition man: it rocks
Cloudy #62
Posted 01 December 2012 - 01:14 AM
Oh, I'm afraid developers going to break working things :(/>
Now it is impossible to protect computers from external startup :(/> Soon no link will be safe :(/>
Do not force other players to play the way, you want. Crypto-programs is unneeded load for servers and problems with trust. -> less fun

You mean, rednet isn't broken already? Someone would STILL need to guess which frequency you were using - and if you're clever you can cycle frequencies. Broadcast is a broken concept that isn't needed with these changes. I'd prefer it was removed altogether, but it all depends on how Dan wants to do things. We may add ports protected with a password for example - it just depends.

Besides, even basic Crypto (or just not making the message human readable for control systems) would suffice. Crypto can be done quite fast, with the addition of Java native binary operators which we have already added.

Cloudy, can you tell us if this may be optional or not? We would really like to know.
I would personally prefer it to not be optional.

I don't know. And stop it with the annoying hidden text. Protip - it isn't hidden on mobile devices, or once you're quoted.
Sebra #63
Posted 01 December 2012 - 08:51 AM
In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.
Cloudy #64
Posted 01 December 2012 - 08:58 AM
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

Yes, because something that isn't a modem needs to have modem capabilities. Makes sense.

We may open it up to others in the future, we may not.
KillaVanilla #65
Posted 02 December 2012 - 10:53 AM
In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

Or perhaps it will shift the attention to creative confrontation.

One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?
CoolisTheName007 #66
Posted 02 December 2012 - 03:55 PM
But…but…argh, I can't code networks like this! One day everyone has an unique way to prove it's identity (by receiving the ID of the sender no matter what) and now 'everything' wants to change…Had just started coding routing protocols and now I must go through the trouble of security… Please consider that reliable authentication will be an extra burden on the processor. I will proceed to cease activity on networking until there's…well, I know no one has to promise anything, but, comm'on, some projects rely heavily on the present state of things.
GopherAtl #67
Posted 02 December 2012 - 05:17 PM
unless I'm mistaken, you would still get the id of the sender as the first parameter, not the frequency, so you would still know who sent the data, you just can't be sure others aren't listening in. Unless you're sending passwords or account information, it's not an issue. If you are.. start researching cryptography I guess XD
Pharap #68
Posted 02 December 2012 - 06:20 PM
Personally I see the frequency thing as more of a convenience for less experienced players and lazy players.
Whether it's a benefit or detriment to security is irrelevant. Sure you'll always have users who want maximum security and you'll always have players who like to be able to break security.

But what of the beginners who aren't experienced with programming or encryption?
Yes this mod is designed for programmers, but by the same token, it should be a 'pick up and play' mod that can be used without needing masses of programming +knowledge. Ultimately, being advanced with programming will still be an advantage because you can do more, but some people want to use this mod but just can't be bothered to learn to program. It's like real world computers, you can send emails and play games and all that without knowing how to program, or you can learn to program and make some of your own tools to use (much like indie gamers and open source software developers).

Without the frequency system, you have to keep track of who you do and don't want to send the messages to, which while being secure, can be difficult for beginners and time-consuming for the lazy. With frequency systems, beginners will see it as being easy and be more inclined to use the mod and lazy programmers won't have to keep retyping the same code every time they go to a different CC server. It is less secure as people can listen in, but generally hacking is against server regulations, and on the ones it isn't, it adds a reason for people to develop security systems even further. Making it optional will of course ensure that people (and servers) don't have to use it, but the option is always there, just like with the fuel divide.
Sebra #69
Posted 02 December 2012 - 07:20 PM
Spoiler
In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.
Or perhaps it will shift the attention to creative confrontation.
One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?
1.War is reason for most inventions, but still very bad thing.
2.Yes, but challenge to create some beauty is better than challenge to break some. You already able to hack any CC comp, you have access. You want just wireless way to do it.
3.If your "zip through" means "break anything" then I'm sorry about you. :(/>
4.LAN cables, WR inter-dimensional modems (if Chicken Bone add it you get frequencies also), inter-MC-world communicators … Use constructive creativeness, not destructive.
Pharap #70
Posted 02 December 2012 - 08:09 PM
Or perhaps it will shift the attention to creative confrontation.

One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?

'Creative confrontation' is no good unless both parties are willing, otherwise it becomes a game of 'beat someone up, watch them leave the server in despair' or 'beat someone up, get kicked off the server'. Also, I find it hard to believe that the majority of the people on this server would use frequencies purely as a way of causing grief to other players.

I beg to differ, the whole idea of sandbox is to have fun without there being an actual goal and without having to worry about things like taking damage or getting hungry - you can do whatever you like without having to worry about 'how you're going to run things'.
KaoS #71
Posted 02 December 2012 - 08:15 PM
@Pharap I prefer the case of 'beat someone up, get away with it' :D/>
Cloudy #72
Posted 03 December 2012 - 12:15 AM
Nothing is set in stone. Work hasn't even STARTED on rednet modifications - but I definitely want broadcast to die. By die I don't mean crash programs - I mean "don't send to every computer and it's mother".

I think you're all exaggerating the security concerns - before someone can listen on your frequency they have to know it first. This is not a way to cater to users laziness - lazy users already use broadcast which has absolutely no security whatsoever.

I will however take people's concerns into account when me and dan are designing this feature. Maybe we'll add a way to secure your channels, maybe we won't.
BigSHinyToys #73
Posted 03 December 2012 - 12:46 AM

local function broadcast(message)
	for i = 1,channels do
		 rednet.send(i,message)
	end
end
… and even before broadcast is removed it is bypassed.

The current method of rednet messaging is simple adding additional problems to connectivity will force a standard of some kind to be formed for secure network traffic. This could both be seen as a good thing and a bad thing. servers with low hardware specks will not run as well if all computers are running encryption / decryption on every packet. personaly being able to capture all traffic and analyze it will be a fun activity. compromising systems by broadcasting Spam on one channel could be by passed by having the program just channels if there is to much activity. I'm kinda iffy about this will have to wait and see how the exact implementation is and if all programs are broken.
ChunLing #74
Posted 03 December 2012 - 02:36 AM
Maybe rednet.send(nil,message) could cause the message to only travel the minimum range (like during a thunderstorm). You could have something like interference so that the number of discrete rednet.send()'s from a given modem in the current tick would each degrade the effective altitude by 1, so by the 255th message in a single tick the range would be the same as for sending from bedrock or during a thunderstorm.

That would mean that the limitation wouldn't be too easy to bypass, but wouldn't overly affect intelligently designed systems that avoided spamming.
CoolisTheName007 #75
Posted 03 December 2012 - 04:23 AM
In general, one needs:

send(group of computers, msg)
setListenTo(group of computers)

where 'group of computers' can be defined in many ways, e.g. a table of computer ID's, a frequency, a range; a pair (frequency, password), ect.

We have several factors at play here:
-efficiency
-security
-ease of use
-realism

In terms of efficiency, by sending messages to the desired target exactly:
- a substitute of broadcast() that restricts itself to a subgroup of computers (maybe determined by those listening for a frequency, as suggested) would allow better neighborhood detection;
- for simple computer A to computer B communication, with send(freq,msg) and listen(freq,msg) one would have to set up a frequency for each pair of computers. This is not difficult, but:
- listening for different frequencies is then necessary if we are to have computers listening to their neighbors. So I would still prefer to have send(id,msg); however, if a computer is hosting more than a network, e.g. it's a gateway linking two networks, it needs to listen to different broadcasts, and consequently different frequencies, at the same time. at least listening for 2 frequencies should be allowed.

To conclude, I would prefer having:
broadcast(freq,msg)
setFreqToListen(set of frequencies)
send(id,msg)
so that a message is sent either if:
-there was a broadcast in a frequency set by setFreqToListen(set of frequencies);
-there was a direct message by send.
'rednet' event parameters would have to distinguish between frequencies and direct sends, and also pass the id of the sender.

There is a loss of realism here: every computer has already a unique id and it is passed through messages, but, also, every computer may be forced to listen to a limited amount of frequencies, which in my opinion is unrealistic.
I recognize that some people might find it fun to find security solutions for authenticating ID's and ect. It is entirely a matter of opinion whether or not to sacrifice efficiency, ease of use and security for the sake of realism. Either one may lead to interesting programs, but IMO considering that the main bulk of ComputerCrafters are not expert programers, I would prefer the first one.

In terms of security:
- there would be little originality here: encryption. Instead of just increasing server load with it, why not to abstract it in the java side:
assuming there's a get_key(id,freq) function implemented Lua side and passed to rednet for each computer:
send/broadcast(id/freq,msg,key) would , for each target in range and matching id/freq, pass the message if key==get_key(id,freq) of the target.

Replies:

You could have something like interference so that the number of discrete rednet.send()'s from a given modem in the current tick would each degrade the effective altitude by 1
This would limit speed in transmissions, not sure if it would be enough for networks or terminal redirection.
Sebra #76
Posted 03 December 2012 - 04:30 AM
What is wrong with broadcast? If you know receiver ID, use it. If not - use broadcast.
Broadcast definitely needed for GPS. You do not need to know host's ids.

I do not need really to hide my messages. Most wanted feature for me is reliable sender id. Let anyone decipher anything as long as I can filter out enemy commands.

If you allow rednet to use any peripheral (with methods "open", "send", "receive", "close"), you can apply frequencies to modems only by adding optional "setup" method. In "setup" method any specific options can be tuned. You can set output frequency, input frequency diapason, transmission speed if you want… More input frequency diapason means less range. Less transmission speed means more range but delivery delay. Each peripheral can treat "setup" as it want, frequency for modem only.

edit: found an error in my post plus short answer.

@PixelToast So real need is to try to isolate your input from spammed channel, not to enable hacking and encourage cryptowars.

And yet another idea to look:
Use string as a channel id. Modem should receive messages iv receiver tuned with substring of transmitted channel. For example modem, tuned with "PixelToast" would recieve messages on "PixelToast 1", "PixelToast going to win", but not "GPS" channel. To receive all channels you can tune receiver with "".
Edited on 03 December 2012 - 06:27 AM
PixelToast #77
Posted 03 December 2012 - 05:42 AM
What is wrong with broadcast? If you know receiver ID, use it. If not - use broadcast.
Broadcast definitely needed for GPS. You do not need to know host's ids.
and thats why you need frequencies
each program will have its own frequency
so anyone who does not want to receive those annoying ping messages dont have to
CoolisTheName007 #78
Posted 03 December 2012 - 09:21 AM
What is wrong with broadcast?

Efficiency: everyone in range of the broadcaster will get a new event in their event queue; that means, java side, that a lot of coroutines, each representing a computer waiting for an event, will be woken up. By using frequencies, you wake up exactly those who want to hear the broadcast.

Security: the main issue it that you want a set of computers S to be able to communicate without any external interference from other computers.
One solution is to keep a whitelist, a list of the computers in S, in each computer of S. Now that I think about it, it wouldn't be difficult to keep a whitelist in a large network if the network was divided in smaller networks, each with it's whitelist, and there weren't connection issues. However, imagine a computer wants to move from a network to another. It would have to know where it would be next, and inform the corresponding subnetwork.

I think that a realist, safe, easy to use, and lag-free system would be the one I described previously, but without the possibility of sending directly to an ID. Why not send the ID? Well,
-it's superfluous, since after sharing keys, computer A should trust computer B to send it's ID in the rednet message;
-the ID's existence it's a 4th wall breaker, and here is a chance to reduce their importance.

Zebra remembered me that send(id,msg) is essential; so:

send(id,msg) would be just like the normal send.

broadcast(freq,msg,key) would:
-first check range;
-then check if @freq is in the target listening frequencies (one frequency only would not allow a computer to participate in two networks at the same time; listening to two frequencies would be enough)
- then it would call get_key(@freq) (or access a previously set key for that frequency) from the target and check if it matched @key
- if yes, it would queue a rednet event to the target event queue with the parameters @freq, @msg, distance.

IMO, the question remains whether or not send() should return false in case the message isn't delivered. It isn't difficult to implement a handshake, such as send(id,msg), wait(timeout, id=id,msg=='i got it'), what got me thinking that maybe that should be done in Java too. It would reduce network traffic caused by handshakes.
Some may say that, if it send does provides that information, an attacker could iterate over the possible keys and know when it got to the right one by getting true from send(). But that's very unlikely to happen: on CCEmulator, I took some measurements and got an upper bound of 10^8 operations per second. Now, imagine your key is a 10 char string, each one is a byte. That gives (256)^10/10^8~10^19 seconds to check all combinations. That is, 317097919 millenniums Sure, this isn't the same as the expected time to get the right answer, which is at least the number of combinations/2 and which I've sampled with this code:

j=tonumber(...)
s=0
for i=1,j-1 do
s=s+i/(j-i)
end
print(s)

So, my opinion is that there are some procedures in real-life networking that I would rather skip in ComputerCraft, because:
- they are both non-original and have standard implementations;
- they can be simulated in the Java side much more efficiently, consequently reducing server lag.
- because they are simulated exactly as they happen in real-life, e.g. both low processing cost and behavior, we keep the experience realist.
Sebra #79
Posted 03 December 2012 - 10:05 AM
@CoolisTheName007
So effectively you want _only_ broadcast but with divided networks. It works against your efficiency thesis.
Also "without the possibility of sending directly to an ID" works against security thesis too.
Forced encryption do not fit in "Ease of use" unlike sending to ID.
Realism? Look for it outside the game. Why you call it "frequency"? Who can measure it?

As I said rednet uses sender id internally for routing needs. You want to break it. And all it just to allow hacking and force all CC users to cryptography.
CoolisTheName007 #80
Posted 03 December 2012 - 10:29 AM
snip
Your comment is in general incompletely justified, but did remembered me that I forgot that send(id,msg) is essential for efficiency. I will include it in my post. Thanks!
KleinRefrigerator #81
Posted 03 December 2012 - 10:37 AM
But that's very unlikely to happen: on CCEmulator, I took some measurements and got an upper bound of 10^8 operations per second. Now, imagine your key is a 10 char string, each one is a byte. That gives (256)^10/10^8~10^19 seconds to check all combinations. That is, 317097919 millenniums.

We have to presume an attacker will not stay within the bounds of CC or the emulator, and 80 bits is on the verge of readily crackable. You really shouldn't be using less than 128 for a symmetric-key cryptosystem. However, from a security and efficiency standpoint, the existing system is probably best. Messages are not interceptable if sent directly, and if you exchange keys securely, preferably in person, even indirect sending should be pretty much completely secure if you use a good cryptosystem. Remote key exchange can be vulnerable to man-in-the-middle attacks, though the specifics vary for the key-exchange algorithm, some would give the attacker the symmetric key that he could later use to decrypt any intercepted messages, but others would require the attacker to remain involved in the interaction, decrypting and re-encrypting everything before passing it on.

I think if what you're going for is a system that might be suitable for communication and espionage in some sort of PvP, trying to implement it within CC is probably the wrong way to go. Implementing it as a CC plugin or perhaps even an entirely different mod that would allow for messages that can be intercepted, and "encryption", which would really just mean that the server stores the plaintext and only gives it up when someone provides the correct key when "decrypting" ciphertext or does something to attack and decrypt the message. It would be far, far easier to balance.
CoolisTheName007 #82
Posted 03 December 2012 - 10:46 AM
snip
I think I got totally the wrong message across by forgetting that send(id,msg) is crucial. I just want to improve the broadcast function, that currently is inefficient because it wakes up everyone in the vicinity, and requires encryption to authenticate neighbors as safe (without using whitelists, which are unpratical). broadcast(freq,msg) is better, and a complete solution if frequencies are allowed to be long enough as typical symmetric keys.
If they are not, then broadcast(freq,msg,key) would solve the issue:
The key from A broadcasting to freq1 that B and C are listening to, never gets told to either of them; B and C must provide a key to the Java side, via either a map freq->key (defined by the user, LUa-side) that defaults to default key, that is then compared to the key parameter in broadcast(freq,msg,key). By not providing a key in A,B,C sides, the broadcast function would act as originally suggested, transmitting to all in the same frequency and that hadn't set a key for that frequency. You would have more security and efficiency when using broadcast, not less. And send(id,msg) should remain.



Also, isn't a byte an ordered set of 8 bits? Thus having 256 possible values? How did you get the 80 there?
ChunLing #83
Posted 03 December 2012 - 11:03 AM
"imagine your key is a 10 char string, each one is a byte."

Which isn't really a whole 80 bits worth of information, it's closer to 60 bits because of the limitations of character strings. But this is neither here nor there. If someone wants to use real-world computing resources to break into your CC network, they should just log on as you after you log out and go around and do whatever they like inside your base…as you. Defending against that is obviously beyond the scope of this discussion.
KleinRefrigerator #84
Posted 03 December 2012 - 11:05 AM
I think I see what you're going for. An alternative might be to allow a computer to create a "subnet" of which it becomes the administrator, and then other computers can request to join, subject to approval, and the administrative computer could boot the other clients out. Then broadcasting on this subnet would only go to the currently authorized clients. This should be more secure than using a key because it's not prone to the key being brute-forced (if that's feasible, depends on the specifics of the system) or to the key being revealed mistakenly to the wrong person (which is a common problem with scaling symmetric-key systems, ideally you want a different key for every pair of clients involved.) You'd just need to worry about confirming identity, which you already need to do when exchanging the key in your method.

"imagine your key is a 10 char string, each one is a byte."

Which isn't really a whole 80 bits worth of information, it's closer to 60 bits because of the limitations of character strings. But this is neither here nor there. If someone wants to use real-world computing resources to break into your CC network, they should just log on as you after you log out and go around and do whatever they like inside your base…as you. Defending against that is obviously beyond the scope of this discussion.

Not necessarily, strings in lua are just octet arrays. There's no reason why it only has to be printable characters.

Edit: Further, someone is far more likely to use their personal computer to brute force some encryption inside minecraft than they are to compromise the security of the server, not only because the latter is harder (in terms of what you have to know to do it, not necessarily now long it'll take or how feasible it is), but because it's definitively illegal and has potentially very serious consequences. How to defend against an attacker who has more processing power available than is accessible within the context of CC is not an invalid question, whereas if the server's security is compromised, there's little security to be had in any case, since most things in CC are gonna be sent to and fro in plaintext, regardless of any encryption used within the context of CC.
CoolisTheName007 #85
Posted 03 December 2012 - 11:06 AM
ninja'd
CoolisTheName007 #86
Posted 03 December 2012 - 11:30 AM
snip

The idea is very interesting, but I'm too tired to think about it now. I suppose my first concern is that these subnets break the 4th wall too much, and that…well, see you later.
EDIT: must…reply…my initial idea is to have a key for each network B, and then gateways, controlled by an A ,can link network B to A's network ; that way one can have an administrator, A, and keep key distribution contained.
Sebra #87
Posted 03 December 2012 - 07:24 PM
If you want so complicated system (key distribution etc) do it yourself and for yourself. Other players may have fun to hack it.
Do not force all players to deal with it.
CoolisTheName007 #88
Posted 04 December 2012 - 12:19 AM
snip
Have you even read the post? Or the previous posts? There was a suggestion: rednet frequencies. Then several parts, including Cloudy, pointed out that broadcast had to be replaced, and that frequencies were something to consider. Then I worried about the fact that it would be too much insecure, and proposed, not forced, which is something that, as far as I know, I can not do nor I want to, several ideas to improve security and efficiency, without compromising ease of use (keys, as I said, are optional; if you don't set a key, a default one is used) or realism.

snip
Regarding subnets:
Your idea is worthy of consideration; however, it forces breaking the 4th wall because it implies a no range limit synchronization between members of the network. That isn't such a bad thing, because, IMO, the simplicity and ease of use gained are worth it, but we need to plan it carefully so that this functionality isn't used as a no-range communication method.
This system is very similar, at least from an exterior perspective, to the Wireless Redstone (ChickenBone's or the other, I don't know) permissions system, where there is a range for public frequencies and a range for frequencies that can be claimed.
So I propose the following behavior and implementation ( I use Lua pseudo-code to describe what would have to be done in Java):

data structures:
Listen = a map freq->set of ID's
This data structure keeps track of what each computer wants to listen to;
Members = a map freq->set of ID's
This data structure keeps track of where a computer is authenticated, i.e. what are the members of a freq.
Admins = another map freq->set of ID's; since admins of a freq are already members of it, an upper bound on their number is the number of members.
Each field of these data structures is created on request, and must be deleted if the corresponding set is empty. The order of the indexes freq,id is so that sending messages is faster, instead of being id,freq.
Tracker = a map ID's->{
nMember= number of freq's the ID is a member of;
nListen= number of freq's the ID is listening to;}

constants:
maxListen= the maximum number of frequencies a modem can be listening to; I propose something of order 10 or 100.
maxFreqs= the maximum number of frequencies a modem can be a member of; I propose it is == to maxListen.
These constants are to be used with Tracker, in order to avoid out of memory situations, how unlikely they may be. They impose indirectly a limit on Listen and Members; this all relies on a limit for the number of computers, which IMO can be very, very large and still cause no trouble.
unregister_delay= a time delay between removals of computers from freq's, in order to avoid the use of freq's as an unlimited range communication method. I propose 30 s.


functions:
send(id,msg) –the normal behavior, maybe returning true in case of success to reduce handshaking traffic;

broadcast(msg,freq)
args: freq defaults to 0, which is in the public range, and consequently broadcast(msg) will work as it works now if the targets don't remove 0 from their listening frequencies;
code:
if freq is not in the public range:
   if Members[freq][id]==nil: return false, because the caller is not a member of freq;
iterate over the valid targets according to range, and queue the message to them only if Listen[freq][id]==true;
return true.

I still have to think about these ones; I'll rather like to have some feedback before doing so.
setMember(freq,id,bool)

setListen(freq,id,bool)

setAdmin(freq,id,bool)
ChunLing #89
Posted 04 December 2012 - 07:41 AM
As far as I know we'll still have access to the old version of rednet.send(), which can be considered as being a virtual representation of a completely secure encrypted directional transmission. So it's not hackable by normal means…it's good encryption. You can still get to one of the nodes in a network and reprogram it somehow.

The question is really how to incorporate something like frequencies into the system without breaking all existing code. I would suggest having an extra parameter on the rednet.open(side,clock,frequency), with nil setting to a default frequency (same as clock defaults to 15). That means that you only need to change just one line in most rednet programs if you want to use frequencies, and it still works basically like before if you change nothing. You can still change frequencies and stuff, but it would be easier to just set up several modems on your computer unless you were going for a scanner (and if that was regarded as undesirable, rednet.open could take a tick or two to work…a "proper" scanner would have to be a bunch of computers with modems all over them).

The other question is how to find a way to throttle back on rednet spam from use of broadcast that can't be circumvented by people just using for loops. Having the number of messages sent during the current tick cause "interference" that reduces the rednet range isn't "unrealistic" because of how directional antennae work. And it shouldn't interfere with proper rednet use, messages to a single address should be in packets sent more than a tick apart for max range.
CoolisTheName007 #90
Posted 04 December 2012 - 07:47 AM
snip
I repeat: the functions I proposed conserve the current behavior, introduce public and private frequencies without complicated code ( the functions I left to define aren't complicated), and thus fix the broadcast issue and introduce new, safer functionality for networking.
ChunLing #91
Posted 04 December 2012 - 10:03 AM
Hmmm…I find them a bit over intrusive compared to just adding an extra argument to rednet.open.
Cloudy #92
Posted 04 December 2012 - 11:25 AM
We were thinking that by default every computer listens on its own frequency. You'll be able to change that by doing rednet.listenFreq(blah). Or something.
CoolisTheName007 #93
Posted 04 December 2012 - 11:33 AM
Hmmm…I find them a bit over intrusive compared to just adding an extra argument to rednet.open.
The fact is, that, as you noted, the broadcast spamming isn't solved by simply allowing frequencies.
You propose a solution that would solve that problem, by limiting the number of messages per tick; however, that means that all the legit uses for high rate of transmission will be affected.
Also, limiting one modem to one frequency…well, I must admit that that part wouldn't be a limitation for networks, since one can use more modems, and that is possibly something to consider. IMO, modems should be able to listen to several frequencies; if you allow frequencies to be strings of a certain size, then using strings of length 10 automatically stops anyone from listening to all frequencies (it would take milleniums to request to listen to all of them).

I first thought of allowing broadcast(freq,msg,key), and then I noticed that could be simplified to broadcast(freq,msg) if freq can be an arbitrary number (inside Lua's capabilities) or in general something that can have so many values that finding the frequency you want to spam would be very unlikely.

However, as @KleinRefrigerator (does putting @ in front of an username does anything here?) noted, it is not a good system in the sense that once an attacker finds the right freq / pattern that you are using (Cloudy suggested switching patterns over time, for instance; I can elaborate on why that is almost the same as using a fixed freq), much likely because of human error/betrayal, you would have to change the freq in each of you network's computers.
That can be a pain if you don't have an update procedure built-in in your system, so things quickly get complicated in case of a breach.
So, he proposed an hidden authentication system in the Java side, in which freq's can have admins that add members to the frequencies, MC-world-wide, no range restrictions. Then a message sent through a freq only gets to it's destination (that has to be in range) if the freq is a public one, or if the freq is private and the destination is a member of that freq.
CoolisTheName007 #94
Posted 04 December 2012 - 11:40 AM
snip
That seems okay if you allow freq's to be quite a lot of things; since numbers in Lua are double's, which are 64 bits, I don't think they are secure enough I think that 5 milleniums of computation to get there are enough. Maybe strings of fixed length? Then again you could improve it with Java-side cod for admins and private freq's (together with public); it's much safer, avoids the need for encryption, and simpler to use for networks, but would imply breaking the 4th wall. A balance thing.
ChunLing #95
Posted 04 December 2012 - 04:07 PM
Wait, are we saying that rednet.send(id,message) would become insecure to the extent of anyone being able to listen in on a message by spoofing the frequency? It doesn't take 5,000 years to guess a floating point number. It just doesn't.
Sebra #96
Posted 04 December 2012 - 07:18 PM
Have you even read the post? Or the previous posts? There was a suggestion: rednet frequencies. Then several parts,
including Cloudy, pointed out that broadcast had to be replaced, and that frequencies were something to consider. Then I worried about the fact that it would be too much insecure, and proposed, not forced, which is something that, as far as I know, I can not do nor I want to, several ideas to improve security and efficiency, without compromising ease of use (keys, as I said, are optional; if you don't set a key, a default one is used) or realism.
I read. Frequencies are iffy. But you suggest administration and encryption also, and it is bad.
The question is really how to incorporate something like frequencies into the system without breaking all existing code. I would suggest having an extra parameter on the rednet.open(side,clock,frequency), with nil setting to a default frequency (same as clock defaults to 15).
We were thinking that by default every computer listens on its own frequency. You'll be able to change that by doing rednet.listenFreq(blah). Or something.
No! Should not be frequencies in the rednet. Leave it to Modems only! Rednet is a layer of communication, able to use different ways. Bundled Cables and Modems currently. Allow other peripherals and implement channels or frequencies into Modem peripheral.
If you want administration or cryptography, do it above rednet, not below.
The other question is how to find a way to throttle back on rednet spam from use of broadcast that can't be circumvented by people just using for loops. Having the number of messages sent during the current tick cause "interference" that reduces the rednet range isn't "unrealistic" because of how directional antennae work. And it shouldn't interfere with proper rednet use, messages to a single address should be in packets sent more than a tick apart for max range.
Not the rednet spam, but Modem spam! Make Modem range backwards proportional to "frequency diapason width". This will mean Modems spamming on all frequencies would have almost no range. Modems, tuned to use one channel only, will have fairly far full range. Of course two and more Modems (or other rednet peripheral) per Computer quite possible.
ChunLing #97
Posted 04 December 2012 - 08:20 PM
I guess that's a valid point, we're really talking only about wireless, which is particularly important considering upcoming support for lan cables. So I guess we do need at least one new method for modems to set their frequency rather than changing anything else.
Sebra #98
Posted 04 December 2012 - 08:55 PM
I am heard. At last. Thanks.
Cloudy #99
Posted 04 December 2012 - 11:39 PM
Setting frequencies on cables would do nothing. Do you think I'm stupid?
Tiin57 #100
Posted 05 December 2012 - 12:52 AM
Setting frequencies on cables would do nothing. Do you think I'm stupid?
No one thinks you're stupid. Some people don't think before suggesting. :P/>
Sebra #101
Posted 05 December 2012 - 02:59 AM
So you mean I did not think? You wrong.

Setting frequencies on cables would do nothing. Do you think I'm stupid?
I think you are able to make wrong decision to implement frequencies into rednet instead of into Modems. This opinion was based on your words "rednet.listenFreq(blah)". The difference is important when you allow other rednet peripherals. LAN Cables for example fit rednet very well but do not need frequencies. Some other peripheral can have other options you cannot predict. So lets Modems have frequencies, not all peripherals.
Also if you have more than one modem attached you would want tune them for different frequencies. That also show you rednet should not be involved.
Cloudy #102
Posted 05 December 2012 - 03:04 AM
So you mean I did not think? You wrong.

Setting frequencies on cables would do nothing. Do you think I'm stupid?
I think you are able to make wrong decision to implement frequencies into rednet instead of into Modems. This opinion was based on your words "rednet.listenFreq(blah)". The difference is important when you allow other rednet peripherals. LAN Cables for example fit rednet very well but do not need frequencies. Some other peripheral can have other options you cannot predict. So lets Modems have frequencies, not all peripherals.

I'm not going to have a manual setting on modems not accessible through the rednet API. If anyone else is identifying themselves as "modem" to utilise the rednet API they'll have to adapt or crash user programs.
Sebra #103
Posted 05 December 2012 - 03:17 AM
Make it optional parameters for "open" method. So program can rednet.open("right") or rednet.open("right", 100, 200). API should only translate optional parameters to peripheral. Only peripheral should know what this optional parameters mean. For example some interdimensional modem can take target dimension name or code. Interworlds modem can take ip address of another MC server. Rednet itself do not need to know exact details of data traveling. It should not know about frequencies.
Cloudy #104
Posted 05 December 2012 - 03:37 AM
Make it optional parameters for "open" method. So program can rednet.open("right") or rednet.open("right", 100, 200). API should only translate optional parameters to peripheral. Only peripheral should know what this optional parameters mean. For example some interdimensional modem can take target dimension name or code. Interworlds modem can take ip address of another MC server. Rednet itself do not need to know exact details of data traveling. It should not know about frequencies.

Sorry, but no. Having it in open would be unintuitive and wouldn't make much sense.

What's the big deal? It will be a function that if you don't use it, you don't call it.
Sebra #105
Posted 05 December 2012 - 06:11 AM
Big deal? Just different abstraction levels. Frequencies have sense for Modem only and Modem is only one of possible rednet peripherals. If you would be wise enough to allow others. For now rednet API is an interface to Modem peripheral and Bundled Cables. It kind of forced to have support for Bundled Cables internal behavior but have no internal info about Modems. The more details about modems you place into rednet, the harder would be other peripherals integration. Now to add LAN cables to rednet you need to remove check for "modem" only. If you place some frequency functions in that API, other peripherals will need some stubs for it. It is counterproductive.
Cloudy #106
Posted 05 December 2012 - 06:43 AM
Big deal? Just different abstraction levels. Frequencies have sense for Modem only and Modem is only one of possible rednet peripherals. If you would be wise enough to allow others. For now rednet API is an interface to Modem peripheral and Bundled Cables. It kind of forced to have support for Bundled Cables internal behavior but have no internal info about Modems. The more details about modems you place into rednet, the harder would be other peripherals integration. Now to add LAN cables to rednet you need to remove check for "modem" only. If you place some frequency functions in that API, other peripherals will need some stubs for it. It is counterproductive.

This argument is stupid. If one more function is added to a modem and then rednet, and this causes peripheral authors troubles then they probably shouldn't be coding peripherals. If you're also altering rednet to allow for other modem types then that's something you'll have to contend with yourself.

Anyway rather than carrying this on further I'll state that we haven't even started it yet, we don't have an inplementation on how it would work or anything but we will most likely involve the community on IRC for feedback.
CoolisTheName007 #107
Posted 05 December 2012 - 07:56 AM
Have you even read the post? Or the previous posts? There was a suggestion: rednet frequencies. Then several parts,
including Cloudy, pointed out that broadcast had to be replaced, and that frequencies were something to consider. Then I worried about the fact that it would be too much insecure, and proposed, not forced, which is something that, as far as I know, I can not do nor I want to, several ideas to improve security and efficiency, without compromising ease of use (keys, as I said, are optional; if you don't set a key, a default one is used) or realism.
I read. Frequencies are iffy. But you suggest administration and encryption also, and it is bad.
It's not much like encryption, it's more like authentication, so there's no need for complicated algorithms or extra effort of the user, since it maintains rednet current functions and relieves the user of worrying about grieffing by hacking; if you mean it's bad for other reasons, please tell me which, I would like the feedback.
Instead of relying on no-one else listening to your frequency, you would be able to either:
-1st idea: set a key that would have to match the target's key in order for the message to pass; then again , they could guess the key, what makes this idea useless, so:
-2nd idea: you would be able to claim a private frequency, and set admin computers for those frequencies. This is the ideal solution in which no griefing will come of invading/spamming networks, but, as I noted, it does involve infinite range operations when configuring the network.
ChunLing #108
Posted 05 December 2012 - 10:09 AM
I feel like I've lost track of this discussion.
PixelToast #109
Posted 05 December 2012 - 01:52 PM
I feel like I've lost track of this discussion.
yea .-.
people dont understand that this is easialy securable ( to the point that it is impractical to crack )
as long as rednet.receive returns a computer id you can prevent MiM (faking ids)
CoolisTheName007 #110
Posted 05 December 2012 - 02:35 PM
snip
There's a difference between impractical and impossible; I usually like to play really safe.
PixelToast #111
Posted 05 December 2012 - 03:55 PM
snip
There's a difference between impractical and impossible; I usually like to play really safe.
by impractial i mean having a brute force program take an entire day to decrypt a single exchange
and by then your target computer could have made a hundred connections

seriously, you have better chances of brute forcing the servers FTP .-.
JJRcop #112
Posted 05 December 2012 - 07:03 PM
What PixelToast said. This is very terrible to even think about cracking. You can even use encryption and give keys to your friends. So if they do invest enough time to crack the frequency, you could send an encrypted message telling your friend's computer "we've been jacked, go to this frequency".

Listen, this mod is very OP right now. And I am very very happy that the developers are toning it down by implementing things like this. Please don't complain about that.

EDIT: I didn't realize that PixelToast was talking about encryption in his post, which is your second line of defense after an attacker spend a millennium trying to find what frequency you're using. I was talking about the frequency thing in general, sorry!
PixelToast #113
Posted 05 December 2012 - 07:13 PM
What PixelToast said. This is very terrible to even think about cracking. You can even use encryption and give keys to your friends. So if they do invest enough time to crack the frequency, you could send an encrypted message telling your friend's computer "we've been jacked, go to this frequency".

Listen, this mod is very OP right now. And I am very very happy that the developers are toning it down by implementing things like this. Please don't complain about that.
i wasnt talking about the symetric keys, i was talking about the method that uses public keys to create a shared key wich can then be converted on both sides into a shared key that can be fed into a symetric key encryptor

this is the method still used today for insecure networks
JJRcop #114
Posted 05 December 2012 - 07:28 PM
i wasnt talking about the symetric keys, i was talking about the method that uses public keys to create a shared key wich can then be converted on both sides into a shared key that can be fed into a symetric key encryptor

this is the method still used today for insecure networks
Cool! That is even easier! Now, I can continue the big long discussion/argument about encryption, but I'm not going to do that.
When I said "Please don't complain about that." I meant with the complaining about rednet turning frequency-based.

EDIT: Sorry Pixel, I didn't know you were talking about encryption!
Sebra #115
Posted 05 December 2012 - 07:34 PM
@CoolisTheName007 I like rednet and modems as is and do not want complication.
as long as rednet.receive returns a computer id you can prevent MiM (faking ids)
and as soon as it lost sender id it mostly broken
I feel like I've lost track of this discussion.
I got my answer :(/>
But some people discuss encryption instead of frequencies.
PixelToast #116
Posted 05 December 2012 - 07:44 PM
But some people discuss encryption instead of frequencies.
because everyone is complaining about their programs being insecure .-.
cloudhunter said it will be implemented (and hopefully optional) so there is no need to discuss the actual frequencies themselves

you can report the thread and request it be locked and someone can make a new thread that is centered on encryption
JJRcop #117
Posted 05 December 2012 - 07:54 PM
(and hopefully optional)
I personally hope it isn't optional.
The debate is, some people want it optional, some people don't want it optional, and some people don't want it at all.
That's why we're still talking about it.
Sebra #118
Posted 05 December 2012 - 07:56 PM
Everyone loud enough? ;)/> Most people do not care about it (afaik)
Encryption can be made above rednet, as a program or API. You can do it for yourself.
Frequencies should be a property of Modem, so below rednet (even if controlled through rednet API).
I personally hope it isn't optional.
That is worse because you want to force others.
CoolisTheName007 #119
Posted 06 December 2012 - 07:38 AM
To clarify: I'm not complaining, forcing, ect. I would like frequencies implemented, and since we are here, why not to improve it with more security/ ease of use? That doesn't means it will be more OP: examples of OP'ness by rednet anyone? I'm just calmly debating, so please stop with the drama.
Ahrum, I'm not talking about encryption, I'm talking about secure networks, by either using bare frequencies, or, and here's something I forgot to mention and that KleinRefrigerator has the credit for: even if you have a frequency that is 1 billion bits long, all it takes for having to change the frequency of the entire network is an attacker obtaining the key; that is becomes more and more likely as more people join your network, e.g.suddenly you have an entire town hooked up (chat programs ect.), and you probably ain't close friends with everybody, and then one of them betrays the whole system and you have to change the frequency in the whole network. And it isn't that simple to change freq's in an entire network automatically. I have considered several situations and simple encrypted communication by send(id,msg) is not enough; you'll have to account for computers which are offline and need to be contacted later, or computers currently out of range, and, most importantly, you'll have to sync the changes over the entire network, or suddenly you won't be able to reach everyone. If you have something like a network floppy to configure computers, you will have to change that too.
Dlcruz129 #120
Posted 13 December 2012 - 04:19 AM
Everyone stop fighting. This is a great idea and I don't want it to be locked.
PixelToast #121
Posted 13 December 2012 - 04:26 AM
-snippy-
why does the ENTIRE network have to use the same, unsecured channel?
just make secure connections to every client, and now even if an attacker has the frequency they wont be able to do anything
if done correctly it can run seamlessly with the rednet api
CoolisTheName007 #122
Posted 13 December 2012 - 05:35 AM
-snippy-
why does the ENTIRE network have to use the same, unsecured channel?
Because it needs to broadcast in order to detect it's peers; and they only use it to broadcast, other transmissions are dealt with the secure send(id,msg) and it is due to that broadcast that a new member validates itself. Static, manual setup networks don't need frequencies obviously; I and others are referring to dynamic networks.
just make secure connections to every client, and now even if an attacker has the frequency they wont be able to do anything
They will be able to detect packets sent by the network during broadcast cycles, and work their way to fake themselves as a valid member. If you use encryption/frequencies, the transmission of keys/frequencies id's over a large group of users ends up being insecure. I do realize that partitioning the network into different frequencies could lead to a secure setup, however it puts a halt to simple one-frequency town networks. Also, I am trying to avoid whitlelists, because of the syncronization problem they pose.
if done correctly it can run seamlessly with the rednet api
Even if you ignore networks' needs, the original api, as Cloudy stated, needs some replacement for broadcast; I now realize I never read the reason for it, but I assume it is to reduce the number of computers waked up unnecessarily by broadcasts.
PixelToast #123
Posted 13 December 2012 - 06:44 AM
Because it needs to broadcast in order to detect it's peers; and they only use it to broadcast, other transmissions are dealt with the secure send(id,msg) and it is due to that broadcast that a new member validates itself. Static, manual setup networks don't need frequencies obviously; I and others are referring to dynamic networks.
as long as rednet.receive() returns an actual id you can ensure it is valid
in that case MiM is impossible (or atleast preventable)
the transmission of keys/frequencies id's over a large group of users ends up being insecure.
again, if you use the method i said before you dont actually broadcast a key
you agree on a random prime and primitive root then you can use an symetric key algorithm to encrypt the message
it is completely secure, and the attacker will have to brute force it
CoolisTheName007 #124
Posted 13 December 2012 - 07:12 AM
Because it needs to broadcast in order to detect it's peers; and they only use it to broadcast, other transmissions are dealt with the secure send(id,msg) and it is due to that broadcast that a new member validates itself. Static, manual setup networks don't need frequencies obviously; I and others are referring to dynamic networks.
as long as rednet.receive() returns an actual id you can ensure it is valid
Only if I have a whitelist explicitly telling me which id's are valid for the network. If I want to add computers to the whitelist on the go, I must deal with the problems of synchronizing a whitelist over an entire network.
in that case MiM is impossible (or atleast preventable)
the transmission of keys/frequencies id's over a large group of users ends up being insecure.
again, if you use the method i said before you dont actually broadcast a key
you agree on a random prime and primitive root then you can use an symetric key algorithm to encrypt the message
it is completely secure, and the attacker will have to brute force it
The problem lies with the Steve side of sharing the key with many users; I'm talking of treason or something like that, which is likely if you start a big network. It isn't broadcasted. If an OS is furnished with the purpose of storing the key away from the user, it could work.
PixelToast #125
Posted 13 December 2012 - 07:35 AM
Only if I have a whitelist explicitly telling me which id's are valid for the network. If I want to add computers to the whitelist on the go, I must deal with the problems of synchronizing a whitelist over an entire network.
didnt you have to do that anyway .-. i am confused
the way i have my network set up is there is a global host password that you need to enter in order to be added to the closest host
the already existing host will then send its list of hosts, and then every host in that list (that is in range) will be added to the new host list

the problem with this is that you will have to keep your password a secret , and if your friend leaks the password to someone untrustworthy then you will be prone to MiM attacks

The problem lies with the Steve side of sharing the key with many users; I'm talking of treason or something like that, which is likely if you start a big network. It isn't broadcasted. If an OS is furnished with the purpose of storing the key away from the user, it could work.
im not talking about generating a key for the entire network, i mean a key that only one client and one server will know
it dosent matter if the client knows it because it will only work for decrypting messages directed towards the client
CoolisTheName007 #126
Posted 13 December 2012 - 12:16 PM
snip

I don't want whitelists like those, because they require human intervention each time the network changes; also, I want to keep lengthy encryption computations to a minimum. I'm thinking a local whitelist plus a header specifying that a msg is a broadcast to allow new members to join in. However, that msg must also validate the new member as safe, and if the msg is really independent of time and most network state, that is impossible, because an attacker can just copy it, wait for the new member to turn off and then fake it's way through by repeating the same message. So I suppose I will have to involve the sender's id somewhere in the msg, because that's one of the things rednet has, unique identifiers, and that may solve this.
EDIT: encode the new member M id in the message with a pre-shared key K; host decrypts the message and checks if decoded id matches the id given by the rednet event 1st parameter; attacker C though he has the message and M's id, won't be able to send a valid message because it would need to know K to encode it's id.
By buffering the encoded sequences, one can avoid virtually all encryption computations.
I'm not an expert in encryption, but I guess that deterministically assigning id's, plus in an ordered fashion, like it is done now, e.g. 1,2,3,… it's a killer for this idea.
Any reason it has to be this way?

EDIT:
I guess that mapping id's to some reasonably sized string in a bijective way would be enough.
Also, to ensure that the host is valid, one could send a random password encrypted in the message, and expect receiving back a transformation of it.
PixelToast #127
Posted 13 December 2012 - 02:43 PM
snip

I don't want whitelists like those, because they require human intervention each time the network changes; also, I want to keep lengthy encryption computations to a minimum. I'm thinking a local whitelist plus a header specifying that a msg is a broadcast to allow new members to join in. However, that msg must also validate the new member as safe, and if the msg is really independent of time and most network state, that is impossible, because an attacker can just copy it, wait for the new member to turn off and then fake it's way through by repeating the same message. So I suppose I will have to involve the sender's id somewhere in the msg, because that's one of the things rednet has, unique identifiers, and that may solve this.
EDIT: encode the new member M id in the message with a pre-shared key K; host decrypts the message and checks if decoded id matches the id given by the rednet event 1st parameter; attacker C though he has the message and M's id, won't be able to send a valid message because it would need to know K to encode it's id.
By buffering the encoded sequences, one can avoid virtually all encryption computations.
I'm not an expert in encryption, but I guess that deterministically assigning id's, plus in an ordered fashion, like it is done now, e.g. 1,2,3,… it's a killer for this idea.
Any reason it has to be this way?
encryption is not lengthy and not that hard to implement

also, your talking about a symmetric key algorithm
the method i was talking about was creating a key to feed into one of those algorithms
so the client dosent have to know a password in order to connect

i dont get why you would include your own id in your message, its unnecessary
the attacker wont be able to figure out the password just from listening nor can he fake his id
CoolisTheName007 #128
Posted 14 December 2012 - 03:15 AM
encryption is not lengthy and not that hard to implement
The less is it is needed the better; I don't want to encrypt every message, only authentication ones.

also, your talking about a symmetric key algorithm
No, it may ressemble one, but the idea is to use it together with rednet id's to ensure a safe authentication.
the method i was talking about was creating a key to feed into one of those algorithms
so the client dosent have to know a password in order to connect
My problem is to have a computer authenticate itself to a network, using only a network shared key.
Quoting a previous post:
the way i have my network set up is there is a global host password that you need to enter in order to be added to the closest host
the already existing host will then send its list of hosts, and then every host in that list (that is in range) will be added to the new host list
Your client seems to need to know the host id, otherwise it would have to broadcast it and then the password would be known to anyone listening.
In my case, the client must auto-detect in-range hosts (that's dynamic networking), and that's why it has to broadcast in order to detect them, and then both parties must ensure their partner is valid. I left out the part where the client checked if the host was valid; a possible solution would be having the client encode a random password on the fly, and expecting to get back a transformation of the pasword.
PixelToast #129
Posted 14 December 2012 - 04:27 AM
The less is it is needed the better; I don't want to encrypt every message, only authentication ones.
why wouldn't you want to encrypt every single message, encryption isnt that hard nor does it lag ffs

No, it may ressemble one, but the idea is to use it together with rednet id's to ensure a safe authentication.
its still symetric key encryption because it has a single private key
adding your id dosent make the connection any more secure if rednet.receive returns an id then it does not need authentication
My problem is to have a computer authenticate itself to a network, using only a network shared key.
-snip-
im researching ways to ensure two hosts have the same password without them leaking the password itself
elliptic curves sound nice c:

and for efficiency
only make the host authenticate the closest valid host in range
then the old host will send its list of hosts over to the new one
and every host on that list that is in range will be added to the new hosts list
CoolisTheName007 #130
Posted 14 December 2012 - 05:08 AM
The less is it is needed the better; I don't want to encrypt every message, only authentication ones.
why wouldn't you want to encrypt every single message, encryption isnt that hard nor does it lag ffs
It depends on how big your network is and what kind of traffic you'll have. I know it isn't hard, because I know some algorithms myself, in addition to various encryption tools already coded for CC.
No, it may ressemble one, but the idea is to use it together with rednet id's to ensure a safe authentication.
its still symetric key encryption because it has a single private key
adding your id dosent make the connection any more secure if rednet.receive returns an id then it does not need authentication
Yes, it does, how would you distinguish between a valid authentication message sent by valid computer B and the same message sent by malicious computer C?
My problem is to have a computer authenticate itself to a network, using only a network shared key.
-snip-
im researching ways to ensure two hosts have the same password without them leaking the password itself
elliptic curves sound nice c:

and for efficiency
only make the host authenticate the closest valid host in range
then the old host will send its list of hosts over to the new one
and every host on that list that is in range will be added to the new hosts list
Won't work for a host that is in range of two disjoint parts of the network.
PixelToast #131
Posted 14 December 2012 - 05:36 AM
It depends on how big your network is and what kind of traffic you'll have. I know it isn't hard, because I know some algorithms myself, in addition to various encryption tools already coded for CC.
then use a light weight encryption algorithm, or optimize it with pre generated tables
Yes, it does, how would you distinguish between a valid authentication message sent by valid computer B and the same message sent by malicious computer C?
what you want is to xor your mac address and a key together and combine it with the message, not just include your own id to the message, its a bit complicated and is only neccicary if you are trying to prevent the message from being tampered while going across the network itself
Won't work for a host that is in range of two disjoint parts of the network.
then auth every id you detected that wasnt on the list the old host sent
or just dont make disjointed networks at all
BigSHinyToys #132
Posted 14 December 2012 - 07:41 AM
It depends on how big your network is and what kind of traffic you'll have. I know it isn't hard, because I know some algorithms myself, in addition to various encryption tools already coded for CC.
then use a light weight encryption algorithm, or optimize it with pre generated tables
If you can make a light weight encryption system capable of terminal redirection and playing "star wars" without shudder I would like to see it.
PixelToast #133
Posted 14 December 2012 - 07:42 AM
It depends on how big your network is and what kind of traffic you'll have. I know it isn't hard, because I know some algorithms myself, in addition to various encryption tools already coded for CC.
then use a light weight encryption algorithm, or optimize it with pre generated tables
If you can make a light weight encryption system capable of terminal redirection and playing "star wars" without shudder I would like to see it.
ok :3
CoolisTheName007 #134
Posted 14 December 2012 - 07:44 AM
or just dont make disjointed networks at all
lol, of course I want to be able to merge disjoint networks! e.g. a middle node goes offline and then restarts.
What I just realized is that I could not put the id in the messages, but then an attacker could repeat the broadcasts from the network. It wouldn't be able to change the message, and consequently the network could detect it was not a valid computer after some time, but by including the encrypted id I guarantee total safety.
I am only talking about using encryption for authentication, in-network messages go around without encryption.
Now on to coding!
PixelToast #135
Posted 14 December 2012 - 08:02 AM
or just dont make disjointed networks at all
lol, of course I want to be able to merge disjoint networks! e.g. a middle node goes offline and then restarts.
What I just realized is that I could not put the id in the messages, but then an attacker could repeat the broadcasts from the network. It wouldn't be able to change the message, and consequently the network could detect it was not a valid computer after some time, but by including the encrypted id I guarantee total safety.
I am only talking about using encryption for authentication, in-network messages go around without encryption.
Now on to coding!
if the attacker had the password to the network, and was added to nearby host's host list you can just take a users id and create a fake message from that
however you can prevent tampering as long as you securely transfer a password
if the attacker gets a hold of that password then you are prone to tampering

EDIT:
host to host connections will work the same as host to client connections
if you want you can layer encryption by resetting the connections password every time data is transfered
meaning you will have to crack every single previous password before getting to the current one
CoolisTheName007 #136
Posted 14 December 2012 - 08:19 AM
if the attacker had the password to the network, and was added to nearby host's host list you can just take a users id and create a fake message from that
That's not what an attacker would have to do; it would have to get the key==password and encode it's own id in it, exactly like if it was running the normal protocol.
An attacker who gets the pass certainly can break everything, as in all systems; but I plan on subdividing the network in regions with different keys for authentication, and possibly a password for each pair of id's in delicate situations, such as gateways to public networks.
When I said a client connecting, I really meant a new host/ new client.
Tiin57 #137
Posted 15 December 2012 - 02:24 AM
I cannot tell how far off topic this has gone.
PixelToast #138
Posted 15 December 2012 - 03:36 AM
I cannot tell how far off topic this has gone.
:s i know