Is this ECDHE approach secure?

Question

First of all sorry if this question could be trivial, but I did some researches and it seems to me that this is a standard approach, but I want to be really sure.

I'm developing a signed/encrypted communication block channel. And, to encrypt/sign it, I chose the ECC.

Now, in order to send a message, I will do this

1. Download the server's public key
2. Generate an ECC key on the client
3. Create the shared secret between the server's public and the client's private keys
4. Calculate the hash of the shared secret (e.g. SHA-384)
5. Divide the hash in two parts; one will be the communication key (e.g. 32 bytes for AES-256), the other the IV (if AES, 16 bytes)
6. Encrypt the message with the appropriate algorithm and symmetric key
7. Sign the message with the client's private key
8. Send the client's public key, the encrypted message and the signature

Now, I have three questions about this:

1. Is this approach secure or there is some naive issue?
2. Is it better to sign the plaintext message or the ciphertext message? I'd sign the plaintext (so the server can verify if the message is correctly transmitted), but this would give the attacker a way to understand if the attack was successful
3. What is the suggested ecc key size for this? If I calculate the SHA-384 of the shared secret, is the same ecc key size (so using curve P-384) a good choice? Should I use the biggest key possible (P-521)? Is even a smaller one enough (P-192)?

Answer 1

Is this approach secure or there is some naive issue?

There are some issues, see below. Most naive ones at the top.

1. You need to trust the public keys to create an authenticated connection. I don't see any part of the protocol where you verify public keys.

2. Instead of signing "the message" you need to sign the key agreement parameters. If you just sign the message you're open to man-in-the-middle attacks. Once you've established session keys you just need authentication tags. This should also answer question #2.

3. Depending on the algorithm you may need an encryption key and a MAC key. Alternatively you could use an authenticated mode of encryption.

4. It's usually best to use separate client & server keys, assuming that you require two-way communication.

5. You're directly using a hash as Key Derivation Function (or, as TLS calls it, the PRF). Although that may not directly pose problems, it's probably better to use a true KDF, e.g. HKDF.

What is the suggested ecc key size for this? If I calculate the SHA-384 of the shared secret, is the same ecc key size (so using curve P-384) a good choice? Should I use the biggest key possible (P-521)? Is even a smaller one enough (P-192)?

Using a hash of 384 bits and P-384 is nicely in balance. You can check the NIST recommendations at keylength.com, second table after >> 2030. The only thing currently worry about would be quantum computing as it could attack ECC cryptosystems in general.

---

Nitpicks:

• You cannot generate an ECC key, you can generate a public/private key pair;
• I don't see where you generate key pair for the server;

---

Why not take a look at the draft TLS v1.3. They specifically rewrite TLS there to make sure they solve all the loose ends of TLS v1.2. That should give a good insight in all the pitfalls of creating a transport protocol.

Of course for production purposes using TLS v1.2 is a good idea, don't roll your own.