@@PaulTurnerChannel your videos are extremely useful and informative ... i hope to see more soon ....many thanks for your effort paul... god bless you.
Hi, k. SHA256 is a hashing algorithm. An HMAC uses an algorithm, like SHA256, in a particular way. Instead of just taking a message and hashing it with SHA256 to get a hash (fingerprint) of the message, you hash the message with a secret key (twice, as shown in the video) to create an HMAC that serves as an authenticated fingerprint or signature of the message. A recipient who has the secret key can verify that the message came from the sender and that it wasn’t changed. On the other hand, if I was to simply hash this message with SHA256, you couldn’t verify that it came from me when you received it because anyone could create a message, hash it, and send it to you. However, if only you and I know the secret key, you know that the message you receive )with an HMAC attached) came from me because you can verify that it was hashed with the secret key. I hope that helps, and sorry it wasn’t clear in the video.
Hello Paul, thank you for taking time to put this great content! I have a question about a "certain area" I'm trying to understand in PKI, what is the exact operation that our browsers do in the backend to verify that server certificate X is signed by root CA certificate Y? what i understand is that the browser will take the public key of the root CA certificate Y and try to decrypt the server certificate X using that public key and if its able to decrypt it then this means that certificate X must have been encrypted with the private key of root CA, but the problem with this "theory" is that the server certificate X is actually sent to the browser un-encrypted (clear text) as we can see it in a wireshark capture for TLS 1.2 session
Hi, Nader. You are actually correct but with a slight difference. The certificate is passed in the clear. I’m order to prove it is coming from them, when issuing the certificate, the root CA hashes the clear text certificate and then encrypts that hash with its private key. Once it receives the cert, the browser 1) decrypts the signature with the root CA’s public key to get the hash, 2) hashes the clear text certificate, and 3) compares the two hashes. If they match, it knows that the signature is valid. And, since they trust the root CA cert (public key), they trust the certificate. FWIW, the certificate is now encrypted in TLS 1.3 while in transit to the browser from the server. It is encrypted within the encrypted TLS stream facilitated by Diffie-Hellman key agreement. This was added by the IETF (standards group) for additional privacy. They did not want ISPs or others listening on the internet to know the domain name (the subject DN in the cert) that the browser/user is visiting. This works along with DNS over HTTPS (DoH) to prevent detection. The intermediary can a obviously see the destination IP address of the packets but that IP address could be the destination for many domain names. A VPN connection is obviously an alternative but that is not always convenient and the user may not want the VPN provider to have a clear picture of all their communications (since TLS is still used within the VPN connection). I hope this is helpful.
![Summer Walker - Heart Of A Woman [Official Lyric Video]](http://i.ytimg.com/vi/SFddctbZzw8/mqdefault.jpg)
Ah yes. Just made coffee and saw this come up. What a way to start a Friday
LOL. I just hit “Publish”! You’re on top of things, CKZA10! Thanks for the comment. I hope you like it.
this is an outstanding summary of things ive learned in security but didn't relate to each other conceptually - thank you!
I’m really glad it was helpful for you, Chris. Thanks a bunch for your feedback!
finally new video , welcome back Paul !!! please don't stop these videos ...thanks alot
Thanks for the feedback and encouragement, Mohamed. I hope to get a few more done. It helps to hear that they’re helpful.
@@PaulTurnerChannel your videos are extremely useful and informative ... i hope to see more soon ....many thanks for your effort paul... god bless you.
Hello. Thanks for detailed explanation.
I’m glad it was helpful, BitVibe!
what is the difference between sha 256 and hmac?
Hi, k. SHA256 is a hashing algorithm. An HMAC uses an algorithm, like SHA256, in a particular way. Instead of just taking a message and hashing it with SHA256 to get a hash (fingerprint) of the message, you hash the message with a secret key (twice, as shown in the video) to create an HMAC that serves as an authenticated fingerprint or signature of the message. A recipient who has the secret key can verify that the message came from the sender and that it wasn’t changed.
On the other hand, if I was to simply hash this message with SHA256, you couldn’t verify that it came from me when you received it because anyone could create a message, hash it, and send it to you. However, if only you and I know the secret key, you know that the message you receive )with an HMAC attached) came from me because you can verify that it was hashed with the secret key. I hope that helps, and sorry it wasn’t clear in the video.
@@PaulTurnerChannel Thank you for quick reply.This is perfect explanation.That means SHA doesn’t provide authenticity right?
Hello Paul, thank you for taking time to put this great content!
I have a question about a "certain area" I'm trying to understand in PKI, what is the exact operation that our browsers do in the backend to verify that server certificate X is signed by root CA certificate Y? what i understand is that the browser will take the public key of the root CA certificate Y and try to decrypt the server certificate X using that public key and if its able to decrypt it then this means that certificate X must have been encrypted with the private key of root CA, but the problem with this "theory" is that the server certificate X is actually sent to the browser un-encrypted (clear text) as we can see it in a wireshark capture for TLS 1.2 session
Hi, Nader. You are actually correct but with a slight difference. The certificate is passed in the clear. I’m order to prove it is coming from them, when issuing the certificate, the root CA hashes the clear text certificate and then encrypts that hash with its private key.
Once it receives the cert, the browser 1) decrypts the signature with the root CA’s public key to get the hash, 2) hashes the clear text certificate, and 3) compares the two hashes. If they match, it knows that the signature is valid. And, since they trust the root CA cert (public key), they trust the certificate.
FWIW, the certificate is now encrypted in TLS 1.3 while in transit to the browser from the server. It is encrypted within the encrypted TLS stream facilitated by Diffie-Hellman key agreement. This was added by the IETF (standards group) for additional privacy. They did not want ISPs or others listening on the internet to know the domain name (the subject DN in the cert) that the browser/user is visiting. This works along with DNS over HTTPS (DoH) to prevent detection. The intermediary can a obviously see the destination IP address of the packets but that IP address could be the destination for many domain names.
A VPN connection is obviously an alternative but that is not always convenient and the user may not want the VPN provider to have a clear picture of all their communications (since TLS is still used within the VPN connection).
I hope this is helpful.
Thanks for the video !
Thanks for the comment, Jeff!
thank you very much for this video
Thank you for watching, Radha.