You are only browsing one thread in the discussion! All comments are available on the post page.

Return

charonn0 ,
@charonn0@startrek.website avatar

SSL/TLS, the "S" in HTTPS, and other network encryption protocols such as SSH, use a technique called a Diffie-Hellman key exchange. This is a mode of cryptography where each side generates two keys: a public half and a private half. Anything encrypted with the public half is only decryptable by the associated private half (and vice versa).

You and Youtube only ever exchange the public halves of your respective key pairs. If someone snoops on the key exchange all they can do is insert spoofed messages, not decrypt real ones.

Moreover, the keypairs are generated on the fly for each new session rather than reused. This means that even a future compromise of youtube won't unlock old sessions. This is a concept called forward secrecy.

Message spoofing is prevented by digital signatures. These also use the Diffie-Hellman principle of pairs of public/private keys, but use separate longer-term key pairs than those used with encryption. The public half of youtube's signing key, as presented by the server when you connect to it, has to be digitally signed by a well-known public authority whose public signing key was shipped with your web browser.

zaknenou OP ,
@zaknenou@lemmy.dbzer0.com avatar

this is very detailed answer thank you. however I face an ambiguity regarding this:

This is a mode of cryptography where each side generates two keys: a public half and a private half. Anything encrypted with the public half is only decryptable by the associated private half (and vice versa).

How can this private half be something that I know, Youtube knows but impossible for the snooper to our communication to know??

matthewc ,

Your computer generates two keys. One to encrypt a message. One to decrypt the message. The encrypt key is public. The decrypt key is private. Your computer shares the public key with YouTube. The private key is never shared.

YouTube does the same thing for your computer.

Your computer will have YouTube’s public key and your computer’s private key..

Your computer will be able to encrypt messages to send to YouTube that only YouTube will be able to decrypt. Even your computer will not be able to decrypt these messages after it has encrypted them using YouTube’s public key.

Since the decryption keys are never shared they can’t be snooped. That is why it is only possible for an attacker to encrypt new messages but not read any messages from either sender.

aldalire ,

Good description of asymmetric cryptography!

Darkassassin07 ,
@Darkassassin07@lemmy.ca avatar

Youtube never knows the private half of your key pair. That never leaves your system.

Anything encrypted with the private half can only be decrypted with the public half, and anything encrypted with the public half can only be decrypted with the private half. These halves are known as the public key and the private key. Each side of the connection generates their own key pairs.

We both generate a set of keys, and exchange the public halves with each other. I then want to send you a message:
I first encrypt it using my private key, I then encrypt it again using your public key and send that to you.

In order to read that message, you first decrypt it using your private key. This ensures the message was intended for you and wasn't modified in transit, as you are the only one with access to that private key and only its matching public key could have been used to encrypt that layer.

You then decrypt it a second time using my public key. As I'm the only one with access to my own private key, you can be sure the message was sent by me.

As long as that resulted in a readable message; You've now verified who sent the message, that it was intended for you, and that the contents have not been modified or read in transit.

All this, including the key exchange is handled for you by the https (tls) protocol every time you connect to a website. Each of the messages sent between you and the site are encrypted in this manner.

zaknenou OP ,
@zaknenou@lemmy.dbzer0.com avatar

so you can encrypt a message with my public key but you cannot decrypt it afterward ??

Darkassassin07 ,
@Darkassassin07@lemmy.ca avatar

Exactly. Once encrypted with your public key, you're the only one who can decrypt and read it as you are the only one with access to your private key.

deluxeparrot ,

The best way I find to think about it is a padlocked box.

The public key is a box with an open padlock on it. I can give it to anyone. If someone puts a message inside the box they can lock the padlock, but they don't have the key to open it again.

I keep the key private. If someone sends me a locked box that has my padlock on it, only I have the key to open it and read the message.

intensely_human ,

Anything encrypted with the private half can only be decrypted with the public half, and anything encrypted with the public half can only be decrypted with the private half.

This is not true. In key pair cryptography, the public key used only for encryption and the private key is used only for decryption.

Darkassassin07 ,
@Darkassassin07@lemmy.ca avatar

As far as I understand a key pair can be used bi-directionally like I'd described. Was I mistaken?

In practice, the private key is usually used to create signatures instead, but I avoided that for simplicity.

chayleaf ,

no, it isn't bidirectional, public = encrypt, private = decrypt, that's it. You can address a message to multiple recipients though (when using GPG), so often in case of email a message is addressed both to yourself and your recipient, so both you and your recipient have access to message text

azdle ,
@azdle@news.idlestate.org avatar

You're not mistaken, it is definitely possible with at least RSA, though, I would guess it may not always be possible. It also sounds like it's still a bad idea unless you know all of the parameters used to generate the keys and can be sure what information is actually encoded in the keys.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • privacy@lemmy.ml
  • All magazines