This question already has an answer here:

The need we have is to pass encrypted messages but such that the encryption key can't be generated from the decryption key.

This rhymes with vanilla asymmetrical crypto, but in every schema I've seen, one can generate the encryption ("public") key from the decryption ("private") key in a reasonable order of time.

Use case: we have a network processing daemon that we want to be able to decrypt encrypted traffic headers during routing but in the event the machine is hijacked/rooted/stolen, we want to mitigate the loss and not have an adversary have the ability to author/encrypt anything.

Or perhaps there is a way to combine multiple schemas?

The daemon needs to have some kind of secret in order to decrypt the message headers -- so we're saying that secret gets leaked somehow. Unless what this question poses exists, the only choice would be to use a symmetric key, allowing all nodes on the system to be able read message headers. However, this would allow a rooted/stolen node to author fake messages -- not ok! Well, how about we add-on a signing scheme then... That means nodes would have individually-issued signing keys (that would be revoked/blacklisted when a node is known to be compromised). The problem is, in the mean time (seconds or days), a compromised node would still be able to author fake messages. This question is about a schema that is the "mirror" of canonical asymmetric encryption (where the "public" key can ONLY decrypt and the "private" key can only encrypt or do both).

Terminology accuracy note: I say the "public" key is used "only to decrypt", but it's obviously not public -- it's also held as a secret. In the p2p node example, nodes would hold a set of "community" keys. When a node is known to be compromised, a new community is generated and distributed using asymmetrical (except that the ID of the node that got stolen is not issued a new key obviously). In effect, the compromised shared community key is no longer used and replaced with a new one.

...or, the solution can be canonical asymmetric encryption, but it has to have the property that the encrypting key cannot be derivable from the decrypting key.

This is a far from trivial question and is why the "non-derivable" part of the question is so...key. :\


marked as duplicate by fkraiem, e-sushi Aug 29 '18 at 14:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


It sounds like you're looking for a signature scheme; that is, a way that someone with the private key can generate a 'signature' to a message. Anyone with the public key can verify that the message corresponds to the signature, but is unable to generate fresh message/signature pairs.

And, yes, there are plenty of signature methods around.

  • $\begingroup$ Maybe I'm not following what you're seeing, but we need the message headers to be encrypted, not just signed. I'm guessing you're seeing a composite strategy? $\endgroup$ – Drew O'Meara Aug 27 '18 at 18:49
  • $\begingroup$ @DrewO'Meara: Yes. You can first sign your data and then encrypt it (or possibly the other way around, if you prefer). $\endgroup$ – Ilmari Karonen Aug 27 '18 at 19:36
  • $\begingroup$ But in the case where a node is compromised, the node signing key and the encrypting key are both lost to your adversary. They will still be able to send fake messages to other nodes until the compromised key is marked as revoked on other node participants! In a scheme that I'm asking for, only the ability to decrypt is lost. Looking for answer to the question please. $\endgroup$ – Drew O'Meara Aug 27 '18 at 20:23
  • 2
    $\begingroup$ You cannot magically "untrust" a system that gets stolen. $\endgroup$ – Maarten Bodewes Aug 27 '18 at 22:43
  • $\begingroup$ @MaartenBodewes what are you taking about. Please read the question. This is about a variant of asymmetrical encryption. $\endgroup$ – Drew O'Meara Aug 28 '18 at 0:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.