# Best cryptographic method to distribute license files

I will describe my problem high-level, and not ask a very specific cryptographic question, since I am open for general suggestions as well. So in my question I will only speak about "security keys" not about any specific algorithms or key types.

I have a License File A, which I need to distribute. On the client side, there is a License File decryptor within my program. The contents of A shall remain secret, so signing is not an option, it must be encrypted.

On server side I create the file and encrypt it. Then I send it via an insecure channel to the client side. The encryted data of A, which I send via this insecure channel, must not allow an attacker to deduce the client side key, nor the server side key, nor the plaintext contents of A. This unidirectional channel which transports an encrypted blob of data is the only communication method between client and server.

There are two levels of security breaches for me. The first one should be prohibited. The second one must be prohibited. The two breaches are:

1. An attacker is able to decrypt and read the contents of A.
2. An attacker is able to create its own version of A.

My question: How can I realize that?

Now on my thoughts:

What comes to mind is: I use a RSA public key on client side to decrypt A. I use a RSA private key on server side to encrypt A. The attacker should not know either of these two. But if he is able to extract the public key on client side, breach (1) happens, but he is at least not able to reach breach (2). If the private key would be on client side, the attacker would be able to create its own (public) key to create and encrypt A by himself.

Now I know that "encryption with the private key" seems to be a sentence which causes people from the crypto realm to throw up. I don't really understand the underlying mathematics, but I ask myself why it is not possible. When one "signs" a message with a RSA private key, then the same thing happens, no? -First we hash the message because we need the data to be encrypted smaller than the modulus. Then we encrypt the hash with the private key?!

So if the length of the message is the only limitation, why can't I just encrypt A chunkwise with my private key. Since its a secure algorithm, it should not matter how many small, separate encrypted data blobs I send via the insecure channel. Or even better, I encrypt the message with a AES_CBC Key and use the RSA Private Key just to encrypt the AES_CBC Key, which might already be as small as my message hash would be.

(Please don't delete this question as a "copy of question why it is not possible to encrypt with the private key", since I ask for how to deal with my scenario, not just this question.)

• 1.) License scheme depends on software architecture; 2.) apart from encryption, have you considered digital signature? 3.) How do you prevent B from colluding with A by sharing keys? Or do you consider that out of your scope? Oct 20, 2023 at 9:51
• @DannyNiu 1. The description of my scenario leave no dependencies open to the software architecture. 2. Yes, I have considered digital signature, but if you had read my question, you would see that in paragraph 2 sentence 3 I excluded it, since I need the contents of my file to be secret, if possible. 3. I don't know what you mean with B, since I never defined any object (B). Oct 20, 2023 at 11:45

How can I realize that goals (1) and (2) ?

You can't realize goal (1) [of secrecy of data deciphered by the software] with cryptography, RSA or other. A fundamental issue is that if your software can decipher, so can a skilled adversary with your software running on a computer they control.

If attacker is able to extract the public key on client side, breach (1) happens

Yes, that's one of several ways (1) can be breached. Note that "encrypt with private key" achieves nothing useful compared to symmetric encryption and a "secret" key that's in the software.

But attacker is at least not able to reach breach (2).

True, if done correctly and for the unmodified software. That's achieved by signature, a standard feature of asymmetric cryptography. This is why if asymmetric cryptography is used, the public key shall be on the client side.

Suggestion: the file is encrypted using symmetric cryptography, then the ciphertext digitally signed using the software issuer's private key. On the client side, the signature is checked using the public key in the software. Then the ciphertext is deciphered using the separate symmetric key in the software.

For the symmetric cryptography part, standards include AES-GCM, Chacha-poly1305, and many others.. For the signature standards, there are RSASSA-PSS, RSASSA-PKCS1-v1_5, EdDSA, and many others.

