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. :\
