1
$\begingroup$

My question is fairly simple. I have more than two nodes which needs to communicate very efficiently from computational point of view. One of the nodes can become a coordinator between the nodes. Nodes do have certificate and private keys. To let the nodes communicate with each other efficiently I plan to use a symmetric key therefore key-exchange must be done.

The scheme to key exchange that comes to mind is to share DH's prime and primitive root among all so every one can have the shared secret key after a ring communication. Of course to prevent MITM the parameters are encrypted with each party public key.

Another scheme that comes to mind is to let coordinator generate a secret key and distribute it to nodes using their public keys.

I tend to the 2nd scheme since it's easier to implement and needs less communication in handshake phase.

Would be a compromise to distribute the secret key encrypted with public keys? Or it's always recommended to use scheme like Diffe-Hellman to avoid explicitly sending the shared secret key even encrypted.

$\endgroup$
3
  • 1
    $\begingroup$ I'm confused, are you wanting to establish a group key for symmetric encryption (everyone knows it), or are you wanting to establish pair-wise symmetric keys (every pair has a separate key)? $\endgroup$
    – mikeazo
    Mar 3, 2015 at 13:41
  • $\begingroup$ yes that's right. everyone including the coordinator are in the communication much like a peer2peer architecture in which one has been seleced to be the coordinator. Everyone must be able to communicate with each other. $\endgroup$
    – CppChase
    Mar 3, 2015 at 21:12
  • 2
    $\begingroup$ You might consider taking a look at the papers Multicast Security: A Taxonomy and Some Efficient Constructions and Provably Authenticated Group Diffie-Hellman Key Exchange. Or more generally, Multicast Encryption. Multicast Encryption and Broadcast Encryption have been discussed here on Crypto.SE. $\endgroup$
    – user10496
    May 4, 2015 at 6:46

3 Answers 3

2
$\begingroup$

Key exchange is notoriously hard to get right, and I strongly recommend not to do your own (unless your security requirements are really minimal). For example, what you propose does not provide forward security, which is generally considered of great importance in key exchange protocols. The good news is that there is a paper doing exactly what you need; look here. I haven't looked at the details of it, but by the abstract it sounds very efficient (albeit, not as efficient as your proposal, but giving you provable security with properties like forward security as well).

$\endgroup$
1
$\begingroup$

If efficiency and speed is an issue, you might want to have a look at protocols based on symmetric schemes and a trusted server for key exchange and authentication, e.g. Kerberos or Needham-Schroeder.

Key exchange with DH is only required, if you want the coordinator node not to be able to listen in the other communications. But usually public key operations (let's count DH key exchange to that, too) are quite a bit slower than symmetric operations.

A few other apsects, which you should not forget:

  • nonces (or timestamps) in challenge-response mechanisms to prevent replay attacks
  • always authenticate both communication parties
  • how are keys generated/revoked/become invalid/updated/...
$\endgroup$
1
  • $\begingroup$ The coordinator is a part of communication. as mikeanzo also mentioned, it's a form of grouo communication or peer2peer communication in which one has been ellected to be the coordinator. In that case I would be able to skip DH right? regarding the aspects: all are in the plan :) thanks for mentioning $\endgroup$
    – CppChase
    Mar 3, 2015 at 21:10
0
$\begingroup$

Depending on resources available on nodes and whether you are going to implement anything yourself, racoon and ipsec could be a solution.

It supports nodes with x.509 certificates issued by a local CA.

Please note this question is not simple at all.

$\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.