0

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.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Favolas
  • 109
  • 1
  • 3
    don't use nanoTime – CodesInChaos Dec 13 '13 at 13:35
  • 1
    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
  • Like @CodesInChaos already commented: don't use nanoTime. Instead, go for SecureRandom as that actually returns a crypto-secure random number… which is what you want/need. – e-sushi Dec 13 '13 at 20:49

1 Answers1

1

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.

jingyang
  • 734
  • 3
  • 5