This question already has an answer here:

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?

marked as duplicate by e-sushi May 20 '17 at 1:25

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi May 19 '17 at 16:22

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.

  • My end goal is DRM. But I am trying to use asymmetric encryption for a better DRM. – Ahmad Badkoubehei May 19 '17 at 12:51
  • @AhmadBadkoubehei What you describe is not asymmetric. When you encrypt with a private key you are using the key pair as a symmetric key in the sense that the full credentials are known to both parties. In other words you use RSA symmetrically, which, cryptographically speaking, is worse encryption than e.g. AES or probably any other modern encryption which is designed to be symmetric. – stromboli May 19 '17 at 13:34
  • 1
    My question is exactly the same as you said. I asked can we encrypt a message using private key and then decrypt that using public key? If it is possible, then it remains asymmetric. Because public key does not contain paramters of private key. – Ahmad Badkoubehei May 19 '17 at 14:54

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 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

  • Efficiency isn't in all practical situatations of paramount importance. The common people normally have only messages of fairly small volumes to exchange with one another and a few seconds or even a couple of minutes of processing time wouldn't gravely matter for them, provided that the processing could be done conveniently and securely. I have a RSA signcryption scheme targeting this (large) class of users at mok-kong-shen.de as Example 3S there. – Mok-Kong Shen May 22 '17 at 8:08

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