[encryption] What is the difference between encrypting and signing in asymmetric encryption?

What is the difference between encrypting some data vs signing some data (using RSA)?

Does it simply reverse the role of the public-private keys?

For example, I want to use my private key to generate messages so only I can possibly be the sender. I want my public key to be used to read the messages and I do not care who reads them. I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these. I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

Is signing useful in this scenario?

What is the difference between encrypting some data vs signing some data (using RSA)?

Encryption preserves confidentiality of the message ("some data"), while signing provides non-repudiation: i.e. only the entity that signed it could have signed it. There are functional differences as well; read on.

Does it simply reverse the role of the public-private keys?

Absolutely not. The use of the same private keys for signing and decryption (or, likewise, the same public keys for verification and encryption) is frowned upon, as you should not mix purposes. This is not so much a mathematical issue (RSA should still be secure), but a problem with key management, where e.g. the signing key should have a shorter live and contain more protection before it is used.

For the same message, you should use the senders private key for signing and the receivers trusted public key for encryption. Commonly sign-then-encrypt is used otherwise an adversary could replace the signature with his own. Likewise you should use the private key of the receiver for decryption and the trusted public key of the sender for verification.

Furthermore, you should understand that signature generation doesn't use "encryption with the private key". Although all RSA operations are based upon modular exponentiation, the padding scheme is entirely different for signature generation. Furthermore, the public key has entirely different properties than the RSA private key in all practical uses of RSA.

For example, I want to use my private key to generate messages so only I can possibly be the sender.

That's non-repudiation property, which can be achieved by signing.

I want my public key to be used to read the messages and I do not care who reads them.

The public key should be considered known by all. If you want everybody to read the messages, then you simply do not encrypt them.

Signing will generally not influence the content of the message. The message is is considered separate from signatures. Officially such signatures are known as "signatures with appendix" where the appendix is the message. It's a bit weird name as the message is considered more important than the signature over it, but yeah. Only few signatures offer (partial) message recovery; they are not used much anymore and are generally considered deprecated.

Note that signature protocols such as CMS may deploy a container format that includes both the message and the signature. In that case you'd need first get the - still unencrypted - message out of the container, much like unzipping a file from a plain .zip archive. So the message may be hidden from view and cannot be directly used in that case.

I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these.

Encryption is used to achieve confidentiality. In the past RSA signature generation was often thought of as "encryption with the private key". However, the operations are quite different as explained above, and the later standards desperately try and separate encryption and signature generation.

I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

Yes, this is called establishing trust in the public key. However, protecting your program code is very different from protecting messages. You can perform code signing but then you'd need something to check the signature outside of your code. There are operating systems that offer this.

There is Microsoft Authenticode for instance. Application stores like the iStore and Android app store may or may not use code signing, but they offer some reassurance that your application isn't cloned or at least not cloned within the store. Cryptography is not always the solution after all.

Keeping your code from being cloned / altered at all is much harder, and you'd be solidly in DRM territory if you go that way.

Is signing useful in this scenario?

Yes, absolutely. It can certainly help making sure that the messages were only signed by you, if there is trust in the public key. If it can be helpful for authenticating your application code / integrated public key depends entirely on the environment that you expect to run the code in.

Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.

Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.

Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.

Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.

So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).

In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".

So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)

There are two distinct but closely related problems in establishing a secure communication

1. Encrypt data so that only authorized persons can decrypt and read it.
2. Verify the identity/authentication of sender.

Both of these problems can be elegantly solved using public key cryptography.

I. Encryption and decryption of data

Alice wants to send a message to Bob which no one should be able to read.

• Alice encrypts the message with Bob's public key and sends it over.
• Bob receives the message and decrypts it using his private Key.

Note that if A wants to send a message to B, A needs to use the Public key of B (which is publicly available to anyone) and neither public nor private key of A comes into picture here.

So if you want to send a message to me you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.

II. Verify the identity of sender (Authentication)

Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.

But what if I am sitting between Alice and Bob, introducing myself as 'Alice' to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob's private key) I am hijacking the entire conversation between them.

Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?

• Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
• Bob receives it and verifies it using Alice's public key. Since Alice's public key successfully verified the message, Bob can conclude that the message has been signed by Alice.

Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

A signature is a hash of your message signed using your private key.

Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.

Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.

As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.

Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.

In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.

So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.

A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.

Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.

However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.

So:

• To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
• To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.

Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

A signature is a hash of your message signed using your private key.

Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.

Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.

So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).

You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.

Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

A signature is a hash of your message signed using your private key.

Answering this question in the content that the questioners intent was to use the solution for software licensing, the requirements are:

1. No 3rd party can produce a license key from decompiling the app
2. The content of the software key does not need to be secure
3. Software key is not human readable

A Digital Signature will solve this issue as the raw data that makes the key can be signed with a private key which makes it not human readable but could be decoded if reverse engineered. But the private key is safe which means no one will be able to make licenses for your software (which is the point).

Remember you can not prevent a skilled person from removing the software locks on your product. So if they have to hack each version that is released. But you really don't want them to be able to generate new keys for your product that can be shared for all versions.

