This question already has an answer here:
- Inverse public-key encryption 1 answer
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. :\