1
$\begingroup$

Say we have a public network and lots of peers. Each may need to communicate with another peer.

Would there be any huge security issue to each peer making the the public part of their key openly available across the network?

In this way, any other peer in the system could automatically calculate a secret to communicate with them. (e.g. using the secret as the AES encryption key)

Any caveats or issues welcome, thank you.

$\endgroup$
  • $\begingroup$ so everyone is fixing their public DH key and publishing it somewhere? Will the key be established using two fixed public keys or from ephermeral and one fixed? In either case you'll loose forward secrecy (more or less) $\endgroup$ – SEJPM Aug 21 '15 at 11:58
  • $\begingroup$ You might want to read NIST SP 800-56A Revision 2 (if you're up to that task). Especially if you want to use two static keys - you don't always want to wind up using the same session key. Oh, and of course you need to trust the public keys using some kind of trust framework as you seem to want to use them for authentication. $\endgroup$ – Maarten Bodewes Aug 21 '15 at 12:06
  • 2
    $\begingroup$ Sure you can do that! That's precisely what public key cryptography is all about. Now you have to be careful with the details; i.e., you must be sure that the public key is authentic, and you should not use the same secret key to encrypt, to sign, for ZK proofs ..., so that it becomes unsecure in the end. You also have to somehow derive new keys for every session... But in principle, yes, you can do it. The security of schemes with public keys is not based on the assumption that public keys are kept secret. $\endgroup$ – Chris Aug 21 '15 at 13:53
3
$\begingroup$

Basically yes, you can do that. Public keys are meant to be shared. The devil is in the details however:

  • public keys without trust are pretty useless as you don't know who you are performing the key agreement with;
  • two static keys will always generate the same key for the same partners if you use a naive DH implementation, something you probably don't want;
  • you need different keys for the sender and receiver
  • you need message integrity and authentication once you start sending messages

Etc. etc. etc. Different methods of performing DH are described in NIST SP 800-56A Revision 2. That still doesn't describe the authentication framework though. You could do worse than learning TLS 1.2 and 1.3 for starters.

$\endgroup$
  • $\begingroup$ If you are satisfied with the answer then it is very much appreciated if you accept it. If you're still missing information then please indicate this in a comment so we know what's missing. $\endgroup$ – Maarten Bodewes Aug 24 '15 at 15:24

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.