I'm almost a newbie about RSA encryption, so my question could it be banal. I'm beginning to create a licensing system for my software. I need to distribute a crypted license file to many customers. I was thinking to use RSA public key to encrypt license file (with OAEP padding or PKCS#1 v1.5). The software that will be licensed to customers will have inside the private key in order to be able to decrypt the license content. Now the question is if can be possible to know the public key giving the encrypted file, the private key and the final plain text. This because an hacker could know these data because are all inside the distributed software.

In other words I need a crypto algorithm that use two different keys. One pw for encrypt the data, and another to decrypt the data. And where will not be possible to obtain the encrypt password giving the decrypt password and crypted text.

  • $\begingroup$ Are you sure you want encryption? Encryption offers confidentiality, however in your case it doesn't, because the decryption key is basically public. It sounds to me like you want integrity and authenticity, which would mean a signature scheme would give you what you want. $\endgroup$
    – Maeher
    Commented Jun 16, 2012 at 11:54
  • 1
    $\begingroup$ Keep in mind that the common way to attack license checks is to patch the conditional jump at the end of the check. So the program will always execute the code path for successful checks. $\endgroup$ Commented Jun 16, 2012 at 12:47
  • $\begingroup$ @ Maher : I didn't wrote that the decryption key is public, the decryption key will be know to the licensed application. The risk is that could it known cracking the licensed software. @Hendrik : yes I know these techniques, but this will not be possible in my software (or will not worth the effort). $\endgroup$
    – Carlo
    Commented Jun 16, 2012 at 13:08
  • $\begingroup$ If the key is anywhere but safely stored on your own machine, it needs to be considered public. $\endgroup$
    – Maeher
    Commented Jun 16, 2012 at 13:36
  • $\begingroup$ @Maeher I think he means using the private key for encryption and the public key for decryption, which is possible and similar to signing. $\endgroup$ Commented Jun 16, 2012 at 13:38

3 Answers 3


The answer to the question in the title is: Yes, it is possible to use RSA signature for software licensing (e.g. in the context either RSASSA-PKCS1-V1_5 or RSASSA-PSS in PKCS#1 as defined here, or any of the three schemes in ISO/IEC 9796-2 free but partial preview). One minor issue is that, for a decent security level, what protects the license file will be much too big to be keyed in.

There are a lot of terminology errors in the body of the question:

  • What's wanted is distribute a crypted encrypted signed license file to many customers
  • What's needed is use the RSA public private key to encrypt sign that license file; in signature schemes with message recovery (e.g. ISO/IEC 9796-2) this will have the (perhaps desirable) side effect of making at least some of the signed content not directly intelligible, though recoverable without any secret information;
  • The software that will be licensed to customers will have inside the private public key in order to be able to decrypt verify the license content (and recover what portion of the signed information was not directly intelligible, if applicable)
  • The question is if it can be possible to know obtain the public private key giving given the encrypted signed file, the private public key and the final plain text signed data.

The short answer to that other question is: No, there is not a reason to worry that the private key (or anything allowing to generate new signed license files) could be obtained, provided the legitimate private key is kept and used securely, and was adequately drawn.

You'll get one private key to sign (and perhaps, with message recovery, make not directly intelligible some or all of) the data forming the license file, and an associated public key to verify the integrity (and perhaps, with message recovery, recover all) of that data; and where it will not be possible to obtain the private key (or some equivalent mean) given the public key and the data in any of its form.

On the other hand, no amount of cryptography will really prevent that someone skilled modify the software to bypass the license check, or allow the use of a license duplicated from an authorized one even if the software attempts to lock a license to a particular computer. Without temper-resistant hardware, the best you could do is that some portion of the software is unusable without access, at least temporarily, to a valid license to use that portion of the software.


Signing the license protects against Eve being able to issue licenses that the unmodified software will find valid. It does not, of course, prevent software from being modified to bypass the license check.


As Chris Smith noted, what you've done is stumble upon the way that RSA is typically used in signature schemes. In RSA, you can use a private key to encrypt a message, creating a ciphertext that can be decrypted with the public key. Successful decryption of this ciphertext proves that the message was encrypted with the correct key, which in this case was possessed by only one party, providing authentication and non-repudiation. (In practice, a hash of the message, instead of the message itself, is encrypted. This is primarily because RSA produces large ciphertexts and is rather slow.)

It's imporant to note that this "encrypt with the private key" trick takes advantage of the peculiarities of RSA, and is NOT a general solution for asymmetric algorithms.

At the end of the day, you need to think in terms of using a proven signature scheme (of which RSA is one) and distributing signatures and public keys rather than "encrypted" files and "private" keys. Keeping your security assumptions clearly defined will prevent you from accidentally screwing your crypto up -- something that's very common in homegrown DRM schemes.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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