Is there an asymmetric encryption that works in a reverse way of RSA (encrypt using private key and decrypt using public key)? [duplicate]

Question

This question already has an answer here:

• RSA encryption with private key and decryption with a public key 3 answers

I'm writing a program that needs to receive an encrypted message from the server and decrypt it on the client.

The problem in this case, is to prevent the client from being able to re-transmit messages encrypted with same key. RSA is designed to use the public key for encryption and private key for decryption. So if a client can decrypt a message (using private key), the client is also able to encrypt another message using it.

I know that it is possible to sign a hashed message using private key and then verify it using public key. But my scenario is not a digital signature problem. I just need a "read only" encryption.

Is it possible to do this using RSA or any other asymmetric encryption algorithm?

UPDATE:

I know that RSA cannot encrypt data longer than it's key size and this is the reason for hashing data to a fixed length data. My supplemental question is: Can we convert a long message to a few small and fixed length blocks and use the same algorithm used in signing and verification to do encryption and decryption?

Answer 1

The need you describe is called DRM, and to implement it you don't need asymmetric encryption - DRM typically uses symmetric encryption where the server encrypts the data using a symmetric key specific to the receiving client.

All that said, once the protected data is decrypted there is no technical way to prevent it from re-distribution. You can, at most, use legal means to deter unauthorized re-distribution. That holds true even if you were a multi-billion $$$ corporation such as Sony or other media behemoth.

The closest you can get to DRM protection on the technical side is to have the server transmit the data only after the client proves that it is genuine, and to have that in turn possible (to some extent) only if the client is hardware-based and non-rootable - e.g., a book reader, set-top box, game console, etc., depending on the media type.

Answer 2

Yes you can, but you probably shouldn't. Other than the key size, there is no theoretical or mathematical reason why you can't swap the exponents (the public and private keys are exponents in the RSA equation). It would thus remain asymmetrical as you stated.

However, there are some good security reasons why you might not want to. The very fact of it being asymmetrical tells you there is an important difference between the public and private keys, so it's intuitive that it won't work well to swap them. The difference being that one (the private key) is exceedingly difficult to compute from the other (the public key). Swap them, and that property vanishes.

It might provide a kind of DRM as pointed out by stromboli, but I don't think it would be nearly as secure (even cryptographically) as you'd want it to be. Consider also the problem of sharing that stromboli mentioned.

If you want a deeper look into the security vulnerabilities of swapping the keys, have a look at the question "RSA: Is it secure to use the private key to encrypt and the public key to decrypt?"

Answer 3

Answer to your supplementary question:

I know that RSA cannot encrypt data longer than it's key size and this is the reason for hashing data to a fixed length data.

Can we convert a long message to a few small and fixed length blocks and use the same algorithm used in signing and verification to do encryption and decryption?

To encrypt longer block / stream is done by creating a random key for symmetric encryption and using the public key to encrypt the generated key. This generated key is used to encrypt the plaintext of any length much more effectively

Encrypting the message itself using RSA is not safe and really not efficient.

this is the reason for hashing data to a fixed length data.

that is used for signing, very often with some salt/nonce and timestamp