# Generate random in secure message transfer

I’m doing a school assignment about secure communications between a Server and a Client. Basically, messages are exchanged between the clients and the server and these communications must implement confidentiality, authentication, integrity and non-repudiation.

Imagine I have to send a message from the client to the server. This is what I’ve idealized:

• Client and Server both generate their public/private keys;
• Their public keys are shared between them;
• Client, generates a session key using 'AES';
• Client encrypts the message using the session key and sends this to the server;
• Client encrypts the session key with the Server public key and send this to the server;
• Client creates a hash of the message and encrypts this hash with the client's private key and sends this to the server;
• Server uses is private key to get the session key;
• Server uses session key to decrypt the message;
• Server decrypts the hash with the client's public key;
• Server creates hash of message and compares with the above hash.

I’m thinking of creating a new session key every time the Client sends a message to the Server.

1. Is this the way it should be done?
2. In the generation of the keys I have to use a random number. How do i do this?

My thoughts for #2 are:

KeyGenerator keygen = KeyGenerator.getInstance("AES");
keygen.init(128,new SecureRandom());


Or this:

KeyGenerator keygen = KeyGenerator.getInstance("AES");
keygen.init(128,  System.nanoTime());


Or should I use other way? I'm asking this because I don't know the best way to generate the seed.

-
don't use nanoTime –  CodesInChaos Dec 13 '13 at 13:35
You are basically making a hybrid cryptosystem. I don't understand something though: The client sends an encrypted message, and then sends the key. Why not share the key before any message is sent? Second, a hash itself is not a signature. This is especially important in your scheme as you don't use an IV (which means an adversary can repeat a message and the server would accept it). Finally, take a look at this question. I hope this helps. –  rath Dec 13 '13 at 16:47
@rath Hi. Thanks for your comments. Key is not shared before, because a new key is generated in every msg. I believe this makes more difficult to "crack" the key. Isn't it? Should I use other method??.. Relatively to the hash, when the Client creates a hash of the message and then encrypts this hash with the client's private key and sends this to the server, isn't this guaranteeing the integrity of the message? Sorry but I was lost in the IV and how I should generate or not the random :( –  Favolas Dec 13 '13 at 17:46
If you generate a proper AES key (with PBKDF2 or Scrypt) it certainly does make brute-force harder, but brute-forcing AES an unfeasible strategy because it's completely impractical to do so (you can google how much time it takes with a proper key). That's why it's the standard after all. By renewing the key for each message you defeat the purpose of a hybrid cryptosystem, which is to avoid expensive operations associated with assymetric ciphers and use the faster symmetric ones. You do need to use an IV though. Some ideas on that –  rath Dec 13 '13 at 18:09
@rath Thanks. But after a while the AES key should be renewed. Wright? Maybe every hour? –  Favolas Dec 13 '13 at 18:16