Using digital certificates in digital signatures

Question

Please could anybody explain to me how certificates are used with digital signatures?

I understand difference between certificates and signatures. It is clear.

Digital certificates are used to verify the trustworthiness of a website, while digital signatures are used to verify the trustworthiness of information.

I am not sure if i understand this picture on wikipedia.

Bob generates private key and public key. He encrypts hash of message with his private key - signature. Bob sends message with the signature and public key to Alice. Alice generates hash of message and compare this hash to decrypted signature. If she wants to decrypt the signature, she needs to verify the public key by certificate (if this public key belongs to Bob).

Why is certificate next to Bobs signature? I thought certificates are used with only public keys.

Is public key always used for decrypting and private key for encrypting in digital signatures?

Answer 1

You claim:

digital signatures are used to verify the trustworthiness of information.

This is right, at least for some interpretations of "trustworhtiness". Actually, a digital signature can be used to verify that the information has been created by some entity having access to the private key to the public key referenced by that signature, and has not been modified since. (If the hash used is not collision-resistant enough, like MD5 nowadays, the entity with access to the public key might create two documents that can be swapped after signing without noticing by you.)

You also claim:

Digital certificates are used to verify the trustworthiness of a website

Which needs a bit generalization: It is not just for "websites", it is for any case of entity. And again, you need to define what trustworthiness really means. A digital certificate enables you to verify that some entity that proves to you to posess some secret key, to be the entity they claim to be.

The picture on Wikipedia shows one process of sensibly dealing with signatures. The document author signs the document, and needs to use the secret key for that. The receiver needs the public key to verify the signature. If the receiver knows the public key of the sender, everything is fine, no need for a certificate. But if the receiver does not know the sender's key beforehand, it needs to make sure that the key does indeed belong to the sender. The receiver thus needs a way too verify the identity of the entity creating a signature. A certificate (issued by a trusted third party) is a great way to provide the proof of identify. Bundling the certificate with the message provides the certificate to the receiver just in time when it is needed to verify the message.

---

Bonus: Actually, the statement "the private key belonging to the public key with a hash of $HASH belongs to $ENTITY", which a certificate should prove, is information. So a signature can be used to verify its trustworthiness. And indeed, certificates are signed.

On the signature of a certificate needs to be made by some entity, so how do you verify whether that certificate has really been issued by a trustworthy entity? Well, there are two ways: Either, you know the entity and its public key, so you can verify the signature on the certificate. Or the you don't know the public key, and then you need a proof that the signature on that certificate has really made by that third party that is claimed to have made it. How do you do it? By having that third parties key being certified again by another party.

The result is certificate chains: Each certificate contains a signature. To be able to use the signature, a certificate certifying the issuer of the certificate is attached. You repeat this process until you can trace a key to a party you trust. The difference between centralized PKI (like X.509) and peer-to-peer PKI (like PGP) is that in centralized systems, all participants agree to trust a certain set of "root certificate authorities", while in Peer-to-Peer-systems, every participant can choose the roots of trust itself. The consequence is that in centralized systems one signature on every certificate is enough, while in peer-to-peer systems you likely want different parties to "sign your key" (i.e. issue a certificate that the key belongs to its claimed owner) to increase the likelyhood that communication partners find a way from your key to a root they trust.

Answer 2

To sign something digitally, it is necessary for me to have a private key and for the matching public key to be transmitted to the message recipient over a secure channel that prevents tampering or substitution. I can then easily prove that I originated the message by hashing the message, encrypting the hash using the private key, and attaching the encrypted hash as the signature. The recipient can also hash the message, decrypt the signature using the public key, and verify that the two hashes match. That will prove that the message has not been tampered with, and that I originated it. The difficult bit is the distribution of the public key. The certificate is optional, and indicates that the third party who signed my key agrees that I am me.