I am working on a method for licencing a software for distribution.
All the .exe distributed will have a public key.
Public key will be same for all distributions, which will be used to encrypt licencing information and generate a licence file.
The distribution will be supplied with a private key(serial key) which will be used to run the software.
Private key will be different for all distributions.
can anyone suggest any algorithm to which can encrypt with a single public key
and decrypt with different private key.
Here is the link which i found similar to this topic but cant figure out how to implement.
as stated in your link by Artjom;
Let's say multiple recipients have (a different) private key and all
of them can decrypt data encrypted with the same public key. You
should ask yourself, how can the different private keys be generated
to arrive at the same public key, but where all the recipients
wouldn't know the private key of each other.
Actually, he tries to say, this construction would be impossible.
And again in your link Panco noted; the questions;
I suspect you need to think more about the security goals (and
nongoals) of the system. The cluster head sends a message; who must be
able to read the message (e.g. the intended recipient)? Who must not
be able to read the message (e.g. random third parties)? Who don't you
care whether they can or cannot (e.g. the cluster head itself)? Also,
this is an ad hoc network; how do nodes join the cluster? Is there
some sort of introduction protocol (where keys can be exchanged)?
This is your solution;
Depending on the answers, a purely symmetric system may be the Right
Thing.
Related
In asymmetric encryption it is quite common to publish your public key to others. With the public key everyone can verify signatures created with the according private key.
So why do crypto-currencies like bitcoin not simply use the public key as the output of a transaction directly?
Bitcoin is instead using a so called address. What is the reason instead of just using the curve25519 public key?
There are basically two advantages to publishing an address, i.e., a RIPEMD-160 hash of the public key, instead of the public key directly:
The hash is only 160 bits compared to 256 bits of public key, so we safe about 1/3 of the space that we'd use when directly using public keys. This is both data transferred and stored at the endpoints. While the transferred size is pretty clear, storage comes in two forms as well: UTXO set size and on disk size.
Some limited protection against ECDSA being broken: should it become computationally feasible to create a signature given a public key, because of a weakness being discovered, we can avoid all funds being stolen by having this level of indirection. Assuming that it takes a while to generate a valid signature we can switch the signature algorithm, and the owners in possession of the private key still have a timing advantage w.r.t. an attacker, which would have to grab the public key from the wire, turn around and quickly compute a signature to a competing transaction.
I thought this would be a simple matter but it looks like webcrypto api doesn't provide a way to take a private key and generate its public key counterpart.
Is this true? Or am I missing something?
The reason I'm trying to do this is because I want to transfer the keypair and trying to reduce the total size. It would be great if I can just export the private key and later retrieve both of the pairs.
WebCrypto does not provide a mechanism to derive the public key from a private key.
It is technically possible with the RSA cryptosystem but not necessarily others (see Given a private key, is it possible to derive its public key?) you are only missing e which is generally could be brute forced/guessed (it is usually 65537).
Migrating private keys is something you do not want to do often if at all, every place a software key exists it may leave a remnant (page file, etc) that could be used to discover key later.
If you make the private key exportable (you do not want to do this for security reasons -- see above why) then you could write javascript to do this.
In short, the space savings is probably not worth the complexity and security consequences.
I have recently been working with some p12 files storing both private and public keys. Being far from a cryptography expert, I started pondering whether storing a public and private key being stored together in the same archive (and then transferred over wire) defeats the whole purpose of the keys.
There's nothing wrong storing a public key along with the private key in a file. It all depends on the intent of this.
If you only wanted to send the public key to a third party, then by sending your private key you give them a way to break the public key mechanism. This is insecure, and you should throw away your keys as have they don't have any values now.
If the transfer is part of your infrastructure, and the transfer happens securely, and you fully expect this file to be private on the destination, then there's nothing wrong storing them as one file.
Most frameworks will know how to use a single private/public file properly, and would only disclose the public part to a third party and keep the private part internal.
Whether to distribute private keys or not depends on your particular needs. Normally they are kept secret and not distributed more than needed (almost never).
Technically it's possible to add a certificate without a private key into PKCS#12 container, but this doesn't make much sense because other formats are more practical for distributing just certificates. And if you are adding a private key just because some software works only with PKCS#12 format and you don't know how to avoid putting the private key there, this is a mistake - you should not do this.
Now, safety of data in PKCS#12 file depends on what encryption algorithm is used. Previously (in older versions of Windows) 40-bit encryption was used by default. 40-bit is not secure, that's for sure. Newer versions support 3DES encryption - it's much stronger.
I'm trying to implement licensing system for a software to prevent piracy.
For this I need to read a license file within the application, and I need to make sure this file is written by the owner company.
Asymmetric cryptography has good potential for this aim, but in other way around!
Asymmetric cryptography algorithms, like RSA, give you a Public key and a Private key which are used as follow:
Private keys are used to decrypt.
Public keys are used to encrypt.
But I need them like this:
Private keys to be used to encrypt.
Public keys to be used to decrypt.
A simplistic idea would be to switch the role of public and private keys, but there are posts saying that in RSA public keys can be generated from private ones which make this idea impractical.
So here's my question: Is there any asymmetric cryptography with reversed key roles?
If speaking about RSA public/private key pair can be used in both cases you described. When you use private key to encrypt then public key decrypts and vice-versa.
As you said public key can be derived from private key but not the other way.
If you want to prove the origin of licensing file, use RSA in signature mode. In signature mode a hash is computed from the data you want to protect and then encrypted using private key. The result -the digital signature - is appended to the protected data.
Verification process starts by decrypting the signature which gives you the hash. Then compute hash value from the data. Computed and decrypted value shall be the same.
There are a lot of libraries providing comfortable way of signature creation and verification. You can choose depending on the platform you use for your application development.
http://en.wikipedia.org/wiki/Digital_signature
I am doing an activation server which will enable users to activate their software. The problem is that they own the public key.. the verification method needs the public key to check signature of the license file. My concern is that someone could generate their own license file using two key (public and private) and then change the public key on the client which would spoof his current license.
Is there any way of avoiding this ? Where should the public key be stored ? You have to take into consideration that the checkup is done on client and the signature is created on server.
Thanks.
Don't use a licensing file. Each time the application is started, have it connect to a licensing server to validate it.
So? The whole point of a public key encryption that the decryption can only be done by the key's counterpart. If you app encrypts something with the user's public key and sends it to your server, they can't decrypt that data packet, because only the private key you possess will work.
If the user's license file is encrypted with your private key, only their public key can decrypt it. This way, even if the license file gets shared, you'd be able to track down who shared it because only one user's key would've been able to decrypt it.