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.

You are describing symmetric encryption where both parties have the same key. There is something called asymmetric encryption that solves this. Basically you have a public key and a private key. You can give your public key to youtube, they can use that key to encrypt the symmetric key that will be used for the actual communication. The only way to decrypt the symmetric key is by using your private key, which is only known to you. So youtube can safely send it to you so you can decrypt it. Now you both have the same key and nothing was sent unencrypted.

Well your public key was sent unencrypted but that's fine because of how asymmetric encryption works.

Asymetrical encryption solves this, here is my attempt to do an ELI5:

Adam want's to send a chat message to Ben, but want to do it securely, so they use a special program on their computers.

When the Adam's program first reaches out to Ben's computer, it asks for an unlocked padlock, this is a padlock that can only be unlocked by Ben's program.

Adam's program takes the padlock and crafts a new special series of padlocks that only Adam's program can unlock, which it put's in a box and locks it with Ben's padlock.

The box is sent to Ben's program, the program unlocks the box and creates it's own special series of padlocks that only Ben's program can unlock, put them in a box and locks it with Adam's padlocks.

The box is then sent to Adam's program, and is unlocked.

This now means that Adam's program can put messages to Ben in a box, lock the box with one of Ben's special padlocks and send it on it's way knowing that only Ben can unlock the box and read the message.

Likewise, Ben can also send messages in boxes locked with Adam's padlocks and know that only Adam can unlock them and read the message.

Added to this is the fact that messages from Ben can be verified as having used the special padlocks Adam sent to Ben, as else Adam's special key wouldn't fit the padlocks given to Ben.

In reality the padlocks are keys to lock a message, and the above text describe a secure key exchange.

@zaknenou @privacy it usually uses Diffie-Hellman key exchange which generates a shared key without revealing it to anyone. There are other ways to do it too.

Seeing as other answers are either links, or wall of texts, I'll try to keep it short and approachable:

• Encryption, asymmetrical or symmetrical, relies on private keys being private. Once those keys are compromised, the encryption also is (read on).

• By default, in the most simplistic form, it doesn't matter when the content was encrypted, the private key can decrypt it. There are solutions to this problem, making encryption time (or iteration) sensitive.

• For an attacker with enough means, the private keys can always be exfiltrated, and content can be intercepted, but usually there are much simpler solutions for snooping on encrypted content: the devil is in the (implementation) details (this link is an illustration, and by no means an exhaustive list).

• Cryptography is always simpler to go around than to break. So never be satisfied with a cryptography only (or protocol only) audit. There are near infinite of ways to neutralize encryption with a single line of code in a client.

• The architecture is also essential. Client-Server encryption has entirely different use cases than Client-Client encryption (EE2E).

• And finally, Schneier's law:

Any person can invent a security system so clever that she or he can't think of how to break it.

Okey, it's like this: You and youtube both generate two keys, public and private. Public keys are public, anyone can see them. Doesn't matter. When you send a message to youtube, you encrypt it with their public key. Now, the trick is, the encryption is asymmetric, which means that the message can only be decoded if you also know the private key, which you never send anyone but keep hidden. Right? This way, as long as your private key is secure, you can not realistically decode the encryption from outside just knowing the public key. Thus setting up a secure connection is just an exchange of public keys.

This is more or less how I understand it.

But when Youtube shares the key with me/my client the first time, is that also encrypted?

Here's an explanation of what happens during the initial TLS handshake.

...if ISP automated the process of gathering keys and decrypting web traffic for a certain site with them for all users, would that work for them?

Not sure this is exactly what you're asking, but there's the concept of forward secrecy for defending recorded encrypted traffic from future key compromises.

While we're talking about asymmetric encryption, can someone explain to me why you can't decrypt information with the same public key that encrypted it? I understand the analogies (locks on a briefcase, unmixing paint, etc), but I can't "un-analogize" them to understand what's actually going on. Encryption keys aren't physical locks or paint. They're numbers(?). So why can I encrypt something by multiplying by a known public encryption key, but I can't decrypt it by dividing by that same known public key?

I think no one has mentioned the base for all the cryptographic functions. A mathematical operation which is simple in one direction but very hard in the the other (backwards). The factorisation of large prime numbers is one example.

Bh sharing, unencrypted, on Lemmy that you like watching revolutionary videos on YouTube, the government now has that data, even if Google wasn't going to give it to them. I thought I would just add that, as everyone else has explained asymmetric encryption well.

Also, usually it's just the content of the website, not the URL itself that is encrypted, so anyone, not just the government, can know what YouTube videos you watch (as the video ID is in the URL) as well as the URL of any other websites you visit.

the government

The secret world government ☝️