Using a public key system, a user may encrypt a portion of a document
using his or her private key. This message will later be decrypted by
the recipient using the sender’s public key. Assuming that the
sender’s private key is secure, the recipient can assume basic
authenticity of the encrypted portion of the document in that only the
sender holds the private key used to encrypt the message. Thus, the
encrypted portion of the message is said to have been “digitally
signed” by the sender.

I have a few questions about the following line:

This message will later be decrypted by the recipient using the
sender’s public key

Let's say I have the sender's public key. And let's say I have "satan's" public key also (which does not belong to the original sender).

I thought that the private key is used for signing and deciphering/decrypting, so why does it say that
"a user may encrypt a portion of a document using his or her private key"?

If I try to decrypt with the sender's public key (as written above), how do I know that the message hasn't been altered? And how do I know that the decryption has succeeded?

What will be the result if I try to decrypt the message using "satan's" public key?

3 Answers
3

a user may encrypt a portion of a document using his or her private key.

Sounds like a badly written description of RSA signing. With RSA signing you essentially encrypt a hash of the message with your private key.

2) You use the senders public key to verify the signature. And since the signature contains a hash of the whole document, you know it hasn't been tampered with.

3) Is a bit unclear. If you decrypt with plain, unpadded RSA, it will succeed for most blocks, and give gibberish. When using padding you'll get a padding failure. But since this is a nonsensical operation, you don't need to think about that.

The way messages are encrypted in a public key system is:

Sign the hash of the message with your private key

Generate a random symmetric key, and encrypt the message(and potentially the signature) with it.

Encrypt the symmetric key with the receivers public key and combine it with the ciphertext.

Encrypting the key with the receiver's public key, means that only the owner of the associated private key can decrypt the symmetric key, and thus the message.

Signing the whole message with your private key, means that the receiver verifies that the signature matches the sender's public key, and that the hash embedded in the signature matches the document. Thus he can be sure that the whole message is unaltered, and was sent by the owner of the sender's private key.

@codeinChaos.... I have so many questions about it.....thanks for replying....the last part in your answer : does this 3 steps are being made for EACH MESSAGE ? Cause ive heard that it occures only at the start (encrypting the master secret code - as you written) and then use symetric keys.
–
Royi NamirFeb 24 '12 at 17:05

@RoyiNamir Depends on the exact protocol and type of message. For email encryption, this step is probably done for every message, so emails become independent. In SSL asymmetric encryption is only used during the handshake. And for individual messages(records) only symmetric encryption combined with some kind of MAC is used. The wikipedia article on SSL is pretty good.
–
CodesInChaosFeb 24 '12 at 17:11

Your block of text appears to be aimed at a novice. The last line states the actual result:

Thus, the encrypted portion of the message is said to have been “digitally signed” by the sender.

So question 1. Yes, you sign with a private key and verify the signature with the public key. The actual operation involved is the same. You are "encrypting" the text using a large number. Whether the number is a private key or a public key makes no difference, though there are security gotchas associated with using the wrong key for an operation.

For question 2, you know the message hasn't been altered because only the private key can sign the message. This is the basis of all asymmetric cryptography: one key is held dear, and the other is made public. Through this, you create the characteristic of non-repudiation of sending -- the inability to claim the message was not sent by the holder of the private key. If the private key has been compromised, then all bets are off.

For question 3, the results are implementation-dependent though I suspect you would get gibberish in many cases.

Previous answers are very good, but there's so much confusion in this question that I believe more explanation is always better.

I thought that the private key is used for signing and deciphering/decrypting, so why does it say that "a user may encrypt a portion of a document using his or her private key"?

It's used to decrypt data that was encrypted by your public key. Also it can sign anything and people with your public key will be able to verify your identity.

If I try to decrypt with the sender's public key (as written above), how do I know that the message hasn't been altered? And how do I know that the decryption has succeeded?

You decrypt with your own private key, they encrypt with your public key. The decryption cannot fail silently, if an output file is here, then it's all good. Implementations may be broken though.

What will be the result if I try to decrypt the message using "satan's" public key? No data ? Error indicating incorrect key? Gibberish data?

You cannot decrypt with other public keys. If you try with all but the right private key, it will not work. Error indicating incorrect key is the most likely outcome. You could expect weird implementations to still produce an output file with gibberish data though.

If a user signed a document using his private key and he sends it to me - - so i Decrypt it using his PUBLIC KEY to check if i got the same hash ( which I should equate to a hashe which I generate myself according to the same protocol he used to hash...).....no?
–
Royi NamirFeb 26 '12 at 10:41

You don't decrypt it, you verify the signature. It's different. For this case, you use hist public key. For decrypting, you use your private key.
–
AkiFeb 26 '12 at 12:01

With all due respect, I'd rather not share my email address. I help people here when I ask a question usually, and when I'm done, I'm out of here. Besides, many other members are at least as competent as I am, I don't deserve such attention... Thanks though.
–
AkiFeb 26 '12 at 12:52

You could expect weird implementations to still produce an output file with gibberish data though there is a problem here.... Lets say the decrypted hash value is "abc". now , according to your sentence , if i decipher it with satan's public Key ( to verify) - I might get Gyprish data like : "@#$". Now , How the hell I suppose to know that @#$ is not the real data ? Now I have 2 options to choose : "abc" or "@#$".... (only first is correct)... how should i choose ?
–
Royi NamirFeb 27 '12 at 8:26