I wondered how long it would take for someone to point that out! 😅 You're correct, in the case of sending a symmetric encryption key I was responding to, the SENDER would encrypt it with the public key of the RECEIVER and then the receiver would decrypt it with THEIR private key. If the SENDER used their private key to encrypt it, then anyone could decrypt it using the [presumably well-known] public key of the sender.

Talking on a simplistic level, the problem is solved by the 1) client generating the symmetric key, 2) encrypting it with the server's public key and 3) sending it to the sever, which then can 4) decrypt the encrypted symmetric key with it's private key. 5) Thereafter, the communication can proceed in an encrypted manner (encrypted with the exchanged symmetric key)

@@wizard_in_oz absolutely, and this is exactly how SSL/TLS ,SSH tunnels are created for example.

100% Correct. Wonder why none of these guys presenting caught that. 😂

​ @Michael F ​Sigh! When I'm speaking spontaneously and rapidly, I sometimes use the wrong word. Senior moment? Jeff obviously knows security - he even teaches it at our local university. Either he missed my error in the moment or was being kind.

I’m glad this explanation made sense to you!

Thanks so much for the kind words of encouragement! It’s a complicated topic and I had to take some liberties with the explanations in order to fit the time constraints, but, hopefully, it shed some light on a really fascinating, but gorpy, topic

@@jeffcrume Hey in this video it is been said that any one key can be arbitrarily chosen as a public key but i was under the impression that once the key pairs are generated they are specifically private and public because of the derivation of one key from the another i.e. We can't derive the private via the help of public key if we possess it but we can derive public key with the help of private key which distinguishes these key from each other and we can't randomly select any one key as the public from the available pair

Exactly right. Asymmetric is used to solve the key distribution problem but symmetric is used to encrypt the bulk of the data

So glad you liked it!

You’re welcome!

Thanks! If you'd like to see other topics on Tech Talk, let us know!

I haven't implemented my own CA, but a quick search "how to create certificate authority openssl" yielded step-by-step tutorials. For those following along, this is different than just creating a self-signed certificate (no CA) that you might do for testing. Most browsers will refuse to connect to a site using one, unless you specify a command line/configuration setting to disable it.

Thanks!

I do too! He’s a sharp guy, for sure!

If you are a Web developer it's sure you must understand faster because this is included in the day to day life of website developers.🎉

First of all, be sure to read the pinned comment above as I misstated public/private in the video. That may be the source of your confusion. Sorry about that! But to clarify, there's two issues at play here: (1) How do you know the message you received is actually from who you think it is? (2) How do you establish secure communication with someone? For (1), you as the receiver of a message from SND know that *must* have originated from SND if you're able to decrypt it with SND's public key, because only SND has their [private] key that was used to encrypt it. Let's say for (2), SND wants to establish a secure connection with RCV. To start, SND creates a unique SND-to-RCV session ID "ZZZ" and wants to send it to RCV. So, SND uses RCV's public key to encrypt the session ID ZZZ, encrypts that with their own (SND's) private key, then sends the "package" to RCV. It's true that someone *could* intercept that package and use SND's public key to decrypt it, but all that would get them was RCV's (encrypted) session ID, which is worthless to the interceptor. On the other hand, RCV can decrypt the package using SND's public key *and* they can also decrypt the message to retrieve the session ID using their private key since SND used RCV's public key to encrypt it. Once this is complete, both SND and RCV share a session ID that nobody else knows; that can be used to establish a secure connection with both parties knowing the other end is who they claim to be. Another easier way to think of it is a message encrypted with a public key can only be decrypted with the associated private key. Thus you can use this asymmetry to prove that a message did in fact originate with the owner of the public/private key, because any tampering along the way would render the message gibberish when decrypted. Did I get it right, @jeffcrume?

Here's a simple end user example: Programs like email and browsers use encryption in order to ensure that communications cannot be read by anyone other than the intended party. Symmetric cryptography is how we secure the message and asymmetric crytography/PKI is how we exchange the symmetric keys so that the only the intended parties can read the messages [thanks to Jeff Crume for improving on my initial answer].

