Tag Info

5

That is not a bad method of doing a license key; an attacker would certainly be unable to generate a signature that would validate with his computer's window product key. On the other hand, this approach may be overkill. The easiest way to attack this system would be to modify the program to skip (or ignore) the signature validation; hackers have both the ...

4

RSA signatures are designed in a way that only the owner of the private key can generate valid signatures, no matter the message size/length. (There is no proof of this, but RSA would be considered broken if this was not the case.) Your signature is actually a certificate saying The program is allowed to run on a computer with Windows-ID xxx, and if your ...

4

Your second solution seems to be quite close to optimal. You perhaps do not need both nonce and timestamp unless timestamp is part of the payload. Anyway, the structure $$N||P,$$ where $N$ is 48-bit nonce and $P$ is a 32-bit payload seems sufficient for your needs, as you are unlikely to generate more than $2^{48}$ product keys. To ensure authentication ...

3

You're somewhat on the right track. A standard way to do this would be using an RSA sign/verify scheme. On the server, user-specific and license-specific data is concatenated into a string and signed with the private key. In the software, the signature is verified with the public key. The public key can not be used to create valid signatures, it can only ...

3

Since no-one else has mentioned this yet, I guess I should point out that it is possible to use public key signature schemes like (EC)DSA to generate software registration keys. For example, Microsoft apparently uses this for their product keys. Basically, you embed the public key in your program and keep the private key, which you'll use to sign whatever ...

2

To begin with, let's assume that the attacker cannot extract the AES key from your software. That means the best they can do is a chosen-plaintext attack on AES: choose a block $Y$, request its encryption $Z$, repeat as many times as desired and try to use the results to figure out something useful about the encryption of other plaintext blocks. Since AES ...

2

There a number of ways of using block ciphers to produce short ciphertexts: see this post and this post. A general technique is format preserving encryption (FPE). I am not clear on the details of how you want to use it. Is the secret key being distributed with the software so that it can encrypt the username for comparison to the product key you supply?

2

An important point is that you should make sure the fields are all fixed-length, so that you can recover each of them from the concatenation of all of them. You can just let magic be an all-zero string. $\:$ (It does not need to be kept secret or chosen randomly.) The "problems with the use of ECB mode" are not relevant to your proposed scheme. However, ...

2

Crypto.SE is not the ideal place for this question, but I will answer this. Android keychain only stores keys and certs. You will have to manage security of activation status by your own. If the data is sensitive DO NOT store it in the SQLite database in plain text. I can recommend two methods: Method 1: Encrypt data and store encrypted data in the ...

1

embedding a symmetrical (AES) key in your software really is pointless - an attacker could easily extract the key and generate their own software license key, or worse, create a small program (a crack) that allows other users to generate their own license keys I recommend RSA - generate 'Z' (as per your question) by signing the data 'Y' with a private key, ...

1

If it's not necessary to think about security, etc, you could do the following: the user sends you the username you calculate the MD5 hash of his same + some salt you choose. Let's say, you do calculate MD5(username + "mySecretSalt"). Let's say the result is "5aa63b07a1a9f0b33d88e719e4cc9f86" you take only the first 4 hex characters. For example, ...

Only top voted, non community-wiki answers of a minimum length are eligible