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.
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??
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.
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.
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.
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
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.
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.
@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.
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.
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.
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.
One thing to think about is the encryption quality of a zip file, which I ignore.
One danger that I see is that you have the risk of having the passwords on the clear all over the place many times. Not an expert so don’t quote me on this, but password managers are careful avoiding passwords on the clear as much as possible.
I don’t trust any online service for that, I am using keepass/syncthing for myself, with android as the only client decrypting (as I always have my phone with me). one example of advanced security measures is that while using the app I can’t take screenshots, and I hope/expect that it uses images backed by secure memory to show them to me and is careful with things like RAM and temporary files (didn’t check personally though, although being open source I could)
Having to be sure that your zip app handles that seems like a hustle honestly. On top of having random passwords without the biases I would add for each separate site.
I suppose there’s nothing wrong with it when the file is at rest, it looks like zip uses AES 128 or 256 which are adequate if you have a very strong password for the encryption. Ideally the encryption would feature a computationally intensive algorithm to slow guessing attempts when attempting to decrypt so you probably don’t want to use a weak password.
Usability won’t be great, you’ll be copy pasting constantly and that presents an opportunity for malware to spy on the paste buffer and steal your passwords but it’s a low to medium severity issue.
If you want to keep everything local I’d recommend KeePass, it’s free, open source, and very strong. It’s kinda the same thing but with the ability to insert passwords directly in some cases and can do more to keep everything organized.
If you want to use this in environments where you can’t install anything on the systems but don’t want anything online, this is probably acceptable though.
If your goal is to “self-host” a password manager, you might as well use Keepass + SyncThing.
free software
master password protected
has organization and auto-fill features
can sync across multiple devices
Usually the downfall of rolling your own password manager is it’s easier to make mistakes and accidentally lock yourself out. Or if you don’t keep backups/replicas then you could easily lose your passwords.
I guess it would work, as long as you’re using an up to date zip implementation with AES-256 encryption. I guess my question would be why bother? Being compressed doesn’t add any real additional benefit, since just using text shouldn’t take up much space.
Is recommend just using an actual password manager for convenience, since you aren’t really gaining any security by only storing your passwords in a file.
Your storing in password protected zip file is better than storing it plain text in a file on your computer but the password encryption of zip is probably not that strong. A friend of mine insists on using a disk encrypted pen drive with an office document having his passwords. I hope he has a backup drive :)
Very bad, because the usability of such a scheme would be a nightmare. If you have to unzip the files every time you need a password, that’d be a huge burden. Not to mention that unzipping it all would leave the files there, unprotected, until you delete them again (if you remember deleting them in the first place). If you do leave the plaintext files around, and only encrypt & zip for backing up, that’s worse than just using the plaintext files in the backup too, because it gives you a false sense of security. You want to minimize the amount of time passwords are in the clear.
Just use a password manager like Bitwarden. Simpler, more practical, more secure.
When we wrote malware in labs in college one of the first places we looked was unemptied trash. This is almost certainly a pattern that’s going to leave your crap in trash in plaintext and even the dumbest script kiddie will find it the very first time you slip and something gets in your system.
Lemmy is, like a lot of Fediverse platforms, about as private as it can be. There’s no trackers, you’re not forced to use real names or any other identifying information, no adverts follow you from site to site, no browser fingerprinting and no instance owners are trying to sell your data.
Beyond that, what you choose to say on Lemmy is your responsibility and yours alone.
I personally enjoy that this sort of information is public, it keeps people honest and gives a tool to use against bad faith actors. People lie. Besides, it’s not like anyone’s forcing you to post personal information online. Some level of responsibility needs to be put on the user.
If Lemmy cared about privacy, contributing source code & opening tickets would not require opening accounts with a for-profit, US-based, closed, prorietary service owned by a publicly-traded megacorporation that has shareholders to appease & a history (as well as current) record of EEE (embrace, extend, extinguish).
I mean it took the code production of from workers for the Commons, packaged it up, & sold it back to the workers—often in violation of the license if not the spirit of free, ethical, or similar software. All AI generations should be CC0 / 0BSD licensed.
Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
privacy
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.