the encryption keys, why can't the government just sneak on them?

disclaimer: I'm just asking to get understanding of the theory behind network traffic encryption, I know this doesn't happen irl most likely.

Let's take https connection for example. I like watching revolutionary things on youtube and do not wish for authorities to know what I am watching, we accept here for the sake of showcase that google won't sell my watch history if asked (LMAO what am I even saying?).
So if I'm not mistaken since youtube has https implemented, our communication is encrypted, the keys are shared only between me and youtube. But when Youtube shares the key with me/my client the first time, is that also encrypted? Wouldn't the same question keep getting answered until there is something unencrypted? I know this is a bit too much unlikely, but 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?
I'm taking https here as an example, while I have the same question for like VPN.

EDIT: Thank you everybody. I am not a member of this community, but every comment was a golden experience to read!

7heo , (edited )
@7heo@lemmy.ml avatar

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.

Quereller ,

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.

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

I'm satisfied with the answers and insights I got so far. But if you may add I'd be happy to know why factorization of prime numbers is so crucial in cryptography. I heard about this a lot before but don't know anything. I know quite well about Prime number and theorems about them on math, but not their applications

Rootiest ,
@Rootiest@lemmy.world avatar

As I understand it, it's just as they said:

Calculating primes is fairly straightforward so you calculate a few large prime numbers, and do some math to them.

Now you have a strong key that didn't require a supercomputer to create but taking that final number and turning it back into those original primes is a much more computationally expensive proposition.

In fact, it's one that's not viable with current technology.

paris ,

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?

Bienenvolk ,

https://www.practicalnetworking.net/series/cryptography/rsa-example/

Gooey0210 ,

the government

The secret world government ☝️

navigatron ,

Other comments here do a great job pointing to DH key exchange; I’d like to try explaining it with the paint analogy.

You and Youtube need to agree on a “color of paint” (encryption key) without ever sending it over the network.

You and Youtube agree on a common “yellow” in the clear, and you each pick a secret color. Youtube mixes yellow and their secret and sends it to you. This is okay, because un-mixing paint (factoring large prime numbers) is really hard. You add your secret to the mixture, and now you have yellow+Youtube’s secret+your secret.

You mix yellow and your secret and send it to youtube. Youtube adds their secret; now they’ve got yellow+Youtube’s secret+your secret. You both have the final color!

An eavesdropper can’t reconstruct this - everything sent over the network had yellow mixed in, and un-mixing paint can be really hard. Maybe you can guess that green minus yellow is probably blue, but you can’t get close enough to decrypt anything. And what if it’s brown? Is that blue + orange, or is it red + green?

Cryptographers have worked very hard to make the communications secure. I would be more worried about the other end ratting you out - using a relay / proxy / vpn that you trust is a good idea :)

catacomb ,

I think you're asking if it's possible for your government to be a man-in-the-middle? Depending on which government you live under, the answer is likely no but more importantly the answer will always be; it's not worth their effort to find out what you're watching.

YouTube's public key is signed by a certificate authority whose public key (root) is likely installed on your device from the factory. When you connect to YouTube, they send you a certificate chain which your browser will verify against that known root. In effect, it's information both you and YouTube already share and can't be tampered with over the wire.

Technically, those signatures can be forged by a well resourced adversary (i.e. a government) with access to the certificate authority through subversion, coercion, etc. At the same time, it's probably easier to subvert or coerce you or YouTube to reveal what you watch.

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

The situation is just an example, I'm not actually planning a revolution. just for demonstration purpose

stoy ,

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 OP ,
@zaknenou@lemmy.dbzer0.com avatar

Oh! I remember these steps being explained on a youtube video before. So the point is that the padlock (that Adam received on the third paragraph) is like a program on my windows desktop, I can run it (here like Adam uses it to encrypt the date), I can copy it and send it to a friend, but I can't read the code which is compiled through an unknown language (i.e even if snooper received the padlock he can't figure out how to unlock it and decrypt the data)?

stoy ,

Yep, if a thrid party gets the padlock they can lock the box, but can't unlock other boxes

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

Thank you! extremely helpful answer

JackGreenEarth ,
@JackGreenEarth@lemm.ee avatar

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.

Jajcus ,

URLs are definitely encrypted. What can be sent unencrypted are domain names and IP addresses. Which is not a problem when the host name is 'youtube.com', but is a bigger problem if it is 'the-terrorists.com'.

RHOPKINS13 ,

That's not true. The original DNS request, for youtube.com, may not have been encrypted, but any URL parameters afterwards are kept encrypted. As long as HTTPS is used, if hypothetically Google wasn't going to give it to them, "the government," or your ISP for that matter, can tell you're watching YouTube, but can't tell which video you're watching.

CaptainSpaceman ,

The other 2 commenters are wrong. URLs as they appear in your web browser are NOT encrypted when sent over https protocols.

The only data that is encrypted is POST data, and ONLY if it is sent over HTTPS.

So for example, a website login page crafts a URL like https://some.example.com/login?sessionID=12345678 and when you log in to the site extra parameters like Username and Password are sent via POST data, then anyone listening to your web traffic (like the NSA or your neighbor with wireshark) will br able to see the website and the sessionID, but not the login details as they will only show up encrypted.

However, if the site is ran by idiots who pass the data in the URL like this https://some.example.com/login?sessionID=12345678&username=Homer&password=Simpson, then ANYONE listeneing would have your credentials.

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.

immibis ,

@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.

cralder ,
@cralder@lemmy.world avatar

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.

banazir ,
@banazir@lemmy.ml avatar

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.

hungprocess ,
@hungprocess@lemmy.sdf.org avatar

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.

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