Can public key be recovered from ciphertext & encrypted private key?

Question

I'd like to implement something like a write-once public/private encrypted shared secret (no better quick description for the lack of terminology knowledge). I guess, I'm trying to implement HSM.

The scheme goes as follows:

1. given a secret (e.g. 512 characters long string)
2. generate a public & private key pair
3. encrypt the secret with the public key, for private key to decrypt
4. encrypt private key, to a hardware token key (OpenPGP smartcard, yubikey, FIDO secure key, TPM etc.) such that only the hardware token can decrypt it.
5. destroy public key, destroy plain copy of the secret key

The following properties are achieved:

• given that public key does not exist, no other encrypted secret can be created for that private key.
• both encrypted secret & encrypted private key can be stored externally and transmitted via insecure channels
• to unlock the secret, both encrypted secret & encrypted private key must be presented to the hardware module that does on-chip decryption of the private key & decrypts the original secret which is presented back
• a single hardware token can unlock unlimited amount of secrets (as they are stored externally)
• it's not possible to tell which hardware token can unlock which secrets

Are there fallacies in above argumentation and is it a reasonable scheme? Can a public key be derived from ciphertext & encrypted secret key? Can a public key be derived from ciphertext & decrypted private key? (assuming hardware token is flawed and exposed it externally)

Essentially, I'm trying to create a multi-factor scheme to store shared secret which is used for full-disk encryption (LUKS / cryptsetup). With above to access unlocked encrypted disk I'll need to have:

• ciphertext
• encrypted private key
• hardware token to unlock the first two (e.g. smart card)
• smart card pin

But I can reuse the smart card for multiple secret/ciphertext/private-key combinations. Or am I unnecessary complicating things, and should simply encrypt the shared secret with a smart card?

Answer 1

Are there fallacies in above argumentation and is it a reasonable scheme?

It's not unheard of to encrypt secrets for them to be decrypted by a HSM or smart card. Usually though the smart card or HSM itself is used to encrypt/decrypt stored secret values. I know that at least one HSM does this, and all TPM's out there.

If you are accepting an unlimited number of secrets, then you seem to be generating an unlimited amount of key pairs. If any combination of public/private key pair is accepted then you may as well always use the same public key/private key pair.

As a side note it's strange to talk about a secret being 512 characters. That doesn't mean anything in cryptography (unless you mean C/C++ char values that essentially translate to bytes).

Can a public key be derived from ciphertext & encrypted secret key?

No, not if the encrypted secret key is presented as raw key material. Both outputs should be (almost) indistinguishable from random.

What you are trying to accomplish should be possible without a secret public key. Using cryptography outside its bounds is dangerous and should be avoided.

Can a public key be derived from ciphertext & decrypted private key?

Yes, almost certainly, unless the public exponent has the same properties as the private exponent. The modulus will be known so it is required to keep the public exponent safe. Most private key containers will contain CRT parameters and/or the public exponent. Furthermore, the exponent of the public key is often a known value such as 3 or the fourth number of Fermat (65537).

Or am I unnecessary complicating things, and should simply encrypt the shared secret with a smart card and that's it?!

Yes. That seems at least more reasonable than the scheme you've described above.

Even if the scheme is not directly wrong, it contains too many assumptions and leaves too many things not well described. It's unlikely that a direct implementation will be secure.