tec_SG, on 05 November 2014 - 07:31 PM, said:
Cauldron server
3
104 replies to this topic
#101
-
- Moderators
-
- 7,332 posts
Semi-Professional ComputerCrafter
- LocationAustralia
Posted 05 November 2014 - 11:29 PM
this could be 99% of the problem right here with the older versions.
#102
-
- Members
- 10 posts
Posted 07 November 2014 - 07:59 PM
theoriginalbit, on 05 November 2014 - 11:29 PM, said:
tec_SG, on 05 November 2014 - 07:31 PM, said:
Cauldron server
I confirmed that it saves the state of the pc on cc 1.65 +cauldron, just as he said the latest version does not have that bug so neither do I.
#103
-
- Moderators
-
- 8,465 posts
Lua Liquidator
Posted 11 December 2014 - 05:49 PM
I've added a couple new features.
Back when LyqydNet was first created, there were only wireless modems. Thus, LyqydNet as designed for only a single modem per computer--there was no need for additional modems. I've just added interface (side) information to the routing tables stored by LyqydNet, as well as enabling support for more than one modem per computer. The system will automatically select the best modem to send a message to a known host. Routers with more than one modem can route messages between networks. You could, for instance, have a wired network in your base and use wireless routers to link to a distant base. Non-router computers that are on two different networks will not repeat packets originating in one network on the other.
The second feature is support for some of the newer rednet networking concepts. LyqydNet routers will now act as if they are running the default "repeat" program as well as routing messages as normal. With the rednet API overrides included in LyqydNet, rednet messages to known hosts will be routed with the less chatty LyqydNet routing, while unknown or non-LyqydNet hosts will be reached via the default rednet repeating methodology. I also plan on implementing the rednet style DNS lookup functionality soon.
As usual, if you find any issues, feel free to post them here or on the github repo!
Back when LyqydNet was first created, there were only wireless modems. Thus, LyqydNet as designed for only a single modem per computer--there was no need for additional modems. I've just added interface (side) information to the routing tables stored by LyqydNet, as well as enabling support for more than one modem per computer. The system will automatically select the best modem to send a message to a known host. Routers with more than one modem can route messages between networks. You could, for instance, have a wired network in your base and use wireless routers to link to a distant base. Non-router computers that are on two different networks will not repeat packets originating in one network on the other.
The second feature is support for some of the newer rednet networking concepts. LyqydNet routers will now act as if they are running the default "repeat" program as well as routing messages as normal. With the rednet API overrides included in LyqydNet, rednet messages to known hosts will be routed with the less chatty LyqydNet routing, while unknown or non-LyqydNet hosts will be reached via the default rednet repeating methodology. I also plan on implementing the rednet style DNS lookup functionality soon.
As usual, if you find any issues, feel free to post them here or on the github repo!
#104
-
- Members
- 17 posts
Posted 19 March 2015 - 07:08 AM
How would I go about implementing my PKI in nsh for an implementation of psudo tls I already have the encryption/decryption algorithms figured out basically it's not a true private/shared key but more like a web api key in which theirs a private hash key encrypted and stored on a server with a public hash key that decrypts that key the uses the private key for validation the encrypted form is sent to the client which decrypts it using their copy of the private key and sends the decrypted private key back to be checked against the server's copy of the decrypted private key.
If all of these factors are proven true and your routing api basically solved the problem of validating clients(I was previously using a combination of gps and computerID as a psudo ip address if the location is the same as the one stored in the clients trusted servers file then it's valid it requires a user to validate the request the first time before we have a profile for that server etc.)
on serverside if the key sent matches its copy of private key and the generated client profile based on computer id each computer id has exactly 1 tls key the keys are generated serverside only and only the public key is issued to the client and never transmitted it must be manually input into the configuration file of the client.
if every one of those factors are true then the server uses a random time seed based on %d%d%d all the minecraft time values to generate unique keys with each request and send those keys along with the packet (Basically the way actual ssl works with the exception of true private/public cryptography in which at no point does the private key in any form leave the server since they encrypt/decrypt each other. Wish I knew a bit more about how to port code to lua to get a rudimentary real AES pki ("same as openssl") since the seed function in lua is an openssl supported one.
Anyway I tried using your nsh to do this but I can't seem to get my nsh client computer to send any sort of request to the server to go through the auth process/notify the server that your remote and want to create a profile.
The cryptography works fine from the server and the server validates the generated password(I just want more than one password or more than one "user", one for each device that connects to the shell might set up a kind of jailing too eventually)
How would I encrypt all traffic like this regardless of what it is at each endpoint decrypt and pass that on to an isolated network behind the router passing the key around till it gets regenerated by the authentication server? Will it keep people from spoofing packets yep. Will it keep people from generating a way of decrypting all packets on the network yes. Could they monitor realtime traffic of a single connection and decrypt that unfortunately yes that's possible if theirs a way of spoofing hostnames.
If all of these factors are proven true and your routing api basically solved the problem of validating clients(I was previously using a combination of gps and computerID as a psudo ip address if the location is the same as the one stored in the clients trusted servers file then it's valid it requires a user to validate the request the first time before we have a profile for that server etc.)
on serverside if the key sent matches its copy of private key and the generated client profile based on computer id each computer id has exactly 1 tls key the keys are generated serverside only and only the public key is issued to the client and never transmitted it must be manually input into the configuration file of the client.
if every one of those factors are true then the server uses a random time seed based on %d%d%d all the minecraft time values to generate unique keys with each request and send those keys along with the packet (Basically the way actual ssl works with the exception of true private/public cryptography in which at no point does the private key in any form leave the server since they encrypt/decrypt each other. Wish I knew a bit more about how to port code to lua to get a rudimentary real AES pki ("same as openssl") since the seed function in lua is an openssl supported one.
Anyway I tried using your nsh to do this but I can't seem to get my nsh client computer to send any sort of request to the server to go through the auth process/notify the server that your remote and want to create a profile.
The cryptography works fine from the server and the server validates the generated password(I just want more than one password or more than one "user", one for each device that connects to the shell might set up a kind of jailing too eventually)
How would I encrypt all traffic like this regardless of what it is at each endpoint decrypt and pass that on to an isolated network behind the router passing the key around till it gets regenerated by the authentication server? Will it keep people from spoofing packets yep. Will it keep people from generating a way of decrypting all packets on the network yes. Could they monitor realtime traffic of a single connection and decrypt that unfortunately yes that's possible if theirs a way of spoofing hostnames.
#105
-
- Members
- 20 posts
Posted 17 May 2015 - 04:08 PM
I'm glad I found this... I was thinking I would have to write my own networking protocols, which would just slow down development for me... +1 to you, Lyqyd.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
