Encrypted Messaging

So, on a combat-oriented server, I'm working on improving a basic messaging system run by ComputerCraft. The messaging system is primarily used because of forced local chat on the server.. I'm having all messaging be run through a single, secure computer and then re-transmitted. I have a custom-designed encryption process, which I'm going to explain below. Please point out flaws in the process which would allow people to translate the messages:

So, the messaging server tracks all users who register. When you connect to the server using the program for it, your pocket computer's ID is automatically sent to the messaging server. The server scans its databanks to see if you are a registered computer. If you are not, it asks for two things. Your IGN, and an encryption code. Up until this point, you're using a simple binary shift of letters, along a randomly scrambled array of characters. This is universal for all versions of the pocket-program and all instances of the server. The server records your specified IGN, your computer's ID, and the encryption code you specified. It also records a password for you, which is a randomly generated string of 8 characters. It also records a rank for you in the messaging server. The password is then transmitted to you, and you're told to record it. The encryption code you send is a two-character string. Along a separate shuffled list of characters from the aforementioned basic encrypter, it scans it and sees the distance between the two characters in it. The pocket-program is distributed in many separate versions. Each version has a different value in one point of the program.. This is the value of the distance between the two characters of your encryption code. The encryption code you are supposed to enter at the registry is given to you along with the program, in a secure out-of-game chat. Then, after the computer has your encryption code and you are a verified user - to be a verified user someone with access to the server computer has to rank you up - you'll be authorized to interact with the server as a whole. Before, you were only able to communicate with the server computer. All messages on the channel came through, but every message is encrypted and has a data tag at the start of it. The data tag specifies who receives the message, and the encryption prevents people from bypassing the data tag by using a separate program to record incoming messages. After you can interact with the server as a whole, you'll be able to send a join command to the server computer. It'll ask for your password and an encryption tag. You have 3 strikes available, and 5 other suspicious activities. A strike is gotten by entering an invalid encryption tag - longer than 2 characters - or by sending the wrong password. They are reset by successfully logging in. A suspicious activity is earned any time you send in an encryption tag which is not the same as it has recorded for you.. But you are not informed of these. If your strike or suspicious activity count caps out, your account will be permanently deleted from the chat server and your computer ID will be blacklisted. Once you have connected to the server with the correct password for your computer's ID and a valid encryption tag, you'll be marked as receiving messages and online in the chat. You then will be broadcast the current encryption key for the entire chat server. However, it will be encrypted using your encryption tag. The data tag before the encryption key is transmitted will specify only your computer's ID as receiving the message, and so it won't be shown to anyone else using the pocket-program. Anyone not using the pocket-program, or using a different version with a different encryption key hardcoded in it - will see an unintelligible mess of characters, as they won't have the correct encryption tag for it. The encryption key which you receive from the server will have been encrypted using the tag you submitted at the start of the session. If that matches the tag hardcoded into your version, your computer will now have the current encryption key for the chat server in it. If it doesn't match, your computer will have a useless mess. After you receive the encryption key, all incoming messages will be decrypted using that key. If they contain a tag pertaining to your computer, then they'll be displayed to you. If you had entered your encryption ID wrong, nothing will be displayed, as the data tag authorizing your program to display the messages will be fouled. A foreign computer would be receiving all of the messages, but as the messages bouncing around the channel have been encrypted using various methods - inconstant - it'd be hard to track a pattern and create your own decrypter. Additionally, because the encryption key for the chat server is only stored on the chat server, a copy of a pocket computer with the program can be lost to another player without violating the system. As the list of characters used for local encryption tags - which are used when transmitting the global encryption tag - is shuffled, they cannot tell what encryption tag to use for that computer, as they only have a numerical shift value. That shift value also would be useless, for the aforementioned reason of the character list being shuffled. Also, if someone watching the stream of data across the channel notices that most of the messages begin with a common set of characters - which would be the 'all' tag used to say that all verified members will see that message, they still won't be able to reliably translate. If they watch for long enough to figure out the encryption pattern, that encryption pattern is changeable easily in the server computer by rearranging an array. Then, when users log in again, they'll be re-transmitted the new array personally encrypted and marked for them to receive.

Oh, also, any time the server picks up a message from someone who does not have the basic tag at the start - which is used for every message sent by the pocket program - it will be recorded to the server computer, as well as the channel the server was currently running on. This will allow the chat server Ops to change the channel being used, and notify all authorized users of the system.

Does anyone notice flaws within this, which would allow someone to gain access to the network without actually being authorized?

I can see a DDoS possibility here. Make a program that causes suspects activity - make it cause it on all ID - all ID blacklisted - all users deleted - system locked.

Yeah, woj, except that requires someone with knowledge of the inner workings of the server, as suspicious activity is only registered when you incorrectly reply to a prompt given by the server. The server does not give prompts unless you send properly encrypted access codes.. The encryption that would cause it to send the log-in prompts is specific to each registered user of the program. They'd have to collect the encryption code for an ID before they can blacklist it, otherwise they won't send a message which can be decrypted to yield a proper pairing of ID and encryption tag. I also just realized that because all following communications with a specific user are done with their last-registered encryption tag, they manage to make the server ignore them if they enter it in wrong.. I'm going to have to make it permanently store the original encryption tag, and use that for performing logins, regardless of last-entered encryption tag, which would also be stored. Also, it only deletes registered users. The system management computer is not a registered user, and it is the only way to firmly manage things. But thanks for pointing out the potential of DDoSing. For that purpose, I'm going to not make it automatically delete and blacklist IDs, but rather I'll make it un-register their account, sending it back to the stage before their account registry has been approved. I'll also make it store a registry of suspicious activities, which will be reviewable with the system computer. That way if I notice a suspicious pattern, I can change things up, such as the basic encryption used to register an account, or the data tag used to direct a message to the server computer.

Only problem I can see with the concept is if the encryption method is susceptible to known-text attacks, in which case someone could register to this, send someone a message, and then receive the encrypted copy of the message allowing them to get someone's encryption code. The best option for encryption would be public-private key encryption with secure keys, although even your proposed idea is a bit overkill for what it's actually being used for

People's encryption codes are only used for broadcasts to them by the server itself, not for the actual chat. The main encryption(two lists of all the characters, randomized each time, then matching up the char from 1 list to the same spot on the other list, plus a random shift value) is used for main chat-based functions.