
Convenient End-To-End Encryption for E-Mail - doener
https://autocrypt.org
======
tptacek
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 prevent secrets from accidentally being sent in the clear.

* Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. 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.

* Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.

* Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.

* Most email clients are searchable-archive-by-default. Again, if you're using a secure messaging system to keep secrets from a state-level adversary, that's exactly what you don't want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?

Everything that makes email effective in the real world makes it inhospitable
to secure messaging. We should stop trying to push this particular boulder up
this particular mountain and instead just get people to adopt serious secure
messengers.

~~~
aftbit
Unfortunately, Signal is not decentralized or federated (for good reasons[1]).
Email is. This is an important feature for those of us who worry about the
growing centralization of the web, as well as the very many users who still
mainly use email for communication. When you leave a job, you may not keep
your email address, but at least you can still communicate with people across
organizational boundaries.

Anyway, even if email security cannot be perfect, I agree with the sentiment
behind RFC 7435[2] - some protection is better than nothing.

If anything, I feel that they didn't go far enough in this compromise. Most
people interact with their email through the provider's webmail client.
Autocrypt is fundamentally incompatible with this[3]. This means that it will
really not be useful for the majority of users.

1: [https://signal.org/blog/the-ecosystem-is-
moving/](https://signal.org/blog/the-ecosystem-is-moving/)

2:
[https://tools.ietf.org/html/rfc7435.html](https://tools.ietf.org/html/rfc7435.html)

3: [https://autocrypt.org/level1.html#requirements-on-mua-e-
mail...](https://autocrypt.org/level1.html#requirements-on-mua-e-mail-
provider-interactions)

~~~
rollcat
> Anyway, even if email security cannot be perfect, I agree with the sentiment
> behind RFC 7435[2] - some protection is better than nothing.

Opportunistic encryption (or any kind of negotiable security) is prone to
downgrades by a MITM. Either both sides require strong security, or you must
assume lowest common denominator.

While I have your attention, please do yourself a favor and pin some strong,
modern ciphers for your SSH client:
[https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern](https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern)

------
r3bl
Gah, the thing I truly hate about this website is that it doesn't offer me an
answer to the most important question: But what does it do?

I have to scroll down to see the content in the "What is Autocrypt" section.
The content was two sentences long and I still didn't understand what does it
do (I wondered what's an "email program" in this context). Since there was no
additional text to help me out on the homepage, I had to look further.

FAQ page was too technical for such an explanation, implementation status page
gave me some genuine idea that this is _something_ related to _other_ OpenPGP
products instead of a new OpenPGP product. The third page I tried opening was
the "test it" page, which led me to basically nothing out of any use.

And this is not an isolated case, this is more of a rule for project websites.
Seriously, figure out a layman term to explain whatever you're representing
and slap it on top of your homepage. Nobody cares if you're decentralized or
an open standard until we know what is it. "Convenient End-to-End Encryption
for E-Mail" made me believe it was a separate OpenPGP implementation, not a
set of guidelines.

Just one sentence like "a set of guidelines that make email encryption easier"
would make me want to find out more. This way, by the time I found that out, I
have already decided to write this out of rage instead of finding out more.

So, here's a plea to the authors of this website and every other project
website: Please, tell me what your project does right at the top of your
homepage and do not make me chase an answer to that question.

~~~
Valodim
Note taken. Making a website for a tech spec is surprisingly hard after
looking at it for so long :(

[https://github.com/autocrypt/autocrypt/pull/328](https://github.com/autocrypt/autocrypt/pull/328)

------
FullyFunctional
The site could benefit from a to-the-point explanation that doesn't assume
prior experience with PGP based mail. I can't point less technical users to
this.

Does this work if one uses multiple mail clients (fx. notebook, desktop, and
smartphone)?

Since it requires client support, it doesn't seem an option currently on, say,
an iPhone.

~~~
Valodim
Indeed, we are not at a stage yet where pointing "less technical users" to our
website is very useful, since the main take away for those people is "stay
tuned".

We hope to be able to change this as implementations progress.

------
upofadown
To save some hunting around, here is the description of what is being proposed
here:

* [https://autocrypt.org/examples.html](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.

~~~
e12e
How is this better than signing outgoing email, and default to encrypt to
senders who sign their mail?

~~~
upofadown
A signature does not give you a public key. You actually need the pub key to
verify the signature.

I think one could still ask why you couldn't just use a mime section for the
public key in the same way that signatures are often attached.

~~~
e12e
The implied missing steps are a)publish key to keyserver network, and b) get
fingerprint from signature and look up key on keyserver network.

Bundling public key with every mail "feels" a bit heavy handed - given the key
server infrastructure that already exist. (and special-casing "mail to new
receiver" seems cumbersome. At least considering you'd probably want to sign
all outgoing mail anyway[1]).

[1] Ok, maybe not your bomb threats if they're designed to be anonymous - but
that's getting into one of the other issues with pgp - non-repudiation.

------
doener
Here is a description how it works: [https://posteo.de/en/blog/new-easy-email-
encryption-with-aut...](https://posteo.de/en/blog/new-easy-email-encryption-
with-autocrypt-and-openpgp-header)

~~~
gruez
>>The manual exchange and management of keys – which users often perceive as
complicated – is becoming superfluous: Prior to the first encrypted
communication, a regular empty email (without content) is sent. With this, the
key is transferred in the background. Henceforth, messages can be encrypted
automatically.

doesn't sound like they solved the key exchange problem. they merely changed
it to trust on first use.

~~~
FullyFunctional
Which is a common compromise and frankly more useful than the web-of-trust
model, as long as users understand the limitation and verify once offline.

It's still unclear to me how this works if you use more than one email client.

~~~
elahd
This seems like a good use case for keybase.io. They've implemented their own
proof of concept messaging system, but I have yet to see any third party
integrate with the service.

~~~
dane-pgp
keybase.io is another centralized third party which, like Signal, we should be
trying to move away from rather than becoming more dependent on. By relying on
the DNS (which is already trusted to make email, keybase.io, and Signal work),
every service provider can be in control of the keys they are publishing.

Also, keybase.io, being centralized, isn't as auditable as the DNS, but
admittedly there is work being done on both DNSSEC transparency:

[http://blog.huque.com/2014/07/dnssec-key-
transparency.html](http://blog.huque.com/2014/07/dnssec-key-transparency.html)

and keybase.io publishing to the bitcoin blockchain:

[https://keybase.io/docs/server_security/merkle_root_in_bitco...](https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain)

~~~
elahd
I'd say that it's only quasi centralized. At its core, keybase is a directory
of signed statements posted on social media. Where space permits, these
statements include the person's public key. Verifications can be checked
directly on Facebook, Twitter, etc. without using keybase, somewhat
decentralizing the service. As you mentioned, writing to blockchain pulls
keybase further out of the equation.

They're more of a facilitator for other applications -- Signal is a packaged
application itself.

------
twiss
Pretty off topic, but: I've been working on signed web applications:
[http://blog.airbornos.com/post/2017/08/03/Transparent-Web-
Ap...](http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-
Service-Worker). If anyone working on a web-based email client wants to take a
shot at making it completely secure (against the web app's server), shoot me
an email :) in profile.

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

~~~
philipwhiuk
Tackling header privacy is harder in an existing platform. Memoryhole (
[https://github.com/autocrypt/memoryhole](https://github.com/autocrypt/memoryhole)
) has some ideas but it's some way off implementation right now.

------
pcunite
Who is the team or company behind this offering?

~~~
philipwhiuk
Developers from various open-source email clients. It's a protocol, not a
product.

[https://autocrypt.org/contact.html](https://autocrypt.org/contact.html)

------
dbennett455
Send the link to your boss and ask his opinion

~~~
figgis
Say your company needs a new vehicle with specific safety features while still
being convenient. When you find the vehicle that meets the requirements do you
just plop the manual on your managers desk and ask for an opinion?

