views:

1566

answers:

9

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?

+2  A: 

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!).

Doug Currie
In normal Asymmetric encryption, encryption is done with the recipients public key, not your private key.
Simucal
I fixed it for him.
slim
A: 

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

Signing you 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.

As for the algorithm used: this involes prime-numbers. I'd do a search on google for a better explanation.

Gerbrand
Can you comment on my use case? I want to use a private key to encrypt and a public key to allow anyone and everyone to decrypt.
Simucal
It's not true that all asymmetric encryption is based on prime numbers, it's just the most well-known example (RSA); there are other methods such as elliptic curve cryptography.
Michael Borgwardt
+1  A: 

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 encrypted by your private key.

John Nolan
+10  A: 

When encrypting, you use their public key to write message and they use their private key to read it.

When signing, you use your private key to write message's signature, and they use your public key to check if it's really yours.

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

This is signing, it is done with your private key.

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.

If you only need to know it to yourself, you don't need to mess with keys to do this. You may just generate random data and keep it in a database.

But if you want people to know that the keys are really yours, you need to generate random data, keep in it a database AND sign it with your key.

I would like to include my public key in my software to decrypt/read the signature of the key

You'll probably need to purchase a certificate for your public key from a commercial provider like Verisign of Thawte, so that people may know that no one had forged you software and replaced your public key with their.

Quassnoi
Not really see where you are going with the random data part. The data i'll be signing will be a name and expiration date. Their client will need to use the public to key verify the signature (I guess).
Simucal
+2  A: 

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.

Michael Borgwardt
+2  A: 

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.

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.
slim
+1  A: 

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)

devio
+1  A: 

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.

rjamestaylor
+2  A: 

I think there are mixed messages above. I was trying to achieve the same thing as Simucal was - i.e. I wanted to generate a licence key that holds important information about who can use the software and between what date ranges etc. But I don't want people to be able to amend that information to extend their licence period etc. My first approach was to use asymetric encryption, but despite some of the comments above, it appears that you can encrypt using either the public OR private key, BUT ONLY decrypt it using the private key. Therefore, in this scenario, you would have to store the private key in the system in order for it to decode and check the licence key... rendering the system pretty insecure because anybody could generate their own modified licence information and encrypt it using the public OR private key (one of which would be stored in the system binary files). The same security risk is attached to symetric encryption of course.

As many of the comments above point to, signing appears to be the way forward for this scenario, but I have yet to find a good example. Does anybody know of a tutorial or online demo that provides a run-through of such a method? Thanks, Chris

Chris