Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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

You can use the well established TLS (Transport Layer Security) protocol to achieve the first three properties and modify it to include a digital signature for non-repudiation*. However, strictly speaking, non-repudiation requires the use of certificates from a CA so that the signature can be verified by any third party.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.