This is as safe against #1 as the programmer's ability to hide the symmetric key in the software, and avoid extraction of deciphered data. This is as safe against #2 as the programmer's ability to prevent the software from running if modified to remove the signature check (including modified to use a different public key).

I ask myself why "encryption with the private key" is not possible.

"Encryption with the private key" and "decryption with public key" is feasible with RSA (though not all form of asymmetric cryptography), but can't achieve what encryption and public imply. Public implies known to all, including adversaries; thus adversaries can decrypt, which is against the goal of encryption.

• "Suggestion: the file is encrypted using symmetric cryptography, then the ciphertext digitally signed using the software issuer's private key. On the client side, the signature is checked using the public key in the software. Then the ciphertext is deciphered using the separate symmetric key in the software." -Thats an amazing idea! Thank you. Oct 20, 2023 at 11:48
• Can we make this Q the canonical post we refer duplicates to, barring them having requirements non-trivally different from the ones here? Oct 20, 2023 at 12:07

If you want to protect the digital rights of your software, you can look for commercial DRM solutions. But if you apply overly much protection before your software has any market penetration, I doubt if your business could survive long. Many small start-ups instead provide their software as closed-source gratis ad-ware.

Asking for a DRM solution here, is not much different from presenting one here and ask if it's secure, which is off-topic, especially considering this type of question offer little value to others.

Some of the people asking this type of overly broad question show clear sign that they're confused of what they're doing. So I hope you can read my comment, and clarify your question and simplify it, to the best of your effort to make it answerable.

Now back to the technicals.

If you can protect to the best of your effort, a signing key, then you can make your users register themselves, and issue certificates (not necessarily x509, CMS is okay) that says (in some kind of binary encoding):

I the software vendor approve the said user to run my software.

Since the signing key is protected, your software will recognize bogus certificates and refuse to run. This is why I think your license doesn't necessarily need to be encrypted.

Of course, this leaves the software itself in plaintext.

If you want to encrypt your software and make your user pay for an decryption key, I can think of the following:

1. Make your user register a public encryption key (think ECIES, X25519)

2. Once they pay for some version of your software, send them a certificate with some encoded statement such as the one above, and encrypt the software executable file decryption key using the key your user registered.

My comment 3 regarding a B concerns following scenario: B is a friend of a paid user of your software A, and A shares the decryption key and user information with B allowing them the use your software, despite having not paid for it.

The only solution for this is either 1: make the software unusable offline and check the IP address of the running software (by making them ping a activation server periodically). Or 2: store the key and user info in a hardware security module (HSM) and offer that as part of your software installation medium.

• Thank you for telling that you deem the way I ask is a clear sign that I am confused of what I am doing. The targets of my DRM solution are very clearly defined and I am pretty sure that I know what I am doing from a software developers perspective. To ensure that it stays like that, I am asking this question. And since I read the answers of a lot of other similar questions before asking my own, I deliberately kept my question open instead of just asking "how to encrypt with a private key" – which was a justified point of criticism in other answers. Oct 20, 2023 at 11:43
• If this is enough for you to deduce that I am confused of what I am doing, then that’s a character problem of yours. Also: I am very sure that this type of question is of a lot of value to others. Obviously not the question, but the answers (except yours). It’s a very common problem/question in software development. Oct 20, 2023 at 11:44
• @Allgaeuer I admit my character is considered by some horrible. What I'm suggesting in the non-technical part of my answer is that, developer should focus on bringing value, and out-source the auxiliary. I've made a technical part consisting of a rough outline for you to consider, but details will have to be yours to work out. Oct 20, 2023 at 12:04
• @Allgaeuer Of course, if a software developer doesn't know what they're doing, they wouldn't be able to make money. But when the subject is cryptography, the warning on this MDN webpage says it all. And it points to crypto101.io which I think is nice. Oct 20, 2023 at 12:22
• Thank you for the second link. The document behind it seems well written and understandable without deep mathematical knowledge. Will read at the weekend. Oct 20, 2023 at 12:33