0

What I have is a client server scenario, and a payload (x).

  • The server generates x and encrypts it : enc(x)
  • enc(x) is sent to the client
  • The client decrypts the data to get x

However, the restrictions I must enforce are that:

  • The encryption and decryption keys must be different
  • The client must not have the encryption key

So straight up RSA is out the window, since you need both the public and private key to decrypt, and the public key lets you encrypt it.

So the objective is twofold: for the client to be able to decrypt a piece of data, ensuring that it came from a known source - but for the client to be incapable of producing its own encrypted version of the original payload.

C# ideally, but I can accept similar language answers.

Edit: I'm informed that only the private key is required to decrypt and not both keys - however there doesn't seem to be a way to make the RSACryptoServiceProvider in .Net do this.

PhonicUK
  • 13,486
  • 4
  • 43
  • 62
  • This sounds like a standard use of RSA signatures. Do you actually want the receiver to decrypt, or do you want the receiver to verify a signature? If so, why? – CodesInChaos Sep 25 '12 at 12:34
  • 1
    [RSA#Signing messages](http://en.wikipedia.org/wiki/RSA_(algorithm)#Signing_messages) – Rawling Sep 25 '12 at 12:37
  • Yes the receiver needs the original data (it contains licencing information) and needs to be able to verify its origin. – PhonicUK Sep 25 '12 at 12:37
  • Rawling - You'll need to provide a more concrete example - That example doesn't prevent the receiver from being able to also create their own signature since they have both keys. – PhonicUK Sep 25 '12 at 12:40
  • PhonicUK RSA signing only requires the receiver to have the public key. – Rawling Sep 25 '12 at 12:42
  • I can use signing to verify the origin, but how do I also stop the client producing its own encrypted version? I can't send the original data as clear text and just sign it to verify the origin - that only solves half the problem. – PhonicUK Sep 25 '12 at 12:44
  • 1
    Why do you care if the receiver can create encrypted messages? Those messages can be easily rejected because they're not signed by the sender. – CodesInChaos Sep 25 '12 at 13:00

2 Answers2

4
  1. Use something like AES to encrypt the data
  2. sign the encrypted data with RSA
  3. send the encrypted + signed data to your client
  4. since AES uses a shared key the client can decrypt the data
  5. the client can verify the signature using the public RSA key

The drawbacks are :

  1. The client can reproduced an encrypted message but it won't be signed (since only you have the private key).
  2. the client can replace the public key on his end with his own key pair to sign/verify the message.
Nasreddine
  • 36,610
  • 17
  • 75
  • 94
1

Just use two keypairs, one for encryption and one for signing. RSA is fine for this.

Thom Smith
  • 13,916
  • 6
  • 45
  • 91
  • Can you answer in more detail please. I still don't see how having two key pairs prevents the client from being able to produce its own encrypted version of the original data. – PhonicUK Sep 25 '12 at 12:43