One-Way Command Verification Using 2 Private Keys

Question

I'm trying to figure out if it is theoretically possible to send one way commands that are 100% verifiable by private keys.

The Idea is simple: Master wraps verify secret -> inside a public/private key encryption(master only private key) he then takes this public key, and encrypts it again but with a command AND using a shared private key. soo..

Master - >SECRET > Encrypted (keep private, send public) > Add msg to top > Encrypt with a different pub/priv key, but this time the private key is shared by master and slave.

I'm sure I got some details mixed up. But the idea is simple, using 2 pub/priv keys can a msg be encrypted using one key, and verified by the second key which is found in the un-encrypted version of the original msg.

What I cant figure out, is if the encryption gets weaker this way, by including a form of non-changing salt. And this MUST protect against identity forgery, assuming private keys stay safe.

Can This be done? Is This Crazy Talk?

Answer 1

If I may rephrase your idea

The sender would:

1. Create a message
2. Create a payload that includes the message, plus a digital signature created by encrypting the message (or a hash of the message, if it is large) with the sender's private key.
3. Include the payload plus the sender's public key in an envelope
4. Encrypt the envelope with the receiver's public key

To read the message, the receiver must:

1. Decrypt the envelope using the receivers private key
2. Decrypt the digital signature using the provided public key
3. Confirm the message (or its hash) and the signature match

The idea being that you get both privacy (because the sender encrypted the message with the receiver's public key) and integrity (because the sender signed the message with a signature that can only be created using the sender's private key).

I am thinking this would mostly work, with one small problem. Your system lacks any notion of trust. How does the receiver know the public key belongs to the sender? A malicious actor could create a totally different message with a different asymmetric key, right? If you don't know where the message is coming from, all notions of privacy or integrity are completely moot.

Normally, the way you verify a public key belongs to an entity is to leverage the PKI and check the chain of authority. This requires the CA and everything that comes with it.

A different way to deal with this (if you don't want to deal with PKI) is with shared secrets. You would generate a secret key and provide it to the receiver out of band (e.g. mail them a USB drive). That way you don't have to play all these games, you just straight out encrypt the thing, and assume nobody else can decrypt it. That sort of approach is very common.