0
$\begingroup$

I have case when I need take payload to client with key for decrypting. But client mustn't encrypt another payload by this key.

After some research, as I understand it's case of asymmetric encryption. Me: Encrypt data by "public" key. Client: Decrypts data by "private" key and can't encrypt another payload because he doesn't know "public" key.

But I am worrying, as I understand client can get public key from private key and encrypt another data with this key. So how to avoid this? Or may be, does exist another type of encryption which let me do it?

$\endgroup$
3
  • $\begingroup$ Are you looking for digital signature? It provides authenticity guarantees. Or are you looking for digital right management? In which case it's advisable to seek existing commercial solutions. $\endgroup$
    – DannyNiu
    Commented Mar 15 at 11:50
  • $\begingroup$ @DannyNiu I am looking for method which let me do keys pair I have first key and I encrypt payload, client has second and decrypt payload, but client or someone else mustn't encrypt any another payload. Yeah maybe it's looks like digital signature, which provide warranty that author is only owner of "secret key" which used for encryption. $\endgroup$ Commented Mar 15 at 14:27
  • $\begingroup$ A valid signature proves the (so-called) payload it signs originates from the holder of the private "signing" key that corresponds to the public "verification" key. $\endgroup$
    – DannyNiu
    Commented Mar 15 at 14:33

3 Answers 3

3
$\begingroup$

There is a technique known as proxy reencryption which you might find interesting. This allows you to

  • have an initial public key-pair $(\mathsf{pk}_A, \mathsf{sk}_A)$, and
  • a second public key-pair $(\mathsf{pk}_B, \mathsf{sk}_B)$, and
  • a technique of translating $A$ ciphertexts $\mathsf{ct}_A$ into $B$ ciphertexts $\mathsf{ct}_B$.

So you could have people encrypt with $\mathsf{pk}_A$, use proxy reencryption to convert to a ciphertext $\mathsf{ct}_B$, and then have the client decrypt with this key. The client will be able to create more $B$ encryptions, but will not be able to create $A$ encryptions from their secret key $\mathsf{sk}_B$.

$\endgroup$
2
$\begingroup$

You are correct that you must assume that any public key gets known by adversaries and used.

I think you want the combination of two distinct things:

  • Signature of messages. This will allow the client, and any other recipient of messages, to verify that a message comes from you, unadulterated. That verification requires your public key, that the recipient must know with confidence that it's yours. A signature check will prevent anyone but you from making new messages similarly signed (which is possible only with your private key).
  • Encryption of messages. This is will insure confidentiality of the message. Nothing in the question requires public-key (asymmetric) encryption, but it may be the most convenient:
    • public-key encryption is available and the Standard Operating Procedure in many encryption tools with support of signature (e.g. OpenPGPG/GPG). However the client must be technically savvy enough for generating a public/private key pair, sending you the public key (and letting you verify it's integrity if it's delivered by insecure means like email).
    • symmetric encryption is advisable if that key setup procedure is to be simplified, typically into you communicating a passphrase to the client. This is one (of several) SOP in e.g. Acrobat PDF Reader: the document can be deciphered only with the passphrase, it's displayed with indication that it's signed, and by who.

The tools mentioned above (GPG, Acrobat) will, at least by default, allow decryption of messages that are not signed by you. This is an issue if the recipients do not check the signature. It's technically easy to make decryption of unsigned messages impossible, it's just uncommon, because a general-purpose program must allow multiple authorized signers anyway.

$\endgroup$
0
$\begingroup$

As I understand your question, you are looking for a pure asymmetric encryption scheme, where the receiver cannot encrypt messages with just the knowldege of the decryption key.
For RSA as well as ECC the public key can always be derived from the private key, so whoever has a private key for decryption, can also encrypt a message.
Reverse, deriving a private key from the public one is the hardness of the encryption scheme and so close to implossible.
For RSA you might switch the roles of private key and public key, as discussed here. Due to key design this approach might be weaker against attacks, security relies on the sender of a message keeping his key really private, not the receiver; also the major part of the computational time moves to the sender.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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