Eyad Elfarra's lecture on digital signatures and key management: how signing provides authentication and integrity, why it lacks confidentiality, and how certificates bind public keys to identities.
Key Takeaways
- Digital signatures provide authentication, integrity, and non-repudiation but not confidentiality.
- Signing uses the sender's private key; verification uses the corresponding public key.
- Public key certificates issued by trusted Certificate Authorities prevent man-in-the-middle impersonation.
- Key agreement protocols like Diffie-Hellman let parties establish a shared secret over an insecure channel, though basic Diffie-Hellman does not authenticate participants.
What the video covers
- The lecture is part of the Cryptographic Tools chapter (section 2.4) and covers digital signatures and key management.
- Public keys serve two purposes: digital signatures (verifying sender identity and data integrity) and key management (distributing keys securely).
- Key management involves distributing public keys securely, distributing symmetric secret keys, and creating and transmitting temporary session keys.
- Digital signatures guarantee authentication (the sender is who they claim), integrity (tampering is detected), and non-repudiation (the sender cannot deny signing).
- The signing process: the sender hashes the message, signs the digest with their private key, and sends the plaintext message along with the signature; the receiver recomputes the hash and verifies it with the sender's public key.
- Digital signatures do not provide confidentiality because the message is typically sent in plaintext; anyone with the sender's public key can read it.
- Common digital signature schemes include DSA (based on discrete logarithms), RSA, and ECDSA (based on elliptic curves).
- The man-in-the-middle risk means a public key must be verified as truly belonging to its claimed owner, which is solved with public key certificates.
- A public key certificate, issued by a trusted Certificate Authority, contains the identity, the public key, and validity information, all digitally signed by the CA.
- The lecture moves on to securely exchanging symmetric keys, introducing key agreement such as Diffie-Hellman, and hybrid schemes using session keys and digital envelopes for confidentiality.
Chapters
- 00:00Introduction and lecture overview
- 01:34Purposes of public keys and key management
- 03:34Digital signatures: authentication, integrity, non-repudiation
- 05:03How digital signing and verification work
- 07:09Digital signatures vs. encryption and confidentiality
- 07:39The man-in-the-middle problem and public key certificates
- 09:08Key agreement and Diffie-Hellman
- 19:00Session keys and hybrid encryption
Full Transcript — Download SRT & Markdown
Speaker A
In the name of Allah, the Most Gracious , the Most Merciful. Welcome back, everyone. Today, God willing, we will discuss the fourth lecture in the Cryptographic Tools chapter. We will cover Digital Signatures and Key Management. In the previous two
Speaker A
lectures, we first discussed the introduction. We talked about symmetric encryption keys. And we talked about public-key encryption. We said there is a problem with symmetric keys, which is how I can distribute them to people. So , we will talk about key management.
Speaker A
Alright. Let's talk about Digital Signatures and Key Management. What do I mean by this, or why do I use public keys in general? I use public keys for two things: digital signatures and key management. Digital signatures are to
Speaker A
verify the identity of the person and the data integrity. And key management is to distribute the data. Key management includes three main concepts . First, I need to distribute public keys securely. I need to distribute symmetric secret keys; this is in case
Speaker A
I use symmetric encryption securely. Or if I want to transfer a temporary encryption key, how do I create this key and transmit it with the message?
Speaker A
Alright, that is the creation of temporary keys for message encryption. Now, let's talk about digital signatures. This is an encryption algorithm I use to verify whether the signature on the message you sent me is correct or not. What does this
Speaker A
guarantee me? It guarantees three things: that you are actually the sender, that the data is correct, and it prevents repudiation. How are you the sender? You will encrypt with your private key, right? If I am able to verify the data with your public key.
Speaker A
That means you are definitely the sender. What about data integrity? If any tampering occurs to the sent message, the signature will not match the verification. I will use the public key for that. Consequently, it will show whether the message has been
Speaker A
tampered with or not. What about non-repudiation? Non-repudiation means no denial. This provides evidence linked to the person who. Signed the message; you will not be able to easily , or you will not be able at all, to deny that you are the one who sent the
Speaker A
message. Why? Because no message will be verified with your public key unless you encrypted it. So, the basic idea in digital signatures is that I encrypt with my private key and send it to people outside. People outside will
Speaker A
verify it with the public key I provided them beforehand. Right, the public key that I provided them beforehand. Here is an important point to mention about digital signatures: it ensures authentication, integrity, and non-repudiation, but it does not ensure
Speaker A
confidentiality because the message, in most cases, is sent as plain text. I will confirm that I am the source of the message, but it is not encrypted, and thus there is no confidentiality, except in the case of a digital
Speaker A
envelope, as we will see shortly. So, for the digital signature, the basic concept is as follows. Who is going to send? Bob. Who is going to send the message? Bob. And who will receive it?
Speaker A
Alice. Now, the digital signature is divided into two parts. The part before sending, which is at Bob's end, the signer. And the section after sending, at the receiver side, who is it? Alice says, I have this message. I want to
Speaker A
use a hash function. Calculate the hash of the message. What will result from this? The digest. I will sign this digest. Using whom? Bob's private key.
Speaker A
Who is that? Bob again. The sender. I signed the message; now, what do I put in the packet I send? I put two things: the message itself, which is currently unencrypted—the message is not encrypted, I only calculated its
Speaker A
signature with a hash function—so I will send the message and send with it the signature of the message. Okay, who will receive the message from me? Alice , Alice, Alice? She received the message. She will take the message she
Speaker A
received and input it into...The hash function. The same hash function that I used. What will we get out? A digest.
Speaker A
She will check this digest using the sender's public key. Which is Bob's. She will use Bob's public key. This digest, to verify it effectively. Does this digest match the signature sent to me or not? If the two match each other.
Speaker A
It means who sent the message? Bob. If they don't match, it means either Bob didn't send the message, or someone on the way tampered with the sent message.
Speaker A
Right. The verifier recomputes the digest. Recalculates it, okay. To check it against the signature. Using the signer's public key, the person who performed the signing process. Right.
Speaker A
What digital signatures do we have? We have three famous ones. DSA, which stands for Digital Signature Algorithm, okay. Based on discrete logarithms, okay. And the second type, RSA digital signature, as the name suggests, is based on RSA. And ECDSA, and as the
Speaker A
name implies, it is based on Elliptic Curve Cryptography. Right. Key concept: they all use the private key for signing. Why am I talking about a public key? Because the person on the other side will use the public key for
Speaker A
the verification process. Clear. So, in these three types, I will sign the message using, using my private key as the sender. The person on the other side will confirm that I sent the message using what? Using my public key
Speaker A
that I gave to everyone. So, it is said that digital signature does not mean encryption. Let's go back one step. In this message, in the case of a digital signature, did I perform, in any of these steps from the message to
Speaker A
generating the signature, any encryption of the message? No. So, as long as there is no encryption of the message itself, does that mean confidentiality was guaranteed? No.
Speaker A
Clear. So, digital signature does not mean encryption of the message. It provides authentication, integrity, and non-repudiation, but it does not guarantee confidentiality. Consequently , anyone with the sender's public key can read the message and also verify it is correct. Is everything clear? Anyone
Speaker A
with the sender's public key can read the message and know it is correct, even if they are not the intended recipient. Therefore, a digital signature does not mean encryption.
Speaker A
Well, for confidential encryption, how do we achieve this? We will get to it in a moment. Okay, we said we have a problem with the public key. If I came and sent to Alice and told her this public key belongs to Bob, and I am not
Speaker A
Bob. How would she know that? We need someone to actually guarantee that the public key you have is Bob's public key . Because simply, if I tricked you and gave you a public key of my own and told you this is Bob's public key, I
Speaker A
can simply start sending you messages encrypted with the private key of that key I sent you. And you would believe that I am whom? That I am him. And this is wrong. How do I ensure the public key I have is Bob's public key? This is
Speaker A
the title of this area. Tell me, what is our problem? Public key is public.
Speaker A
How do we verify the fact that the owner of this key is Bob and not someone else? He tells me this, tells me what? He tells me "man-in-the-middle " risk, if someone came in.
Speaker A
If someone came in the middle, okay, and tried to read this message. We will have a problem. The solution is that I want to create a certificate. I want to create a certificate that tells you effectively that this public key you
Speaker A
have belongs to Bob. And you would be sure that this belongs to Bob. I will give you the key within a certificate.
Speaker A
This key within what? A certificate. What is a public key certificate? It is a certificate issued by a trusted and authorized entity. And everyone can reach it, okay. It contains the user identity, for example, Bob. It contains Bob's public key. It also contains the
Speaker A
validity information. Such as the expiry date of this message. After that , what do I do? I digitally sign all this information. Using whom? Using the Certificate Authority, or the Certification Authority. Okay, certifying an identity key. I give you
Speaker A
an identity and a public key. I do not give you the public key alone, okay.
Speaker A
Therefore, I do not tell you that this is from Bob, meaning this is Bob, this is from Alice. So this is Bob's certificate. It is digitally signed by the trusted Certificate Authority.
Speaker A
Which is which is a certificate issuance authority that is what? Trusted and guaranteed. And everyone knows it, okay. And everyone knows exactly what this is. In all certificate authority, of course. It is a third party. Which is someone other
Speaker A
than the sender and the receiver. Okay. So it is not the sender nor the receiver. It is another person. Bob comes and tells her here is my ID. I am Bob. And here is my public key. And here is the rest of the information you
Speaker A
want. So what does it do? It issues me a certificate. Now, when I give this certificate to anyone in the middle, I say. To him. I am Bob; he will go and take my data. Take the certificate and
Speaker A
take the public key of whom. Certificate authority to verify effectively if the certificate is correct or not...okay, the certificate authority is a trusted party. To verify the identity as public key. It verifies the identity. Which is linked to a
Speaker A
public key. Create. Sign certificates, issue certificates like this, alright. To verify the certificate, it allows others to confirm if this certificate is valid or forged. How do I create a public key certificate? First, the client generates what? A public-private
Speaker A
key pair. Generated the public and private keys. After that, it prepares the message information. Who I am. How do I prove that this is me, Bob. And the key and the validation. I send this data to whom? To the Certification
Speaker A
Authority. Or to the certificate. The Certification Authority, what does it do? It takes the data. It hashes it.
Speaker A
Then what does it do? It verifies it using the Authority. After doing that, what does it do? It signs it using whom ? Using a hash function. Then what does it do? It signs this hash using its private key, then attaches the
Speaker A
signature to our certificate, and then what does it do? It sends it back to whom? To Bob. Now Bob has what? He has the public key and his data in a message signed by a globally trusted Certification Authority, and he sends
Speaker A
it to whom? To other people like Alice who communicate with him, so Alice verifies if this is really Bob or not, or if this is Bob's public key, via whom? The Certification Authority public key. So, why did I use the
Speaker A
Certification Authority's public key? Because who signed this thing anyway? The one who signed this is the Certification Authority with its private key. So it is natural to verify this using the Certification Authority's public key. We will verify; I have the message and the signature. I
Speaker A
take the message content without the signature. I hash it, and we get a digest. I take the signature and verify it with the Authority's public key. And I compare them. If they match, it is valid. If they don't match, it means it
Speaker A
is invalid. If it is valid, it means it is a trusted person. If it is not valid , it means the person is untrusted, or the certificate was tampered with. Okay . What are some examples of certificates? It told me X.509 is one
Speaker A
of the famous types of certificates issued globally. It is signed using the public key. Used in many protocols and applications in the world. Like TLS, HTTPS, secure web, IPSec, or VPN. SSH, which is if I want to access my remote
Speaker A
server using a secure connection, I call it SSH or secure remote login. Or I also use it in secure email. Okay.
Speaker A
Now, let's move to another question. We said we managed to distribute the public key securely. Let's come to our main issue with the symmetric key. How can I exchange the symmetric key or my secret key with someone far away
Speaker A
securely? It said there are two ways for me to send it. Either I send it directly over the network. And in this case, what is it? Insecure. Anyone on the path who sees the message knows our security key, making our encryption
Speaker A
useless. The second method is that I want to encrypt it using another key. This will create a new problem for us, which is the key distribution problem all over again. What is the solution?
Speaker A
He told me the first method we had was the Diffie-Hellman key exchange. It appeared to us in 1976 and was the first public-key algorithm. And it was used for what? To agree on a key. He told me the first thing we have is
Speaker A
Alice and Bob. Alice and Bob want to agree on a key. We have public information: a private number, a prime number, and a generated number. It is generated from the prime number. They exchange them with each other, and
Speaker A
based on that, they calculate the secret. And they will end up with the same secret. Then they will use it between them for the process of encrypting data, okay? Key agreement is the process of agreeing on keys, not
Speaker A
the process of encryption. Let me repeat, key agreement is the process of agreeing on an encryption key, not encryption itself. Okay. It has a problem, for example, the basic Diffie-Hellman does not authenticate the participants. Meaning the two might
Speaker A
agree on a key. But is this actually Bob? And is this actually Alice? This is also a problem. Okay. So how does Diffie-Hellman work for us? He said, simply, it is done in five steps. The first step is to generate two numbers,
Speaker A
P and G. What are P's characteristics? It must be a prime number. What does a prime number mean? A prime number is only divisible by itself and one. Both are what? They are integers. So now, Alice and Bob have agreed that this is
Speaker A
P, the prime number, and this is G. Okay, they agreed on it between themselves. And they sent it over the network normally. Everyone saw that the number to be agreed upon is 23 and 5.
Speaker A
We have no problem. Now, Alice starts the second step. She chooses a private key for herself, which is, for example, 6. And the same goes for Alice; Bob also chooses his own private key, let it be 15. So in the second step, both
Speaker A
randomly choose a number. Each one has their own number, okay. Now, Alice wants to generate a public key to send to whom? To send to Bob. And Bob, in the same way, wants to generate a public key to send. How will they both
Speaker A
generate it? Using what? Using these two values we chose in step 1: G, which is the second number, raised to the power of the private key, mod P, which is the prime number we have. So it equals 5 to the power of 6 mod 23; if
Speaker A
you calculate it on the calculator, how much will we get? Eight. P, which is here 5, which is G, to the power of his private key, which is 15, mod the 23, which is the prime we agreed on, gives
Speaker A
us a number. And both of them go back to sending each other the public key over the network. Alice sends to Bob the 8, and Bob sends to Alice the 19, okay, the two numbers were transferred.
Speaker A
Now we come to the final step. It is the step of calculating the shared secret key. I will use the shared public key that was exchanged over the network, and the private key from which I generated the public key, mod the
Speaker A
prime number P. Let's come to Alice. The key is the P, which is the public value from Alice, 19, raised to her private key, which is A, which we have here as 6, mod the prime number P, which is 23. If you calculate it, Bob
Speaker A
will calculate the key as well. The A, which is the 8 coming from Alice, raised to his private key 15 mod 23, will give us how much? 8 to the power of 15 mod 23 equals 2. So, effectively,
Speaker A
both agreed on the key between them. How? It turns out to be 2 here and 2 there, without both of them telling each other that the actual key is 2. So , it effectively results in the same key. So the shared secret between them
Speaker A
is what? It is 2. Consequently, the two parties, using Diffie-Hellman, were able to generate a secret key for encryption. They were able to generate a key for encryption between them. Now, if you are asking the question, why am
Speaker A
I using small numbers? Why 5, 23, 16, 15? Is this correct? I tell you no, this is not correct for practice. We are using it here only for the process, which is just for...For explanation purposes. Definitely, use much larger
Speaker A
numbers. Let's come to something called the Digital Envelope. I want to send data between two parties, okay. And the data must be encrypted. Meaning I want to ensure that the data sent is correct . It has not been tampered with. And I
Speaker A
want to ensure at the same time that my data is, what? Secret, so no one performing a man-in-the-middle attack on the way can uncover the data. A term appeared called the Digital Envelope.
Speaker A
The Digital Envelope merges symmetric encryption and public key encryption. I will encrypt the large message I have with symmetric encryption. Because with public key, the encryption process would be difficult and costly. And I will encrypt the key using the public
Speaker A
key. This process will happen for us. What is the first thing I have? I have the message. This is the message I want to send. My first step is to generate a random session key. Why session?
Speaker A
Because it is only for the exchange process. We have just generated the key . I will use the key I generated. The second step is to encrypt what? With symmetric, of course, a symmetric algorithm like DES, AES, and others
Speaker A
like DES or Triple DES and others using what? Using it. The generated key, so I encrypt this message using the key I generated. I get the encrypted message.
Speaker A
The third step, what does it tell me? This key itself, how do you want to transfer it over the network? It must be encrypted. So I will encrypt this key. Using what? Using the public key.
Speaker A
Key of whom? Of the recipient. Who will receive the data? Alice. So I will use Alice's public key and encrypt the key with it. So now I have the message encrypted with symmetric. And the key is encrypted, which is smaller in size
Speaker A
than the message, using what? The public key of whom? Alice tells me she puts both of them together in one packet. She calls it a digital envelope . She sends the message encrypted along with the encrypted key. Does the
Speaker A
attacker know the key I used for encryption? No. Well, does the attacker know the message, or is he able to read it? Also no. Also what? So, the attacker doesn't know the message, can't know it, and can't know the key.
Speaker A
How do you understand this? We will see in a moment. Why do I use symmetric encryption? Because it's efficient, and the calculations are much less for large messages. Why do I use it for large messages? Simply to solve the
Speaker A
problem of whom. The key reached you encrypted using whom? Public key. You received the message, you will split it into two parts. You will take the first part, which is whom? You took it, who is it for? It is the encrypted session
Speaker A
key. I will decrypt it using whom? Using Alice's private key. Why? Because I originally encrypted it using whom?
Speaker A
Alice's public key. I decrypted it, and now I have the key, which is the session key. Now what do I want to do?
Speaker A
I want to recover the original message. So this key, which is the recovered session key, along with the original message, I use to decrypt whom? The message. In this case, I obtained the original message we have. So, first I
Speaker A
use the recipient's private key. I decrypted the session key. Then I performed a recovery using the session key that I identified first. I recovered it and, who, decrypted the original message. Okay? And therefore, what am I doing? I encrypted a message
Speaker A
and sent it with its encryption key across the network. So I achieved encryption confidentiality and key distribution at the same time. So why do we use the digital envelope? It tells me that public encryption with symmetric encryption gives us the best
Speaker A
possible capability for encryption. Public key solves the key distribution problem. And symmetric is efficient.
Speaker A
And what is its efficiency regarding large data? Because it? It doesn't require very high performance.
Speaker A
Encryption is expensive in public key, so symmetric key will be faster. Okay, I use? I use public key for small data, like...small keys or data. While I use symmetric for actual data or large messages. About the large messages,
Speaker A
about. Okay. It tells me with the emergence of the quantum computer concept, we got something called quantum threat and post-quantum cryptography. Do you remember when I said that when I had the public key 129 , after eight months they were able to
Speaker A
crack the message in public key? We said we have 300, we have the current computer, which is zero and one, right, a binary system. And in case we transition, and they have now started working in the public quantum, in
Speaker A
quantum computing. The process of decryption or guessing keys will be very, very easy. Therefore, we must take a step forward in this matter.
Speaker A
People have started thinking about the key establishment process. Which means much larger and massive keys. Digital signatures, different methods. In order to challenge or overcome this challenge . For public cryptography in the quantum era. It must have higher
Speaker A
specifications and other specs than those currently available. So that I can protect it from. The quantum era.
Speaker A
What did we cover in this chapter? We talked about digital signatures. Public key certificate authority. We discussed Diffie-Hellman, digital envelopes, and post-quantum cryptography. With digital signatures, I want to send a message and ensure the sender is the actual
Speaker A
person. And that the message has not been altered. With certificates, I want to ensure the public key I have is truly Bob's or Alice's key. While with key exchange, I want to transfer or generate a shared key for symmetric
Speaker A
encryption without sending it over the network; we saw how Diffie-Hellman did this. And the digital envelope, how I want to encrypt a message effectively.
Speaker A
And if the message is large, it should not create overhead during transmission over the network. Or during the decryption process on my device. And we saw how the digital envelope combined public key encryption and symmetric encryption at the same time. Alright,
Speaker A
thank you very much. In the next lecture, God willing, we will talk about random numbers and pseudo-random numbers.
Topics:digital signatureskey managementpublic key certificateCertificate Authoritynon-repudiationDSARSAECDSADiffie-Hellmancryptography











