get_new_pkey()
Description: Handles remote_user's request for our PUBLIC key
- determine where the request came from
- determine what our public key is
- ask user if they want to send their public key to the user
- Yes - extract your public key from your keyring and send
- key - send rejection notice to user

add_new_pkey()
Description: This is a request to add a new users public key to our keyring
- Check to make sure we don't have a public key for them yet
- Yes - exit and give the sender a rejection message
- No - Prompt local_user if they want to add key or not
- No - Send Rejection notice to sender
- Yes - add new key to keyring
Note: as of now, I think we will save ourself a TON of time if we try to stay away from the key operations and stick primarily to just adding or denying keys... we can do more keyops in the next release/version but I don't think we are EVER going to get this done if we focus to much on key ops

get_skey()
Description: This operation is called when a individual user requests the current SESSION key
- Get Nickname of requester
- Determine things about requester
- Good (ie, Sender is in Keyring)
- prompt local_user if they want to give remote_user the current SESSION key
- yes - encrypt skey with users pkey and send key to remote_user
- no - Send get_skey request denied to user with reason (get_skey denied)
- Bad (Person is on list of ppl to autodeny )
- Send get_skey request denied to user
- Unknown (we don't have a public key for the remote_user)
- Send get_new_pkey request to remote_user
- don't recieve key before %timeout
- Send get_skey request denied to user with reason (no public key for user)
- recieve key
- prompt local_user if they want to add remote_user's public key to their ring
- yes
- add remote_users public key to to local_user's keyring
- prompt local_user if they want to give remote_user the current skey
- yes - encrypt skey with users pkey and send key to remote_user
- no - Send get_skey request denied to user with reason (get_skey denied)
- no Send get_skey request denied to user with reason (public key denied)
Note: There are a few more operations that we have to put in there that I haven't yet (IE sending user a add_pkey sucessfull message)... etc misc shit like that I just have to decide where I want to stick operations like that ...what routine... since we don't want this script to be redundant.... IE... about 1/2 of the operations above will not be IN the actual subroutine... but a call to a previous sub routine...
Note: Another thing I just though of while relooking at this section... how are we going to keep a remote_user_A from encrypting the skey he recieved from the authorative host with remote_user_Bs pkey and sending them the skey..... We could possibly somehow or another pass along the authorative host with the skeyID.. so a message sent out would contain skeyID:authhost:cryptmessage...

use_skey()
Description: This is where we determine the Session KEY (SKEY)
- determine who remote_user is that is sending the skey
- see if remote_user is the same as authorative_user
- No - Send remote_user a request denied with reason (not authorative for skey $skeyID)
- Yes - Set recieved skey as the skey for $skeyID
Note: this is the place where we are going to have to do some serious thinking to determine how we set an authorative person for the skey to come from... and what to do if we recieve a skey from someone who we HAVEN'T set as the authorative host... etc. Things to think about are possibly what if the person wants to have multiple sessions? then they would have to have multiple session keys... we would have to determine a way to uniquely determine each session key so that in effect we could determine which skey a remote_user is requesting.... we could prolly encode this into the way we SENT the encrypted messages.... ie we would send a skey_unique_identifier - crypted message but... this is something to work out at a later date/different version?

incoming_message()
- try to decrypt the message with skey
- if we can't, return failure
- else return plain text message

outgoing_message()
- try encrypt message with skey
- if we can't, return failure
- else return cypher text message
Note: hehe incoming_message and outgoing_message are WAY general.. we still have to determine how we want to send the message so that the user doesn't see the actual encrypted data... but rather just the plaintext (assuming they can decrypt it sucessfully with skey... that would be ideal, but we will discuss later...