Bob wants to use NaCL (specifically the Python NaCL library) to both a) sign some publically available plaintext for anybody to authenticate as being written by Bob and b) encrypt some other secret plaintext for Alice.

NaCL encourages signing and encryption with different keypairs. Bob would like any recipient to be able to prove that the same person controls the NaCL signing key and the NaCL encryption key used in the two above cases. What is a safe way to do this?

  1. Is there some safe way to sign the private key used for encryption with the signing keys?

  2. If Bob computes a derived keys from some master key can he give out the master public key, and then have people verify that the signing public key and the encryption public key are derived from it?

  3. If (2) what is a safe way to derive keys from some master key?

  4. If (2) how can somebody verify the signing and encryption public keys are derived from the master public key?

Ideally Bob would be able to give out a single NaCL public key and then anybody receiving a signed or encrypted plaintext would be able to verify that the corresponding private key was used.

I've read the relevant documentation on djb's site and this post and the Python NaCL library documentation. In the latter all of the examples use completely unrelated keys for the two different functions.

  • 1
    $\begingroup$ Bob sending to Alice needs to sign with Bob's key and encrypt with Alice's key; unless Bob and Alice are the same person (e.g. sockpuppets) these keys should NEVER be under common control. What Bob should want is to prove to Alice that messages she receives from Bob (signed) and messages (including replies) she sends to Bob (encrypted) are the same Bob. And that is what PGP masterkeys do, as answered. $\endgroup$ Apr 1 '16 at 23:33

Is there some safe way to sign the private key used for encryption with the signing keys?

What you're talking about is also commonly referred to as "keychain" or "keyrings", a concept popularized by programs like GPG, which do exactly this:
They generate one master signature key, which you securely distribute and which then "certifies" the other public keys to belong to you. This way you can keep your master key offline and only use to sign your everyday encryption public key and your everday signature public key.

  • $\begingroup$ excellent, thanks! I will research keychain implementation details. $\endgroup$ Apr 1 '16 at 0: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.