all the details are given in docx
Microsoft Word - netp3.doc PROJECT 3, A Secure Chat Service In this project you will develop a secure multi-threaded chat service. The goal is to protect chat messages while in transit by providing a secure communication channel, without having to worry about host security. The secure communication channel will be implemented using a bit-level encryption, and the encryption key (or the one-time pad) will be computed using the Diffie-Hellman key exchange algorithm. For simplicity, we will use 1-byte pads in this project (extract the rightmost byte of the encryption key and use that as a 1-byte pad). The client and server programs will run from the command line with similar command line arguments as in project 2, except that the server will have two additional optional arguments. The additional arguments are for the two publicly known integers, g and n, that DiffieHellman needs in order to compute the secret key. The values for g and n will be hard coded in the server program incase the corresponding option is not given at the command line. The order and the number of command line arguments are not fixed, and may change from one run to the next. See examples below, >java nta_TCPServerMT –p 21400 >java nta_TCPServerMT >java nta_TCPServerMT -g 1019 –n 1823 –p 21400 >java nta_TCPServerMT –p 21400 –n 1823 The functionality of the server and client are outlined below. The server program is multi-threaded so that it can accept multiple simultaneous connections. The server program will log and broadcast every chat message it receives from any client. For each connection, the server will create a new thread and hand the connection to it. The server then waits for the next connection. The server program will create a chat file called ‘nta_chat.txt’ when the first connection is made (the first client joins the chat room) and will share this file with all the subsequent connections as long as there is at least one open connection. The server will delete the chat file when the last connection is closed (the only remaining client leaves the chat room). The server will create a new chat file each time a client joins an empty chat room. The chat file (log file) will contain only the original messages and not the encrypted ones. Since every thread that manages a connection needs to read from and write to the chat file, the activities of these threads must be coordinated (synchronized), otherwise things might go wrong. A thread must have an exclusive access (or a lock) to the chat file before writing to it. When a connection is made, the thread that manages the connection will initiate a handshake with the client. During the handshake the thread will first send the client the values for g and n, and then the two sides will exchange values from which a secret key (or 1-byte pad) will be computed. Due to the randomness of the values exchanged, each client will have a unique secret key, and no two keys will be the same. Upon completion of the handshake, the values of n, g, computed session key, and a 1-byte pad (as a binary string with eight 0s and 1s) should be displayed on the client and server console windows. Note that any exchanges between the client and server from this point forward will be encrypted using bit-level encryption with the 1-byte pad as the key. Next the server will wait for the user’s name, and then sends the client the content of the chat file. It will also log and broadcast the arrival of a new client to the chat room. Any message from the client after this point, except DONE, will be logged and broadcasted. For DONE, the thread will log and broadcast the departure of the client from the chat room. When the client signals that it is ready to leave the chat session (sending DONE), the thread will close the client connection, and will terminate itself. As mentioned above, the server will log and broadcast every chat message it receives from any client. If the server gets a chat message from client A, then client A must be excluded from the list of clients that will get the message (the server doesn’t echo the message back to the same client). The server will write only plaintext messages, not encrypted ones, to the chat file. Since each client has a unique secret key, the message that is being broadcast must be encrypted for each client using that client’s secret key (or 1-byte pad). The client program establishes a connection to the server, and after that the two sides enter a handshaking phase in order to arrive at a common encryption key. Any exchanges between the two sides from now on will be encrypted. Next, the client will identify itself to the server (send user’s name), and then prepare to receive the entire chat file. Now the client is ready to participate in the on-going chat. It sends whatever the user types at the keyboard, and displays whatever it receives from the server. The user can leave the chat session at any time by typing ‘DONE’ at the keyboard, and the client program will send that message to the server and then terminate gracefully. Test the program thoroughly, and make sure it works smoothly when multiple users join the chat room and start simultaneous chat. There is no limit on the size of the chat room and it can grow and shrink dynamically. Prior to submitting your project to the class website, upload your server program to your VM on the GCP, start the server on the background, and test it to make sure it works. When you are done with testing your program, kill the server process and stop your VM. Otherwise, you will be charged daily for those resources. Submission requirements: Please submit the following material to the class website for grading on the due date. · copy all of your files (nta_TCPServerMT.java nta_TCPClientMT.java nta_Readme.txt, etc.) into a folder named nta_proj3 and compress that folder. If you develop your code with an IDE (eclipse, etc.), don’t submit any of the folders created by the IDE. · submit the zip file (nta_proj3.zip) to the class website on ‘canvas.emich.edu’ Note “nta” represents your first, last, and middle initials. Diffie-Hellman handshake protocol: 1- server sends g and n to the client 2- client selects a random value x (between 100-200), and sends gx mod n to the server 3- server selects a random value y (between 100-200), and sends gy mod n to the client 4- each side computes the encryption key a. client computes key = gyx mod n b. server computes key = gxy mod n 1 1 1