0
$\begingroup$

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)?
$\endgroup$
  • 1
    $\begingroup$ Try to avoid full crypto-analysis here, as this is deemed off topic. Isolate your questions and ask them separately instead. $\endgroup$ – Maarten - reinstate Monica Jul 12 '16 at 9:52
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks for the accept. I generally tend to wait a while before accepting answers though. Answered questions receive less views and there may be better answers or comments available from people that haven't had the time to view the question in the first place. I usually wait some 18 to 24 hours so that other timezones have the ability to chime in. $\endgroup$ – Maarten - reinstate Monica Jul 12 '16 at 11:09
  • $\begingroup$ Thank you for this answer. You really made me think about lots of things. Anyway, I have just a couple more questions (you know, the more you learn, the more you understand how much you don't know). As for point 1, probably I'll remove the ephemeral feature and use static key, shared "physically" (i.e. manually copied). And I'll move to an authenticated mode (probably CCM or EAX). Communication will be only client -> server, so just one keypair per side is enough. I just did not understant completely point 2, even if with an authenticated mode the signing is not needed anymore $\endgroup$ – frarugi87 Jul 12 '16 at 12:11
  • $\begingroup$ @frarugi87 I'm still contemplating other attacks, but when you've established the encryption key with a man-in-the-middle then signing a message won't disallow decryption of the message. Especially if you only have one way communication after the handshake, an attacker can simply decrypt everything. That the message is also signed doesn't deter any attack. $\endgroup$ – Maarten - reinstate Monica Jul 12 '16 at 19:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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