137 replies to this topic

[JJRcop]

I don't know if bumping is allowed, but I want to bring more attention to this from the forum community.

[Cloudy]

Already planned, and no bumping isn't allowed />

[billysback]

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]

billysback, on 19 November 2012 - 11:52 AM, said:

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]

immibis, on 14 September 2012 - 11:21 AM, said:

kamnxt, on 14 September 2012 - 11:19 AM, said:

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]

Cloudy, on 19 November 2012 - 12:36 PM, said:

billysback, on 19 November 2012 - 11:52 AM, said:

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]

Cloudy, on 19 November 2012 - 12:36 PM, said:

billysback, on 19 November 2012 - 11:52 AM, said:

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. SPAMMER!

[Tiin57]

dlcruz129, on 29 November 2012 - 06:38 PM, said:

-snip-
The funny thing is that was a one-word post. SPAMMER!

You bumped it.
Which allowed me to show my appreciation of this idea.

[KillaVanilla]

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]

.-.
this is scary
whatever, ill make some sort of protocol to authenticate a two way connection
cryptography ftw

[KaoS]

there is no way of securing this without denying access to the normal rednet function or anyone can mimic whatever you do

[PixelToast]

KaoS, on 30 November 2012 - 03:53 AM, said:

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]

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]

KaoS, on 30 November 2012 - 04:58 AM, said:

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]

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]

GopherAtl, on 30 November 2012 - 05:13 AM, said:

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]

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]

Yeah, I don't like that iea. Making it have an additional argument at the end would make much more sense

[PixelToast]

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]

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.