0

I want to implement simple software protection mechanism. This is how it would look like:

enter image description here

My question is - is there any problem for me using the private key for encryption and public for decryption (since usually it is other way around)?

11
  • 1
    using the private key for encryption and public for decryption is a head-scratcher, because the public key is public (known to everyone), so anyone would be able to decrypt the ciphertext. Perhaps you are referring to digital signing, where the signature is made using the private key, and anyone can verify the signature using the public key.
    – mti2935
    Commented Aug 1, 2021 at 15:26
  • Decrypting is OK. I just wanted to prevent modification and re-encyption of the ACTIVATION_STRING. And if I have PrivateKEY2 on the DESKTOP APP side (and use PublicKEY1 for encryption on SERVER side), I read that they could recover public key from it (PublicKEY1) and then do re-encryption after modification of ACTIVATION_STRING? Commented Aug 1, 2021 at 15:32
  • insted of PublicKEY1 above, should be PublicKEY2 Commented Aug 1, 2021 at 15:39
  • You cannot use a private key to encrypt a message, but you can use a private key to digitally sign a message. If the server signs the message using PrivateKey2, then the desktop app can verify the signature using PublicKey2. If the activation_string is modified anywhere in transit, this will break the signature, so it will be detected. Public keys are used to encrypt messages and verify digital signatures. Private keys are used to decrypt messages and create digital sign messages. I think a digital signature is what you are looking for.
    – mti2935
    Commented Aug 1, 2021 at 16:17
  • 4
    This is bad design on several levels. Not only are you reinventing a few wheels, it won't be effective as a license control. Why swap the keys around? Why not have the client generate a keypair and send the server the public key? Your ACTIVATION_STRING is stored on the client, which means it is knowable by the user on that client.
    – schroeder
    Commented Aug 1, 2021 at 16:50

2 Answers 2

2

You don't encrypt with a private key. You sign the message with one. One of the biggest misconceptions that I have seen here is that you can perform authentication of message by encrypting with a private key, and verified by decrypting with a public key. The problems are many, here are a few:

  1. You don't decrypt with a public key. If some message can be recovered by using some publicly available information, it is not encryption.

  2. BECAUSE, the goal of encryption is confidentiality. You encrypt the data so that only the one that owns a legitimate key can read it. It does not necessarily care about authentication or unforgeability. Digital signatures, on the other hand does not care about hiding any information and are designed to be unforgeable under chosen message attacks etc. (which means the attacker is assumed to be able to get signatures for messages of her choice from the legitimate owner) while encryption goes for semantic security (IND-CPA) or IND-CCA, (the attacker being unable to distinguish between ciphertexts of different plaintexts). One does not automatically imply the another.

  3. Not all schemes allow both signatures and encryption schemes in similar ways but the question was about RSA so I will leave it here. But you should know that RSA encryption and RSA signatures are not the same algorithms even though they share the mathematical core

1

Beware. Private and public keys are theorically equivalent, so nothing prevents you for using the private key to encrypt (and have it to be publicly knows) and the public key to decrypt (and try to keep it secure).

But real life implementations do make a strong difference. It is common that the public key can be computed from the private one! That means that if you give someone else a private key, they will also know the public one, which somehow defeates the whole process of crypting.

That means that you must use your private key to prove that you are the author/sender of some data (you sign it) or the repipient public key to encrypt that piece of data (only the recipient will be able to decrypt).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .