Live data from Hacker News

Convenient End-To-End Encryption for E-Mail

autocrypt.org

131–140 of 190 posts

Re: Convenient End-To-End Encryption for E-Mail

#131
post #16

Earlier quoted context omitted.

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

A large problem is that the companies with the money to address the issue will only do so starting from a position of a walled-garden rather than a system like email that in principle is open to anyone's mua/mailserver? We have a proliferation of communication apps that don't talk to each other because each of the capitalistic driving forces wants to kill every other app so there's wins (even if there app is much wor…

*their's, their

Re: Convenient End-To-End Encryption for E-Mail

#132
post #112

Earlier quoted context omitted.

I have colleagues and students that don't use smart phones. As much as I agree with your sentiment, the unfortunate truth is that right now there isn't a good drop in replacement that we could move to. Signal is drop in for WhatsApp and I can tell everyone I talk to on WhatsApp to just contact me on Signal instead. What do I tell people to move to from EMail?

WhatsApp is an ok substitute for Email in my opinion. Sure, it is not open source and but federated. Signal, Wire, Matrix, etc should catch up in the next years. What do you need from Email that a messenger lacks?

In consideration of the fact WhatApp is owned by a single company (facebook), which gets all the metadata, how is it federated?

Re: Convenient End-To-End Encryption for E-Mail

#133
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Intra-organizational email is pretty secure. Like where I work, we’re all on gmail with client carts.

Re: Convenient End-To-End Encryption for E-Mail

#134
post #32

Earlier quoted context omitted.

> It's that we should stop using email pretty much altogether. Like I said: it's archaic Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.

Yes, you can write as long a message as you want with signal. There are desktop clients. You can attach files. Or voice messages. Or use it to call them. Or video chat them. It’s a crazy robust full featured incredibly secure communications system.

> There are desktop clients

You mean the ones with Electron, using 5% of your CPU idle, requiring you to have first registered your smartphone with it before it can even work? That's not what I call a functional desktop client.

Re: Convenient End-To-End Encryption for E-Mail

#135
post #12

Earlier quoted context omitted.

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

> That's false. There are mechanisms for lost keys revocation. This is already a solved problem. This is very dangerously wrong. Revoked keys decrypt old data just fine. Revocation is advisory. Your attacker will choose to disregard that advice and decrypt anyway. > And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any…

> A secure network protocol is only secure if it's incapable of being insecure.

As long as an email leaves from your computer in encrypted form, what is the point of failure as long as you are careful with your private key?

Re: Convenient End-To-End Encryption for E-Mail

#136
post #53

Earlier quoted context omitted.

I love signal and kinda-sorta agree, but a) Right now Signal is oriented around your hpone # and while most people have phones, they come at a cost, are less easy to acquire than an email address, and much less anonymous b) Signal (and slack and so on) organize conversations around individuals and groups, rather than around subject. That's OK for personal contacts (with whom you have conversational context) but not s…

Signal != Signal Protocol. I like Signal and prefer it to the other applications, but Wire (for instance) does not need your phone number.

Wire does not need your phone number per se, but the Wire client on phones basically suggests by default to use your phone number as an identifier, if you create your account from your phone. That's a pretty poor way of doing things, especially if you are supposed to guarantee privacy.

Re: Convenient End-To-End Encryption for E-Mail

#137
Metadata is more important than content. Metadata is surveillance. There is no way to hide metadata with computers. The only way to get around this is through anonymity. You put the info out there, but it can't be correlated to you by someone else except your intended recipient. This is approaching impossible even with the best, security-minded infosec professional. The safeguards you need to employ are very extraordinary. One slip-up, UR-FCK'ed.

OPSEC is not retroactive.

Re: Convenient End-To-End Encryption for E-Mail

#138

Earlier quoted context omitted.

> Most email users get their email from a website. I'd argue thats not the case. Business users are likely still using outlook/etc. Personal users are likely using their smart phone for email. Also by what standard is pgp "the most popular". Its popular with technical people sure, but there is fuck all support in commercial mail clients. S/mime is supported, and due to ca roots, doesnt require you keep using the sams…

Thunderbird and apple mail are both very popular clients that support PGP via plugins.

I use the pgp plugin for apple mail on my mac, but I wouldn't want to rely on it for anything business critical.

It's usually months after a macos/mail.app update before the plugin works again.

Theres no equivalent option for iOS. There are alternative solutions but nothing as seamless.

S/MIME is supported out of the box. For bonus ease of setup, I can install the current private key + cert pairs I need with a single provisioning profile.

Re: Convenient End-To-End Encryption for E-Mail

#139
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

I'm not sure what the problem you are having is here. Transport can be secure with TLS. Content can be secured with smime or even archaic and ancient pgp. Leaky metadata is a problem with every protocol that can be routed. Oh, and email is one of the few things on the internet that universally works...

Re: Convenient End-To-End Encryption for E-Mail

#140
To save some hunting around, here is the description of what is being proposed here:

* https://autocrypt.org/examples.html

Basically you include your public key in a "Autocrypt:" header line added to all messages you send out. Then encryption transparently happens.

So we give up some protection against MITM attacks but get protection against passive surveillance for people who are not willing or able to participate in a web of trust. All and all a good idea. Because this works with standard OpenPGP messages it would be good if we could tell what level of protection we were getting when we view a message.

Post reply on HN