Python The PyNaCl documentation has an example of 'Digital Signature' which will suite the purpose. http://pynacl.readthedocs.org/en/latest/signing/

and of cause NaCl project to C examples

You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.

Answering this question in the content that the questioners intent was to use the solution for software licensing, the requirements are:

1. No 3rd party can produce a license key from decompiling the app
2. The content of the software key does not need to be secure
3. Software key is not human readable

A Digital Signature will solve this issue as the raw data that makes the key can be signed with a private key which makes it not human readable but could be decoded if reverse engineered. But the private key is safe which means no one will be able to make licenses for your software (which is the point).

Remember you can not prevent a skilled person from removing the software locks on your product. So if they have to hack each version that is released. But you really don't want them to be able to generate new keys for your product that can be shared for all versions.

Python The PyNaCl documentation has an example of 'Digital Signature' which will suite the purpose. http://pynacl.readthedocs.org/en/latest/signing/

and of cause NaCl project to C examples

There are two distinct but closely related problems in establishing a secure communication

1. Encrypt data so that only authorized persons can decrypt and read it.
2. Verify the identity/authentication of sender.

Both of these problems can be elegantly solved using public key cryptography.

I. Encryption and decryption of data

Alice wants to send a message to Bob which no one should be able to read.

• Alice encrypts the message with Bob's public key and sends it over.
• Bob receives the message and decrypts it using his private Key.

Note that if A wants to send a message to B, A needs to use the Public key of B (which is publicly available to anyone) and neither public nor private key of A comes into picture here.

So if you want to send a message to me you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.

II. Verify the identity of sender (Authentication)

Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.

But what if I am sitting between Alice and Bob, introducing myself as 'Alice' to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob's private key) I am hijacking the entire conversation between them.

Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?

• Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
• Bob receives it and verifies it using Alice's public key. Since Alice's public key successfully verified the message, Bob can conclude that the message has been signed by Alice.

You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.

Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.

Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.

As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.

Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.

Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.

Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.

You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.

In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.

So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.

A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.

Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.

However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.

So:

• To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
• To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.

In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".

So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)

Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.

Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.

Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.

Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.

So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).

In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".

So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)

What is the difference between encrypting some data vs signing some data (using RSA)?

Encryption preserves confidentiality of the message ("some data"), while signing provides non-repudiation: i.e. only the entity that signed it could have signed it. There are functional differences as well; read on.

Does it simply reverse the role of the public-private keys?

Absolutely not. The use of the same private keys for signing and decryption (or, likewise, the same public keys for verification and encryption) is frowned upon, as you should not mix purposes. This is not so much a mathematical issue (RSA should still be secure), but a problem with key management, where e.g. the signing key should have a shorter live and contain more protection before it is used.

For the same message, you should use the senders private key for signing and the receivers trusted public key for encryption. Commonly sign-then-encrypt is used otherwise an adversary could replace the signature with his own. Likewise you should use the private key of the receiver for decryption and the trusted public key of the sender for verification.

Furthermore, you should understand that signature generation doesn't use "encryption with the private key". Although all RSA operations are based upon modular exponentiation, the padding scheme is entirely different for signature generation. Furthermore, the public key has entirely different properties than the RSA private key in all practical uses of RSA.

For example, I want to use my private key to generate messages so only I can possibly be the sender.

That's non-repudiation property, which can be achieved by signing.

I want my public key to be used to read the messages and I do not care who reads them.

The public key should be considered known by all. If you want everybody to read the messages, then you simply do not encrypt them.

Signing will generally not influence the content of the message. The message is is considered separate from signatures. Officially such signatures are known as "signatures with appendix" where the appendix is the message. It's a bit weird name as the message is considered more important than the signature over it, but yeah. Only few signatures offer (partial) message recovery; they are not used much anymore and are generally considered deprecated.

Note that signature protocols such as CMS may deploy a container format that includes both the message and the signature. In that case you'd need first get the - still unencrypted - message out of the container, much like unzipping a file from a plain .zip archive. So the message may be hidden from view and cannot be directly used in that case.

I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these.

Encryption is used to achieve confidentiality. In the past RSA signature generation was often thought of as "encryption with the private key". However, the operations are quite different as explained above, and the later standards desperately try and separate encryption and signature generation.

I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

Yes, this is called establishing trust in the public key. However, protecting your program code is very different from protecting messages. You can perform code signing but then you'd need something to check the signature outside of your code. There are operating systems that offer this.

There is Microsoft Authenticode for instance. Application stores like the iStore and Android app store may or may not use code signing, but they offer some reassurance that your application isn't cloned or at least not cloned within the store. Cryptography is not always the solution after all.

Keeping your code from being cloned / altered at all is much harder, and you'd be solidly in DRM territory if you go that way.

Is signing useful in this scenario?

Yes, absolutely. It can certainly help making sure that the messages were only signed by you, if there is trust in the public key. If it can be helpful for authenticating your application code / integrated public key depends entirely on the environment that you expect to run the code in.

Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.

Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.

As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.

Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.

In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.

So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.

A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.

Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.

However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.

So:

• To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
• To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.

Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.

Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.

In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".

So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)

Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.

Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.

As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.

Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.

Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.

Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.

So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).

Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts

A signature is a hash of your message signed using your private key.