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.

Improve this question
$\endgroup$
3
  • $\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
    Commented Aug 21, 2015 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 ♦
    Commented Aug 21, 2015 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
    Commented Aug 21, 2015 at 13:53

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
1
  • $\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 ♦
    Commented Aug 24, 2015 at 15:24

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.