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
Related
everybody.
Is it possible to perform public key encryption flow for elliptic-curve cryptography?
https://en.wikipedia.org/wiki/Public-key_cryptography
I need to implement the following scenario:
Alice generates a message.
Alice encrypts it with Bob's public key.
Alice sends a message to Bob (via an insecure channel).
Bob gets the message.
Bob can decrypt this message only with his private key.
I can't find a proper method inside the tweetnacl lib (https://github.com/dchest/tweetnacl-js). Could somebody can direct me in the right direction?
Thank you in advance.
You should be looking for an ECIES implementation. Here is a random JavaScript library that seems to support it.
Elliptic Curves do not support a encryption primitive like RSA does. There is EC ElGamal but is not worth it due to the small key sizes and the amount of overhead of ElGamal.
To use curves with encryption you need to use hybrid encryption. ECIES is hybrid encryption: offline ECDH key agreement together with symmetric encryption performed using the derived secret key.
Note that ECIES is not well standardized. You may have to choose your own key derivation function, stream cipher or block cipher and mode of operation. For the key derivation method you could choose HKDF where available. AES in GCM mode seems a sane choice today for the cipher (the 12 byte IV may be set to zero or to a value derived from the "shared secret" as well). Libraries that support ECIES will probably have their own idea on what ECIES should look like, but beware of compatibility issues...
Isn't the encryption method in the documentation that you linked to for tweetnacl-js?
https://github.com/dchest/tweetnacl-js#naclboxmessage-nonce-theirpublickey-mysecretkey
nacl.box(message, nonce, theirPublicKey, mySecretKey)
Encrypts and authenticates message using peer's public key, our secret key, and the given nonce, which must be unique for each distinct message for a key pair.
Returns an encrypted and authenticated message, which is nacl.box.overheadLength longer than the original message.
You would use the recipient's public key as the third argument to the above function. You would use your own private key as the fourth argument. The library takes care of message integrity by creating a signature of the encrypted message, signed by your private key.
I will suggest you go to an easy library that makes the work for you, I specially like the python ecdsa module (https://github.com/warner/python-ecdsa), is easy and not complicated. Also read about how EC works will help you in make your decision.
I'm trying to understand how JWT is implemented in a codebase that I'm reviewing. I read this and this
However, it seems in this codebase, the client has the private AND public key... It has the public key of the server and its own private key (I assume the server has the corresponding private key). Why is this necessary? Shouldn't the client only need the public key and the server only needs the private key? If the client is encrypting a message, can't it use the public key to encrypt it and the server just needs the private key to decrypt it? Conversely, can't it decrypt encrypted messages from the server with its public key? Why would the client need two sets of public and private keys?
From the reading:
To create a digital signature, signing software (such as an email program) creates a one-way hash of the electronic data to be signed. The user's private key is then used to encrypt the hash, returning a value that is unique to the hashed data. The encrypted hash, along with other information such as the hashing algorithm, forms the digital signature. Any change in the data, even to a single bit, results in a different hash value. This attribute enables others to validate the integrity of the data by using the signer's public key to decrypt the hash. If the decrypted hash matches a second computed hash of the same data, it proves that the data hasn't changed since it was signed.
What is the differnce between the hashed data and encrypted data? Why do you need to hash it first? Are hashed data encrypted?
Where doe that secon computed hash come from? If the decryptor is attempting to apply the public key to the encrypted data... how does it know it succeeded? What does it compare it to? Where does that comparison hash come from?
JWT is signed (not encrypted) with the private key of the sender. jWT content can be encrypted optionally using JWE.
A symmetric key is used to sign and verify. With an asymmetric key pair, the message is signed with private key and verified with the public.
A digital signature protects the message against alterations and identify the sender. An asymmetric key allows the receiver to verify the signature using sender's public key without compromise the private key
JWT signing can be used both in client or server side depending on the purpose. For example, in an authentication flow
client side: API requests, where the server validates signature with public key uploaded during registration
server side: issue tokens to final users after presenting credentials
Internally, a digital signature involves several cryptographic operations, digest the message, encrypt the hash and add the algorithm identifier. But you do not have to worry about this because all programming languages support it
I tried to explain JWT&digital signatures in a general way instead of answering your specific questions. I probably have left some. Please comment
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 have a follow up question to Given a private key, is it possible to derive it’s public key?
Are the public and the private keys the 'same' (in the sense that you just choose to make one public) or can you do more with the private key than with the public key?
EDIT - to better state my question:
When the two keys are generated, could I just randomly choose one of them to be the public key?
Some paper descriptions present roles of public and private keys as quite symmetrical but you definitely can't swap roles of private and public key in real world.
Common usage:
the public key must be used for encryption and verifying signature
the private key must be used for decryption and signing
There is several reasons for that:
you don't want to leave a choice to the user as to which key should be published and which not. The public key is published worldwide and you can consider it as your public identity. The private part is needed when you have to prove to someone else that you have more insight than others about this identity: you can read messages sent to it, you are able to sign messages that can be verifyed by anyone who knows your public id. If what part of public/private key to publish were left to the user you'll end end with users publishing both. But that's not the main reason.
when you have private keys, you really have both keys every common implementation I know offer tools to extract public keys from private files. That's true for pgp, gpg, openssl. It means so called private key files store both private and public keys as described in algorithms. That's by design.
For exemple with openssl the sequence of commands to generate a RSA key pair can be:
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
It should be clear enough that the first command generate both keys in the private key file and that the public key is merely extracted from it.
The consequence is that if your private key is ever compromized, both your keys would be compromized. The other way around is secure, you can't deduce the private key if you know the public key neither from the file nor from a mathematical attack.
encryption with private key is mathematically weak: well, the previous point is already enough, but some devious users could be considering using asymmetric cryptography
keeping both keys hidden for exchanging data. Don't, use symmetric ciphering if you want to do that kind of exchanges. Yes it is possible to crypt a message using private key and decrypt it using public one (that's basically what is used for signing, but the use case is different as you also have initial message). Internal parameters of the two keys are not the sames and all the strongness of cryptography has been prooved only for the usual direction and common usage.
It really depends on what you call "private key." In almost every practical sitation, the sender knowing the private key also knows the public key. It provides others with its public key so it needs to know it. So in essence, that "private key" will contain "public key" information or at least it can be derived from it.
Generally, you cannot swap private and public keys. In fact, they are not always of the same type (depending on the cryptosystem used). For instance, in ECDSA, your public key is a two-dimensional "point" on an elliptic curve, whereas your private key is a number.
From http://www.webopedia.com/TERM/P/public_key_cryptography.html:
A cryptographic system that uses two
keys -- a public key known to everyone
and a private or secret key known only
to the recipient of the message. When
John wants to send a secure message to
Jane, he uses Jane's public key to
encrypt the message. Jane then uses
her private key to decrypt it.
An important element to the public key
system is that the public and private
keys are related in such a way that
only the public key can be used to
encrypt messages and only the
corresponding private key can be used
to decrypt them. Moreover, it is
virtually impossible to deduce the
private key if you know the public
key.
No. That is the idea of generating a pair of keys in PPK world. You typically encrypt with the public key and decrypt with the private key. So you'd share the public key with your friends and ask them to use it when they send you their bank account number.
i have been using PGP. I need to safely store our PGP keyring for our application that will be processing some pgp files. Can I believe that the PGP is Asymmetric cryptography and i should be able to store the information for keyring in a key container?
PGP is a hybrid cryptographic system i.e it uses a mix of public/private asymmetric and standard symmetric encyption/decryption. It generates a unique session ID which it uses to encrypt the data it then encrypts the session ID with your public key. It then adds the asymetric encrypted session ID to the symmetric encrypted data to produce the final ciphertext
For decryption, the private key is used to decrypt the session ID and then standard symmetric decryption to retrieve the plain text.
PGP stores two sets of keyrings - public keyrings and private keyrings.
So if you shipped the private keyring with your app then anyone could use the private key to decrypt the pgp files.
Public/Private key security is not a magic bullet it still relies on the user keeping their private key or keyrings safe
Here's a good link on how PGP works in more depth
You should check and see if there is a OS-level keystore to use for that sort of thing. Rolling your own solution is error-prone. Besides, why re-invent the wheel if you don't have to?