0
$\begingroup$

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.

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ don't use nanoTime $\endgroup$
    – CodesInChaos
    Commented Dec 13, 2013 at 13:35
  • 1
    $\begingroup$ 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. $\endgroup$
    – rath
    Commented Dec 13, 2013 at 16:47
  • $\begingroup$ @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 :( $\endgroup$
    – Favolas
    Commented Dec 13, 2013 at 17:46
  • $\begingroup$ 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 $\endgroup$
    – rath
    Commented Dec 13, 2013 at 18:09
  • $\begingroup$ @rath Thanks. But after a while the AES key should be renewed. Wright? Maybe every hour? $\endgroup$
    – Favolas
    Commented Dec 13, 2013 at 18:16

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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