Confuse encryption with public and private keys (which are used for encryption)

Question

I make a licensing system when clients request a license from my server, and I send them a license if it is allowed to have one.

On my current system, I encrypt the license with a separate private key and include the public key in the client application that they use to decrypt the license. He works!

Others told me that I should encrypt with the public key on the server and distribute the private key to clients. I searched the Internet and see that sometimes they use the private key for encryption, and sometimes they use the public key for encryption.

In this case, what should I do?

Answer 1

Others told me that I should be encrypting the public key on the server and distributing the private key to the clients.

These people are wrong. The private key of the name implies that this is a personal value, that only you should have access to it.

In this case, what should I do?

Use digital signatures. Sign the license file with your private key and use your public key in your application to make sure that the signature in the license is received from you.

Answer 2

Congratulations, you just came up with the RSA signature. (Anyway, this is what you should use). To contact the public key system, you need to use the secret key once and the public key once, but RSA supports two different orders: 1) Encrypt with the public key, decrypt with private: the recipient does not know anything about the message source, but the sender knows that only the recipient (owner of the secret key) can read it. This is the classic "encryption". 2) “Encrypt” with the private key, then “decrypt” with the public. It is digitally signed and provides authentication. Anyone can read the message, but only the owner of the private key could send it.

Assuming your license is configured for the client (it can be as simple as including a copy of a random number created by the client), then it is useless to anyone else, but the client can be sure that the server sent it.

Symmetry is not quite so accurate in practice; different modes of operation have different flaws and gotchas, so the implementation, as a rule, is significantly different, but the general idea.

One of the first and most important lessons of cryptology is understanding authentication and when to use it. This was necessary, at least as often as encryption, and not knowing when to use it, leaving you at Midvale School for the Gifted .

Answer 3

If you encrypt what should be read by only one recipient, then you encrypt the recipients with the public key, and they use their private key to read it.

If you encrypt for multiple recipients, you can encrypt with your private key and distribute your public key to the ones you want to read. This is usually called “signing,” since anyone who has access to your public key can read it, so this is not a form of private communication.

A general more reliable solution for your application will be to create a key pair for each installation, send the public key that it generated back to the server, which you will then use for encryption so that only one installation can use the license you created (by decrypt it using the private key).

Answer 4

At least in a typical public key encryption algorithm (for example, RSA), in fact, there is no significant difference between public and private keys. When you create keys, you get two keys. You keep one private and publish the other, but it doesn’t matter which one you publish and which one you save.

Everything that you encrypt with one key can be decrypted with another key. For ordinary purposes, you publish one key that allows anyone to encrypt what you can decrypt. From a technical point of view, the opposite works fine: if you encrypt something with your private key, anyone with a public key can decrypt it. This is usually used for things like signing verification (i.e. anyone with a public key can verify that the signature should have been created using the private key). Usually you want to use separate key pairs for encryption and signing.

For your case, it opens some question that you really are going to execute. You can, of course, encrypt some data necessary for using the program, so the user needs a key to decrypt and use the program, but if the user is ready to provide a copy of the code to an unauthorized person, they probably will not hesitate to give a copy of the key to them. Thus, even though encryption / decryption will do the job, it is unlikely to provide real protection.

A more typical licensing scheme is tied to a specific IP address, so you do something like encrypt the IP address, and then use the result as a key to decrypt the data needed to use the program. If the IP address is incorrect, the data is not decrypted correctly and the program does not work. As long as the user has a static IP address, this may work well, but will cause problems with DHCP.

My immediate advice would simply not do this at all. If you insist on it anyway, don't do it yourself - get something like FlexNet to handle for you. You are better off without it, but at least in this way you will get something similar, and you will not spend time and effort on this that could be aimed at improving goals, such as improving your software.

Answer 5

If you use public (asymmetric) encryption, you always encrypt the recipient’s public key, which decrypts your private key. For digital signatures, you sign your private key, and the recipient verifies the signature with the public key.

The question is, how do you create a secure DRM system? If you use encryption and provide the recipients with a private key, they can distribute either the key or the decrypted content. If you use signatures, they can simply strip away part of your program’s signature verification.

The answer is that this is not possible. The concept of DRM is fundamentally wrong.

Answer 6

Hope this Wikipedia link helps. PKI is based on mutual trust. However, the private key must be protected by the owner. The public, as the name implies, is open to all. All architecture is made by inorder to help the scenario mentioned above in your question.