2

I have protocol required for privacy. Thus, I want to use hybrid cryptography. Base on my knowledge, ECDH is fast and secure. My system consists of 3 main components a trusted-server, client, and server

1- The server will generate ECDH parameters and the private key 
and compute the public key.
These parameters and the public key save at the trusted server.
2- When the client joins the network, the trusted server sends the 
parameter and public key to the client. 
3- The client generates his private key, computes public key and then computes 
the secret key by using the public key of the server that was received 
from the trusted server.
4- The client encrypts his message by using the secret key and 
send the encrypted message and his public key to the server.
5- When the server receives the message, the server computes the 
secret key by using the public key of the client and decrypts the 
message by using the secret key.

My questions are: 1- Does this scenario is correct? 2- Can be used ECDH with static public key and parameters?

1

The scenario does not seem correct; what's to stop an attacker man-in-the-middle'ing Step 2?

I don't see any way in your protocol for the client to know that it is talking to the real trusted server and not an attacker.


I also notice that your solution provides no way to block a client from joining the network and/or verify the identity of a client prior to letting them in (ie it provides privacy but no authentication). Doing that would require bootstrapping your clients with some sort of certificate / pre-shared key / auth token prior to it joining the network.

Basically, your clients will be communicating security with someone, but they will have absolutely no idea who. When you allow attackers to join the network freely, then what's the point of encryption?


Static ECDH does exist, so you can use it but I personally have never seen it used "in the real world" it's always ECDHE+RSA using a RSA certificate from a CA, or something similar.


Yeah, basically don't invent your own crypto protocol. Just don't.

There are any number of secure networking protocols with open-source implementations that have been well designed by crypto experts. Signal / libsignal comes to mind, though there are many many others. This is a solved problem, don't re-invent the wheel.

  • The client can verify the trusted server by the trusted server certification. – ayman khallel Aug 1 '18 at 20:00
  • @aymankhallel The trusted server has a certificate? Where does it say that in your question? Maybe you should edit and clarify the relationship between the client, server, and trusted server? – Mike Ounsworth Aug 1 '18 at 20:02
  • So, can I use ECDH with fixed parameters? – ayman khallel Aug 1 '18 at 20:06
  • As I re-read your question in light of that comment, it sounds more and more like you are trying to solve exactly the same problem as the Signal protocol (the crypto layer behind Signal and Whatsapp). So no, don't use ECDH with fixed parameters, in fact don't invent your own solution at all, instead use libsignal. – Mike Ounsworth Aug 1 '18 at 20:09
  • ... or do use them, tell me the name of your app, and I'll hack into it easily :) If you clarify your question, then I will re-write my answer to match. – Mike Ounsworth Aug 1 '18 at 20:09
0

To use static key pairs (of any kind) your protocol needs some way to trust the public keys. Once the public keys are trusted then yes, static-static Diffie-Hellman may be used to generate a session specific secret. Of course, you'd need a nonce in addition to the static keys, otherwise you'd always generate the same secret value.

All kinds of secret key agreement schemes can be found in NIST SP 800-56A Rev. 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. The static static scheme is specified in section 6.3 and is called C(0e, 2s) as it uses no ephemeral keys (e) and two static keys (s).

Note that such a static, static C(0e, 2s) scheme does not provide forward security. If the private key of either of the two party scheme is ever leaked then all messages become compromised. One solution would be to use two ephemeral key pairs in addition to the static key pairs; this scheme would be called a C(2e, 2s) scheme in the NIST documentation.

However generally a c(2e, 0s) scheme is used to create the session secret. Then the session is authenticated by generating a signature over the (random) parameters used. In that case the static key pair(s) are used for signature generation (RSA, ECDSA) rather than the key agreement itself. Examples are easy to find: all the DHE and ECDHE schemes used in TLS perform this kind of key agreement / authentication.

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.