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

This sounds like with vanilla asymmetrical crypto I know, but in every schema I've seen, one can generate public key from the 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 effectively 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 community decided to be compromised, a successor community key is generated and distributed using a traditional asymmetrical schema (except that the nodeID of the node that got stolen and of course not issued the successor key). 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. :\


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$ 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$ 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$ 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$ Aug 28 '18 at 0:40

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