Hey in this video it is been said that any one key can be arbitrarily chosen as a public key but i was under the impression that once the key pairs are generated they are specifically private and public because of the derivation of one key from the another i.e. We can't derive the private via the help of public key if we possess it but we can derive public key with the help of private key which distinguishes these key from each other and we can't randomly select any one key as the public from the available pair

I was giving a single, theoretical example. You’re referring to a very legitimate practical example which implements the same concepts as multiple instances. “In theory, there is difference between theory and practice. In practice, there is.” 😊

Hey i even noted one more thing i.e. It is been said in that video that any one key can be arbitrarily chosen as a public key but i was under the impression that once the key pairs are generated they are specifically private and public because of the derivation of one key from the another i.e. We can't derive the private via the help of public key if we possess it but we can derive public key with the help of private key which distinguishes these key from each other and we can't randomly select any one key as the public from the available pair but yes both can use for encryption as well as decryption at the same time

Yes, SSL (now TLS) encryption is based on these concepts as well

In order to verify, you do need to decrypt the dig sig so that you can compare the hash value from the sender (encrypted with their private key) and compare it to your calculated value using the same hashing algorithm

@@jeffcrume thanks Jeff. I looked it up after I commented and you're right. Probably should have deleted my comment lol.

See the pinned comment above for a discussion of the correction.

That is correct.

Every time you login to a secure web site, you use symmetric encryption as well as asymmetric

No. However, IBM does have tools that do encryption and use PKI (Guardium Data Encryption plus all the PKI that is baked into our products and OSs).

IBM offers crypto capabilities of this sort on the mainframe as part of the security services in the OS. Also, crypto accelerator cards from IBM help speed up operation and keep keys secure

This is the guy with glasses. When I speak spontaneously, I sometimes make verbal mistakes like this. Sorry! I realized it was incorrect in the playback, but decided to leave it as-is. It took a few days for a viewer to correct me. 😉Another viewer pointed out a misstatement (?) by Jeff w.r.t. asymmetric keys. See the pinned comment for the viewers calling out these misstatements and our corrections.

@@homebarista I understand. I'm sorry for leaving a rude comment. It took a response from you to realize my own bitterness.

We're writing on a glass pane that is directly in front of us. Since we're on the other side of the glass, the writing is backwards from the viewpoint of the camera, so we flip the image in post-production. That's why it appears that I'm left-handed when in fact I'm right-handed.

@@homebarista thanks, mate!

The CA is responsible to issue the certs (and sign them with its private key). The public keys for trusted, well known CAs are hardcoded into browsers and other software so that they can verify that certificates are authentic and have been signed by a trusted third party

See ibm.biz/write-backwards for details

aaahahah thank you @@IBMTechnology

And they’re writing backwards!!

Hey in this video it is been said that any one key can be arbitrarily chosen as a public key but i was under the impression that once the key pairs are generated they are specifically private and public because of the derivation of one key from the another i.e. We can't derive the private via the help of public key if we possess it but we can derive public key with the help of private key which distinguishes these key from each other and we can't randomly select any one key as the public from the available pair but yes both can use for encryption as well as decryption at the same time

My goal with the video was to cover the concepts that would be applicable across all platforms. Vendor-specific implementations may be better explained by those vendors

Yes, you're correct and this is noted in the pinned comment.

Sorry about that! It was one of the first two-person mic setups we've done and the sound mixer wasn't dialed in yet. Our audio guy fixed it the next day, so future Tech Talks should be clearer.

Jeff said that once you designated one key as public, the other is then deemed private and vice versa. in other words, it's a mathematical property between the two keys and calling one or the other public/private is arbitrary up until the point that you make the decision. Obviously once you decide, you can't change your mind later.

You you can't choose arbitrary which key is private and which key is public. That's not how math works. If you choose the private key to be the key derived from the other than anybody can hack/decrypt your message. People in this video are just wrong.

Jeff confirmed that you're right, the keys cannot be arbitrarily assigned. This discussion elaborates on why: security.stackexchange.com/questions/74325/does-it-matter-which-key-is-considered-private-and-which-public

@@IBMTechnology I appreciate the clarification. Keep up the good work.

I’d say that crypto is an “acquired taste” and certainly not everyone “acquires” it 😂

Search the channel for a video of me explaining “how we make them” and you’ll learn the secret