-1

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

Bojan Vukasovic
  • 109
  • 1
  • 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 Aug 01 '21 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`? – Bojan Vukasovic Aug 01 '21 at 15:32
  • insted of `PublicKEY1` above, should be `PublicKEY2` – Bojan Vukasovic Aug 01 '21 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 Aug 01 '21 at 16:17
  • That is an option yes. But it would be even better if DESKTOP APP would not be able to see the message (since it will be delivered as a file). – Bojan Vukasovic Aug 01 '21 at 16:25
  • 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 Aug 01 '21 at 16:50
  • @schroeder thats why I asked for some alternatives. client is not a person, but executable. I know that any better reverse engineer can patch my executable, no mather what I do. I just wanted to make it more dificult. ACTIVATION_STRING is stored on client machine, but unencrypted only in runtime. I needed it to be encrypted in file (so user has less info what it is). Do you have some advice how to implement software licensing based on hardware info? – Bojan Vukasovic Aug 01 '21 at 22:06
  • Client is a *user agent*; software that operates on behalf of, and under the complete control of, a person. Unless you're shipping your software only on sealed tamper-resistant hardware, you have to assume your "attacker" (user) is monitoring every operation your software does, and can override it in real time (that's what debuggers are for, and no you can't reliably detect their presence). You're trying to make DRM, which is a well-known mire of failed attempts and user-hostility (nothing like restoring a dead drive from backups and then your expensive software telling you you're a pirate). – CBHacking Aug 01 '21 at 23:03
  • See Thomas Pornin's answer at https://security.stackexchange.com/questions/87325/if-the-public-key-cant-be-used-for-decrypting-something-encrypted-by-the-privat for some interesting reading on this subject. Pay particular attention to where he blames the `deleterious effects of post-Disco pop music` for much of the confusion around this subject. – mti2935 Aug 02 '21 at 12:52
  • "thats why I asked for some alternatives" -- you never ask for alternatives. You state "this is how it is going to work" and then ask " is there any problem for me using..." I know the client is not a person, that's why I said the client should generate a key pair. People don't do that. – schroeder Sep 01 '21 at 10:10
  • @schroeder I guess what I needed is more less the process of "JSON Web Tokens". That one seems to be nice way to generate keys. Data in -> sign with private key, and then the license will become data + signature which can be then checked with public key embedded in the DESKTOP app... – Bojan Vukasovic Oct 11 '21 at 14:06

2 Answers2

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

Manish Adhikari
  • 309
  • 1
  • 4
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).

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84