5

Schematic of encryption

q1) Does that mean that every time information is exchanged, both the original data + digital certification is sent? Meaning data + signature for each and every exchange.

q2) Can any kind soul here please explain why we need to encrypt the one-way hash on the original data, since the hash itself is irreversible ?

If the (a) original data + (b) hash data + (c) hash algorithm is sent over to the receiving party, with (b) and (c), the receiving party is already able to know if (a) is being tampered with, so why the need for encryption ?

=========================================================

Is the purpose of encrypting the hash data is done so that, if someone is able to fake/change (a), he will not be able to change (b) and (c)?

-- is the hashing algorithm encrypted as well?

But again, the original data, and digital signature can all be fake and sent over to the recipient. So why do we need the private key encryption ?

or

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.

Please advise.

  • 1
    Read this security.stackexchange.com/questions/92101/… . A common misconception is that the "private-key encrypts" and the "public'key decrypts " for authentication. Encryption with the private key is a very dangerous practice. That's why hashes are used. Encryption with the private key results, especially with RSA, in an easy forgery. – dylan7 Jul 10 '15 at 19:00
4

You are essentially correct in your last paragraph:

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.

Though, as mentioned in comments, and in various places around the internet, the idea that a signature is "signing with the private key" is not quite right, it's like saying that a motorcycle is a mechanical horse; it's kinda right (and if you're talking to someone from the year 1685 then it's probably the best you can do) but it's also completely wrong.

So I'm not sure where you got that image from, but I would be wary about anything else they've said, since they are clearly over-simplifying.


I think you already have the core idea, but I'll try to add some more context.

Let's say you're in some sketchy foreign country and a complete stranger walks up to you and says "Hi @Noob, I have a letter for you from your mother." Before you open the letter there are two things you probably want to know: 1) did this letter really come from your mother? And 2) did anyone modify it before giving it to you? In information security these questions are known as authenticity and integrity, respectively.

Digital signatures accomplish both authenticity and integrity, let's talk about integrity first.

Data Integrity

With this question we want to prove that the message has not been intercepted and modified while in transit. To do this we will use cryptographic hash functions with the idea that if two messages have the same hash code, then with a 99.99...% chance they are the same message. (The 0.0...01% chance that two properly formatted English messages have the same hash is actually exploitable, and is called a hash collision attack, but we'll ignore that here.)

So when I send a message, I'm going to attach to it a hash of the message so that the recipient can compute their own hash of the message and check that they match (that's the right-hand-side of your image "Identical hash validates data integrity"). But what's to stop the mail-man from replacing both the message and the hash with new ones? Well, we'll solve that at the same time that we solve authentication.

Data Authentication

In this question we want to prove that the message which claims to be from your mother, did actually come from your mother. To do this, we usually get the sender to include something that only they could have done, for example you sign paper by scribbling your name in a way that nobody else could possibly copy, ancient kings would press their rings into wax (assuming that nobody else has a copy of that ring). With digital signatures we are going to sign a small piece of sample data and send it along, that way anybody can try decrypting it with the public key in the sender's certificate and make sure that it matches the original sample data. Now, instead of signing any random piece of data, we'll sign the hash of the message and kill two birds with one stone. When we check that

decode(received_hash, sender_public_key) == hash(received_message)

we are actually verifying both authenticity and integrity in the same step, since the only way this will pass is if the sender owns the matching private key and the message has not been modified.

~~ Edit in response to your comment: ~~

How do I know that the public key that I have is actually for my friend, and not for an attacker pretending to be my friend?

That's what certificates are for.

The question has a different answer depending on the type of trust model we're using, so let's look at the two main ones:

Web of Trust

This is the system used by PGP where each user creates a certificate for them self and gives it to their buddies. The first time you give your cert to someone you have to do it carefully, like on a USB stick in person, or once they have it, have them encrypt something for you and make sure you can decrypt it properly.

Once you have a certificate that you trust for someone, then you can encrypt for them and verify their signatures without any problem.

There's also the Network of Trust (aka "Web of Trust") idea: you can add your signature to anyone's key to endorse that it's genuine. Let's say I'm good friends with Bob, and he has endorsed Alice's cert, then I'm probably OK to trust Alice's cert.

Hierarchical Trust - Public Key Infrastructure (PKI)

This model gets it's trust by having all certificates generated by trusted servers (called Certificate Authorities). In this model, the job of the CA is to make sure that the person is who they claim to be, before issuing the cert to them. For example, if someone submits a request for a certificate tying pub_key to bob@example.com and 1-800-123-4567, then the CA might send a one-time code to bob@example.com and make sure he can get it, and might try calling 1-800-123-4567 and ask "did you just order a cert?"

  • thanks for the explanation. what if someone (that fake person) also send you his public key. So he uses his own fake message, hashed it, encrypted with his own private key. and you holding on to his public key, is able to decrypt it and thought that the message is real ? – Noob Jul 11 '15 at 11:44
  • That's not a simple question, so I updated my answer, rather than do it in comments. – Mike Ounsworth Jul 11 '15 at 14:00
  • thanks for explaining further. is there any chance that a hacker (maybe using his brother's company name) have obtained a signed cert from a CA. When a user attempt to access www.real.com, somehow the hacker managed to route this request to his own webserver and send his digital cert (which is verified by the CA) to the user ? will the end user browser check the cert retrieved contain and matches the domain name the browser is trying to access ? – Noob Jul 11 '15 at 19:38
  • I'm not entirely sure what you're asking, but yes, your browser will complain pretty hard if it requests content from www.siteA.com but gets handed a cert for www.siteB.com . – Mike Ounsworth Jul 11 '15 at 22:18
  • sorry for not being able to elaborate clearly. what i meant is actually having the so call "stranger", faking the message, the hash, and signing the hash with his own key + giving us his digital cert with his public key. The public cert though is a valid one given by the CA (due to some x,y reason, the checking went through). So here i am, as a user requesting to go to www.real.com, but somehow got routed to www.false.com, given a false digital cert, having a false message + signed hash; and then using the public key in the cert to decrypt the message and think its all real. – Noob Jul 12 '15 at 6:42
3

q1) Correct. Every message needs to be sent with its own signature. But if lots of information has to be sent this way, it is not very efficient because public key cryptography is rather slow. Usually the two parties would rather use a protocol allowing to share a secret, then use symmetric-key authentication, like a message authentication code (MAC).

q2) If I create a fake message, and use the same hash algorithm to create the hash value, and just send those, the recipient has no way to know that the data came from me and not the original sender. If the sender uses "encryption" (a signature algorithm) ans sends the signature instead of the hash, the bad guy cannot reproduce a correct message+signature because he dosn't know the private key.

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issue this public key (has the private key) since he/she is able to decrypt it.

Correct

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.