example code
rednet.send ("msg, 351")
rednet.open ("top, 351")
rednet.set ("423")
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")
rednet.send(3, "msg")
rednet.set( 512 )
and mabye this will start hackers acually hacking instead of making a 3 line virusI 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.
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.and mabye this will start hackers acually hacking instead of making a 3 line virusI 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.
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 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 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.
Please tell me you're joking.secure it! ROT13, base64…
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.and mabye this will start hackers acually hacking instead of making a 3 line virusI 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.
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.
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)
Well I don't wanna keep going on this thread, but I just HAVE to say that this remark is brilliant. :(/>/>Please tell me you're joking.secure it! ROT13, base64…
wait, nvm what I said, I thought you said bumps are allowed, because I thought they were o.obut 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?
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?
You bumped it.-snip-
The funny thing is that was a one-word post. :P/> SPAMMER!
http://en.wikipedia....an_key_exchangethere is no way of securing this without denying access to the normal rednet function or anyone can mimic whatever you do
not sure if there is a way to authenticate ids :sbut 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
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.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 already used frequency 0 to negotiate a random frequency to use with other clientBroadcast 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?Broadcast will probably die. It is horribly misused anyway.
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
I see wut u did thar….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..)
my idea is that it would just run on the default frequency of 0I see wut u did thar….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..)
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.
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.my idea is that it would just run on the default frequency of 0
and not on all
my idea is that it would just run on the default frequency of 0
and not on all
not using my method above ^.^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-
problems with trust. -> less fun
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
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 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.
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.
1.War is reason for most inventions, but still very bad thing.Or perhaps it will shift the attention to creative confrontation.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.
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?
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?
local function broadcast(message)
for i = 1,channels do
rednet.send(i,message)
end
end
… and even before broadcast is removed it is bypassed.This would limit speed in transmissions, not sure if it would be enough for networks or terminal redirection.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
and thats why you need frequenciesWhat 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.
What is wrong with broadcast?
j=tonumber(...)
s=0
for i=1,j-1 do
s=s+i/(j-i)
end
print(s)
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!snip
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.
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.snip
"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.
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:snip
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 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.snip
The fact is, that, as you noted, the broadcast spamming isn't solved by simply allowing frequencies.Hmmm…I find them a bit over intrusive compared to just adding an extra argument to rednet.open.
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,snip
I read. Frequencies are iffy. But you suggest administration and encryption also, and it is bad.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.
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).
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.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.
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.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.
No one thinks you're stupid. Some people don't think before suggesting. :P/>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.Setting frequencies on cables would do nothing. Do you think I'm stupid?
So you mean I did not think? You wrong.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.Setting frequencies on cables would do nothing. Do you think I'm stupid?
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.
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.
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.I read. Frequencies are iffy. But you suggest administration and encryption also, and it is bad.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.
yea .-.I feel like I've lost track of this discussion.
There's a difference between impractical and impossible; I usually like to play really safe.snip
by impractial i mean having a brute force program take an entire day to decrypt a single exchangeThere's a difference between impractical and impossible; I usually like to play really safe.snip
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 encryptorWhat 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.
Cool! That is even easier! Now, I can continue the big long discussion/argument about encryption, but I'm not going to do 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
and as soon as it lost sender id it mostly brokenas long as rednet.receive returns a computer id you can prevent MiM (faking ids)
I got my answer :(/>I feel like I've lost track of this discussion.
because everyone is complaining about their programs being insecure .-.But some people discuss encryption instead of frequencies.
I personally hope it isn't optional.(and hopefully optional)
That is worse because you want to force others.I personally hope it isn't optional.
why does the ENTIRE network have to use the same, unsecured channel?-snippy-
why does the ENTIRE network have to use the same, unsecured channel?-snippy-
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.
as long as rednet.receive() returns an actual id you can ensure it is validBecause 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.
again, if you use the method i said before you dont actually broadcast a keythe transmission of keys/frequencies id's over a large group of users ends up being insecure.
as long as rednet.receive() returns an actual id you can ensure it is validBecause 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.
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)again, if you use the method i said before you dont actually broadcast a keythe transmission of keys/frequencies id's over a large group of users ends up being insecure.
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.
didnt you have to do that anyway .-. i am confusedOnly 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.
im not talking about generating a key for the entire network, i mean a key that only one client and one server will knowThe 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.
snip
encryption is not lengthy and not that hard to implementsnip
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
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.
why wouldn't you want to encrypt every single message, encryption isnt that hard nor does it lag ffsThe less is it is needed the better; I don't want to encrypt every message, only authentication ones.
its still symetric key encryption because it has a single private keyNo, it may ressemble one, but the idea is to use it together with rednet id's to ensure a safe authentication.
im researching ways to ensure two hosts have the same password without them leaking the password itselfMy problem is to have a computer authenticate itself to a network, using only a network shared key.
-snip-
why wouldn't you want to encrypt every single message, encryption isnt that hard nor does it lag ffsThe less is it is needed the better; I don't want to encrypt every message, only authentication ones.
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.its still symetric key encryption because it has a single private keyNo, it may ressemble one, but the idea is to use it together with rednet id's to ensure a safe authentication.
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?im researching ways to ensure two hosts have the same password without them leaking the password itselfMy problem is to have a computer authenticate itself to a network, using only a network shared key.
-snip-
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.
then use a light weight encryption algorithm, or optimize it with pre generated tablesIt 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.
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 itselfYes, 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?
then auth every id you detected that wasnt on the list the old host sentWon't work for a host that is in range of two disjoint parts of the network.
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.then use a light weight encryption algorithm, or optimize it with pre generated tablesIt 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.
ok :3If you can make a light weight encryption system capable of terminal redirection and playing "star wars" without shudder I would like to see it.then use a light weight encryption algorithm, or optimize it with pre generated tablesIt 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.
lol, of course I want to be able to merge disjoint networks! e.g. a middle node goes offline and then restarts.or just dont make disjointed networks at all
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 thatlol, of course I want to be able to merge disjoint networks! e.g. a middle node goes offline and then restarts.or just dont make disjointed networks at all
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!
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.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
:s i knowI cannot tell how far off topic this has gone.