/*******************************************************************/
/*            CS255 Project 1                                      */
/*******************************************************************/

I.  Group Info:
   
    He, Changhua      username: changhua    SUID: 5155486
    Jin, Weiyin       username: lucyjin     SUID: 5157548


II. Project Implementation:

Part A: Key Exchange 
====================

    We are using the Diffie-Hellman key exchange protocol to first obtain
the secrets between the server and each client.  To do this, java has
the appropriate APIs where we obtained the secret between the client and
the server.  The secret is then hashed in order to compress it down to 160
bits.  The output of the hashing then serves as the seed to the Pseudo
Random Number Generator.  The output of the PRNG is then the parameter we
feed into the java's keygenerator which then generates the keys for us.
The first 8 bits of the output of the PRNG is also assigned to be the IV
of the block cipher, which we called cbcIV.  Then the next 8 bits are
assigned as the IV of the mac, which we called macIV.
   These new parameters we created, namely desKey, mabKey, cbcIV and macIV
are all defined in the ClientKey class and are used in the subsequent
part. 
   
Related files modified: 

ChatClient.java          //modified connect function
ChatServerImpl.java      //modified postMessage function
ChatMessage.java         
ChatConsumerImpl.java    
ClientKey.java           //added new key related parameters and created
                           the keys 


Part B: Message Encryption and MAC
==================================

    Once the keys are generated from Part A, the keys and the IVs are used in
our encryption and MACing.  We are using the same scheme (encryption +
mac) as used in IPsec, namely, we first encrypt the plaintext with desKey  
and then MAC the resulting ciphertext with macKey.  We return this
combined enc+mac resultant message  in the encrypt function.  In the
decrypt function, we first check to see if the message passed in has a MAC
that matches with what we find individually.  If it is, then we know the 2
MACS match and then we decrypt the message.  If not, then we simply return
and output that the MAC is invalid.  

Related files modified:
ChatClient.java          //modified encrypt and decrypt functions
ChatConsumerImpl.java
ChatServerImpl.java      //add encrypt and decrypt functions 


Part C: Preventing Replay Attacks
=================================

Case: 
   A malicious attacker captures a message en route to either the
server or a particular client.  He then repeatedly sends the message,
which is still a valid chat message, thus flooding the intended recipient
and making the chat room unusable for the participants.  

Solution: 
   We attach a sequence number to every message that the client sends. Upon 
sending a message to the server, the client update the sequence number
(add one to the sequence number).  The server also keeps its own set of
sequence numbers (a table that contain the sequence numbers of those
clients who sent messages and sequence numbers to the server).  When it
receives a new message a client sends, it checks to see if it already
has that sequence number in it's sequence number table(a linked list), if
the sequence number already exists, then the server regards it as a replay
attack and discard the message received.  Otherwise,it appends the new 
sequence number into its table.  Each client does the same as the server
(e.g. it keeps a table of the the server's sequence numbers).

Discussion:
   In our implementation, we prevented the attacker from sending the
captured message to the server over and over again by checking the
sequence number of the sender with the server. By implementing this
feature, even if the attacker keeps sending the same message over and over,
it cannot change the sequence number, and the server will discard the
message since that sequence number already exist.  
   This implementation has several limitations.  First, the range of the
sequence number limits the security from replay attack.  For instance, if
the range of the sequence numbers is from 0 to 999, then after a client has
sent a message with sequence number 999, the next message it sends, will return
back to 0 which will not be accepted by the server. Right now, our range
is 2^16, which we believe is big enough to neglect this limitation. To
make the scheme even more secure, we can increase the range of the
sequence number as appropriate.   
   As the linked list grow bigger and bigger, the server also needs more and
more time to look up a particular sequence number.  The lookup time is on
the order of O(log2(n)).    

   For further improvement, we can tell the server to look for a particular
sequence number within a certain time interval (e.g. search in the linked
list a sequence number received only within the last 10 minutes).    


Test Case:
   We tried our implementation by arbitrarily fixing the sequence number
of the message we send to be a constant.  The first time of sending was 
successful, however, subsequent submission of the same message is not
allowed by the server.  

 
For more description on the actual run of the program, please see the
output strings in the command window.