Client creates random number for 'A' and solves 'G^A mod P', sending answer to server
Server gets this and stores in 'B'
Server creates random number for 'A' and solves 'G^A mod P', sending answer to client
Server solves 'B^A mod P' and stores this in 'KEY'
Client gets answer and stores in 'B'
Client solves 'B^A mod P' and stores this in 'KEY'
Client creates a 16 byte random cypher 'C' with 'KEY' randomly distributed inside
Client sends {(KEY # Name) + (hash(password) # C)} to server
Client searches 'C' and removes 'KEY' and stores back in 'C'
Server gets data, looks up "Name" in database and gets the "hash(password)" for it
Server creates 'C' from (hash(password) # data) and removes 'KEY' from it
Server creates 16 byte random cypher 'D' with 'KEY' randomly distributed inside
Server sends {hash(password) # D}
Server searches 'D' and removes 'KEY' and stores back in 'D'
Server combines 'C + D' into 'A'
Client gets data, restores 'D' from (hash(password) # data) and removes 'KEY' from it
Client combines 'C + D' into 'A'
Both create an 8 byte random cypher 'B' and send (B # C) to the other
Both get it, and store (data # C) into 'E'
Both send (E # D) to the other
Both get it, and check if (data # D) = 'B' for verification
Server creates 'CYPHER' from hash(A + B + E)
Client creates 'CYPHER' from hash(A + E +
During the lifetime of the session, a specific code will sometimes be generated that can add to the beginning or end of the 'CYPHER' with or without shifting out, so increasing security. This code is 2 bytes long and is inserted by the server at random intervals in random positions within a codesend.
This involves several methods, the first of which is a D-H method to secure a transmission session, but leaves it open for man-in-the-middle (MITM) attacks. The second method will hide the key inside an encrypted hash of your password, without prior knowledge of your password, there is no way the MITM can decypher this crypt, therefore cannot falsify information to the server. The server will drop the MITM if it cannot find its KEY within the cyphered hash. Because it was a random generation from the client, the server has no way of telling if the client has actually given the proper hash (which means proper password), so sends back another randomly created encryption of the hash....if the client doesn't know the proper hash (because of bad password), then it cannot recreate the proper cypher from the server and will get terminated when it cannot update it's encryption methods for verification. The last step is just a quick cypher exchange to bump up the security as well as test the previous encryptions authentication. Once this is finished, all blocks will just be cyphered with xor.
*note: "^" is the power function above, not the xor function in GM..."#" is the xor function above.
It looks like this method will thwart any attempts of any kind of attack I can think of, aside from the user blatently giving up their user name and password information to someone outright. I would like any feedback from anyone knowledgeable in this field. I've researched and have not found anyone using this method as far as I know, so please give credit if you do use it with success and report any failures.
Now onto the old stuff:
39DLL Lib v1.0
Download 12.1KB zip
Here it is guys, using as much of my abilities on multiplayer ability as I could into an easy to use d&d lib for you. I'm not going to pester you further, I will get around to writing a tutorial on how to use it, but for now the tutorial files that come with it should help you understand the structure.
You can also read my tutorial here if you want to learn from scratch. True Valhalla has one here. This lib uses the 39dll.dll file included in the .zip file, you can find that post here by 39ster.
This includes (looking at image left to right top to bottom:
Initialize DLL
Just like running dllinit()
Can even change the name of the dll file
All functions no longer require the scripts (all built-in)
You will need the scripts if you use them directly
Used in the initialization of the server
Creates a group the joins players together as a common send thread
You can set up a number of subgroups for each group
Players will only be allowed in 1 subgroup at a time
Automatically degroups player when setting to a different subgroup
This is similar to zones in MMO, or even "Trade Channel"
Used to free the dll
Should be the last thing called in your game before game_end
Same thing as dllfree()
Open Port for Listening
Same thing as tcplisten()
Can define how many players you want to allow on at any given time
Runs a string you define if there's an error
Connects an incoming request
Automatically transfers information to the authentication device you choose
Closes the socket for listening
-Server Auth-Initialize Authenticator
Sets up object for authentication purposes
AuthenticateAutomatically handles authentication
Performs several handshakes with encryption keys attached
Automatically handles encryption schemes
Automatically handles queue if too many players are online
Automatically handles "keep alive" communications while waiting in queue
Automatically loads into player object you define, passing encryption key
Releases all authentication devices
-Server Player-Initialize Player Object
Sets up player data
Sets up outbound buffer and inbound buffers
Places object id onto the outbound buffer first
Sends outbound data to player
Receives data into inbound buffer
Handles encryption schemes both directions
Unravels the inbound data into a queue buffer for easy access
Releases all buffer memory
Releases socket
Will check if player is in group/subgroup, skips if so
Checks if player is in group, automatically degroups them
Handles grouping into subgroup
Removes player from group/subgroup completely
Write MessageAdds an evaluation of an expression onto Group buffer
Send Message to GroupAutomatically adds the Group buffer onto every player linked to a specific group/subgroup
Clears the Group buffer
Connect to Server
Same thing as tcpconnect()
Executes a string that you can define if there is an error
Handles the authentication process in FSM fashion
Handles outbound and inbound data automatically after authentication has completed
Places inbound data into a queue for easy access
Returns true if it is still in authentication mode
Returns false if not
Closes socket automatically
Clears buffers
Clears queues
Message ID?
Checks if next number on stack is equal to the ID
Also checks if there are enough arguments to handle event (good for splitting data if need be).
Automatically pops number off stack if it is and returns true, false otherwise
Evaluates an expression and places it on the outbound data stack
ReceiveGets the next piece of data off stack and stores it in a variable you designate
Clean up MessagesIf a full cycle has lapsed without any messages being popped, it will pop first value
This should never happen if programmed properly, but it's there just in case
Please report any bugs with precise error and code file so that I may fix it. Please feel free to leave comments/ideas good or bad. Also...please give credit if you use my code (even if you rip it). All icons have been made by me of my own idea, they count as credit needing too if you take them. If you make money off it, I do not ask for any, but know that I'm poor and if you'd like to donate, you can ask me for my paypal account information. Thanks in advance!
Edited by sabriath, 07 November 2011 - 04:43 AM.
