Encrypt. Now.
Encrypt. Now.
blog.tripu.info Encrypt. Now. — blog.tripu.info
We have come to a point where end-to-end encrypting all your private data and private communications
You're viewing a single thread.
23 comments
-
I have an idiotic request. Since I'm not familiar with the subject, could we be directed to a kind of wiki or megathread on how to actually encrypt our communications?
-
Depends on the application in use. The grail is end2end encryption with asymmetric encryption where no provider has access to the private keys. The difficulty is getting people on a common method where you can just look for your peer and get a public key handed to you without having to fuss around with where it was uploaded.
Maybe the most common/simple would be looking into things like PGP. You and I would both have a public/private key pair. When I send you messages it's encrypted with your public key and signed with my private key, and as a result only your private key can decrypt the message and you know it came from me because only my private key could have signed it.
The ugly mechanics behind it don't need to be anything you actually learn in detail, but just look for apps that offer end to end encryption where the encryption is set up locally rather than in the service provider's host, if the host generated the keypair then functionally it's useless because at that point they have the private key.
-
-
Please don't take this as laziness, but what is PGP?
-
Pretty good privacy. It's an unexciting name for a public/private key encryption program.
-
Thank you kind stranger! I'll look into it more when my kid goes down for bed!
-
-
-
-
As the other commenter mentioned, your best bet is being selective about which services you use to communicate.
Unencrypted (plain text) is the worst, since data is easy for a third party to sniff (think of it as a wiretap). For example, HTTP and SMS are unencrypted.
Encrypted is a good start, since third parties can't sniff your traffic, but the server handling your communications can usually see everything that passes through it. For example, HTTPS is an SSL-encrypted variant of HTTP, and services like Facebook messenger are encrypted, but Facebook can still see all of your messages, since it's stored on their servers.
End to End Encrypted (E2EE) is the golden standard. Only the endpoints (i.e. you and your friend) can see the content of your messages, and all traffic is encrypted in a way that even the server cannot view it. Signal is end to end encrypted, as are many other modern messaging platforms (WhatsApp is E2EE in theory, as is Google Meet, but we can't verify this ourselves).
-
WhatsApp is E2EE in theory
Didn't Signal even work together with them, to implement their protocol?
But anyway, as far as I know, WhatsApp only encrypts message contents, not the associated metadata. So they're still able to learn a lot about you.
-
I believe WhatsApp uses the same protocol (or at least the same crypto algorithms), though I'm not sure if they were involved in its development.
Good point on the metadata. Signal has the "sealed sender" thing, which (I think) helps with the metadata problem somewhat.
-
Metadata and the comm endpoints is one of the hardest parts to deal with. If an intermediary doesn't have a pointer to a destination then delivering a message becomes problematic, envelopes without an address tend to sit in bins. It would be possible to simply store messages and allow recipients to poll for them but that gets really inefficient at scale. Plus it creates a central repo where messages sit until retrieved which is a liability in itself.
Things like OTR encryption are interesting as a transient system ad-hoc type encryption for things that don't need or even want absolute assurance of identity, but if I want to talk to Alice and be sure it's not Eve then it's not ideal.
-
-
-
-
23 comments