K-9: K-9 mail fails to encrypt emails by default, even with "Autocrypt mutual mode" enabled

[bowmasters]

K-9 mail fails to encrypt emails by default, even with "Autocrypt mutual mode" enabled

Expected behavior

When sender and recipient have both enabled "Autocrypt mutual mode", encryption should be enabled by default and the "green lock" symbol should appear when composing messages.

Actual behavior

Encryption is not enabled by default - the "grey struck-through lock" symbol may be shown, but sometimes no lock symbol is shown at all.

Steps to reproduce

1. Enable autocrypt mutual mode under Settings > Account Settings > Cryptography > Autocrypt mutual mode
2. Compose a new message to a recipient who has also enabled autocrypt mutual mode and you've exchanged encrypted mail with (or just compose an email to yourself)
3. Observe that it does not encrypt by default

Environment

K-9 Mail version: 5.503

Android version: 7.1.2

Account type (IMAP, POP3, WebDAV/Exchange): IMAP

Additional notes

This just further highlights the problems created by the imprudent decision to remove encryption by default and the dubious justifications for doing so.

Consider the issues posed by "non-consensual encryption by default" (as the aforementioned blog post pejoratively and misleadingly calls it):

"Encrypted messages cannot be viewed in all clients and especially web clients, full-text search is typically restricted, and if the user loses access to their keys there might be unintended loss of messages."

Now compare those to the potentially catastrophic (perhaps even life threatening) consequences of failing to encrypt sensitive information when the user is expecting it to do so by default (or forgets to click the dim, inconspicuous, and easily overlooked grey lock icon) and it should be patently obvious that the consequences of the latter scenario are FAR more severe than the relatively inconsequential "convenience" issues of the former.

If you can only optimize for one, mitigating the latter by enabling encryption by default (thus putting the onus on the user to manually disable it if they don't want it) should take full precedence over any concerns about convenience. To do differently is to have priorities that are completely disjointed from the realities faced by the vast number of people who elect to use encryption to protect their communications in the first place. It doesn't just "break the workflows of a couple of users".

Ideally, both can be satisfied by allowing the user to choose the default behavior that suits them in the settings. But when the setting fails to work, as it did in this case, not encrypting by default means that it fails-deadly.

Please consider this and restore the sensible, fail-safe encryption by default.

[jscott0]

Compose a new message to a recipient who has also enabled autocrypt mutual mode and you've exchanged encrypted mail with (or just compose an email to yourself)

I've confirmed also on K-9 5.503. Sending an email to myself, even after sending one before in which encryption and signing were manually enabled, was not encrypted nor signed by default in the new message as the mutual mode would imply.

Replies to myself, however, were encrypted and signed by default if the original message was, but that may have nothing to do with it.

Of course, this could be specific to emailing myself, so I'd like to test mutual mode with @bowmasters or anyone else interested in this issue.

[deadw00d]

I can confirm the same behavior with K-9 5.600 testing between two difference accounts. Replying to message gets automatically encrypted, while new messages do not. I already send a few un-encrypted messaged "by mistake" since the functionality has been removed and I was really looking forward to "Autocrypt mutual mode" to bring that functionality back. However it does not work as I would expect it.

[scarshot]

Here the same. Please add a expert option to force gpg encryption.

[madpsy]

I'm also seeing this (v5.600). In addition to this (and it could be the cause) the check box in mutual mode seems to untick itself randomly. By random I mean if I enable it, come out of settings, go back in and it's fine but then an amount of time later I check it again and it's mystically unticked itself.

[b3yond]

@madpsy can you put more details into #3703 ?

[doak]

Which builds are you using?
I have the same issues wit the v5.600 from F-Droid.

[xandro0777]

ROFL - folks you are talking about AUTOCRYPT. The weakest security model possible and irreparably broken by design.

If anyone of you would entrust your life to this consider yourself dead.

[doak]

@xandro0777, nice try for some OT flame war. Feel free to elaborate your statement and to refer to specific, in your opinion, broken parts including proper rationale.
Without these information your statement (and any upcoming) is obvious trash only.

[xandro0777]

Autocrypt documentation states that it does not protect against MITM attacks. If your life isn't worth you better security ...

[doak]

Autocrypt documentation states that it does not protect against MITM attacks.

@xandro0777, please link or cite that documentation. Neither FAQ nor spec of level 1 seems to state something about MITM.

Be aware of Autocrypt's roadmap: Level 1 is not designed to be bullet-poof. For sure automatic key exchange is attackable in general. For the same reason Whatsup's e2e encryption is not safe. Which regular customer will take care if the security number has changed (in case Whatsup notifies the user at all, I don't know)?!

Source: https://autocrypt.org/level1.html

Level 1 makes it easy for users to encrypt, based on an automatic and decentralized key distribution mechanism. There are no dependencies on key servers and it is meant to work with existing e-mail providers

The aim is to get encryption into email communication per default for the masses (like OMEMO/Whatsup did for chats). For that reason you (sadly) need automatic key exchange etc. Nevertheless, the underlying technology, namely OpenPGP, is absolutely safe.
As soon as level 1 is rolled out (i.e. clients support that stuff, email providers do not strip/mangle with Autocrypt headers, users have a running OpenPGP toolkit and got used to it), time is ready for an improved level (in respect of security). If you life depends on encryption, you should probably already use OpenPGP and you should be able to use it. That is definitely not the aim of Autocrypt level 1, but it does not interfere with safety.

Very important: https://autocrypt.org/background.html#design-differences-from-previous-approaches

Protect first against passive data-collecting adversaries, resist the temptation to early-add complexity which aim to prevent active attacks. See RFC7435 A New Perspective for some motivation of this and the next points.

tl;dr

Although you are right, that Autocrypt level 1 does not protect you from targeted attacks, it is able to shift the email communication to a much higher level (eventually!). That is the base to to shift it to the next level again.
For that reason, it is a very bad job to criticise Autocrypt level 1 for something it never complained to satisfy, especially without citing relevant parts.

Still open ...

Autocrypt documentation states that it does not protect against MITM attacks.

Please state which MITM scenario you are talking about. And please also state why Autocrypt level 1 is "irreparably broken by design".

[doak]

To conclude: It is really a mess, that even six years after Snowden, 13 years after I personally started playing around with GnuPG and 21 years after its RFC of 1998, our (whole society, lawyers, journalists, ...) usual e-mail communication is neither end-to-end encrypted nor signed.
The concept of Autocrypt can IMHO be the breakthrough -- I see a significant chance for the very first time.

[xandro0777]

@doak: you say autocrypt 1.0 is not bulletproof. I stand by my original statement - if you would entrust your life to autocrypt consider yourself dead. Optimism has no place in good security design. We are not dealing with random bullets but with adversaries which will deliberately target every weakness left - any exploitable weakness is equivalent to being doomed.

Autocrypt is by design vulnerable to a wide range of active attacks, accidental malfunction and security downgrade triggered by spam, as well as deliberate DOS and opportunisitc eavesdropping by anyone who can spoof email addresses. Authors of the standard say its security depends on a working spam filter - does that sound like strong security? Wild guess.. pretty soon spammers will start inserting fake autocrypt headers to improve ham/spam score of their messages.

Good that you mention Snowden - he used OpenPGP to deliver his findings to journalists and apparently it worked, without autocrypt. And it is a nice reading how he did it. Good security is damned difficult but not impossible to teach to an average journalist. OpenPGP and long before that PGP were for decades unrivalled in security and nightmare of secret services all over the world as Snowden nicely demonstrated. Near perfect security required certain effort like key signing parties or other means of oob key verification and nontrivial setup.

Autocrypt is much easier to use but so far offers zero to marginal security gain over plain unencrypted email. Nowadays pretty much all MSPs offer encrypted connections and delivery between MSPs tends to be encrypted as well, hence very little chance for your neighbor to eavesdrop. Or if he can you have bigger problems. However both target and origin MSPs are in the perfect position to MITM autocrypt. If your adversary is a blood thirsty dictator, make sure none of your software and contacts use autocrypt. If your adversary is anyone with a surveilance court order, forget autocrypt. In addition to MITM if your adversary is anyone who can spoof email addresses forget it.

Talking about future.. my fear is that the blatantly weak autocrypt security design together with a slew of inconsistent and buggy mua implementations will be the last nail into the coffin of email encryption. No need for autocrypt 2.0. Not only will autocrypt users be very vulnerable but by interoperability and bugs the security of old style OpenPGP will be annihilated.

Compare Autocrypt security design with that of Signal messenger protocol. Imho no need to waste resources on something so inferior.

[doak]

@xandro0777, I guess we agree on the weakness of Autocrypt level 1 but differ on the impact for the future. All your stated points are absolutely valid. Although I need to check how Autocrypt and manually certified keys work together (i.e. if a casual implementation combined with an advanced user could lead to successful attacks). But yes, to really get bullet-proof security (which is the top requirement at the end), you need to select trusted parties manually. My hope is that Autocrypt's implementations/spec does not interfere with this, but I can't proof on this yet. If it interfere in an insecure manner, your are absolutely right.

Regarding bootstrapping of security, I still value non-perfect solutions which works for the masses. I changed my mind about this in the last years. People are just unable/unwilling to configure just something simple like an email client. Before automatic configuration of this (respectively "dedicated" apps for different providers), they just used web frontends and didn't receive emails on their phone. For years! They are even unable to distinguish a passphrase prompt from OS, the email client or anything else. Even for the "good" case, i.e. no malicious attack.

My point is, though I don't like this and I always stress that we (the society) need to learn this ("everybody who wants to do financial transaction online needs to be able to verify the connection"), we (the IT, the developers, the security aware people) need to push this and also lower the entrance.
I guess we even could agree on that and on the fact that "security of old style OpenPGP" must not "be annihilated".

There is another fear I have, which probably is the driver for me to accept "non-prefect" security starter implementations nowadays: I fearful await the time when the usage of (strong) encryption will become suspicious, which is the base to change laws to prohibits strong encryption. The longer encryption is not used by the masses and not valued by the society as default and required, the higher the risk is for that scenario. The claim "you don't need to hide something if you aren't a bad guy" is still in most of our (the society) heads :(

Thanks for your comments and discussion (although OT in this issue). I just value some points more "liberally" and I am a bit more optimistic in this regard.
Anyway, is there any place (XMPP, blog, etc.) where you discuss security related stuff?

[aryoda]

What is the status of this bug?

I have K9 v5.600 and no idea how to use autocrypt (no end-user documentation found, mails are unencrypted despite enabling autocrypt support in K9)

[scarshot]

A simple solution: A checkbox with "Force encryption" in expert options...

[aryoda]

Where can I enable the "expert options" in K9?

And: Will this try to encrypt every email with autocrypt then?

[bowmasters]

@aryoda, there is currently no option to enforce encryption. I believe @patrickvandijk was suggesting someone could add a checkbox in the options to force encryption as a solution to this issue.

In any case, you may be wasting your time here. The lead dev(s) have made it pretty clear in this blog post that they don't personally believe encrypting emails automatically is important, And it's been nearly two years since they crippled the encryption and don't seem to be in any hurry to fix it.

You may have better luck trying to convince the Librem Mail fork to fix this bug. They seem to have more active recent development and a more responsible attitude towards encryption, so you may get more traction there: https://source.puri.sm/liberty/mail/android

Or you could try implementing the simple checkbox on your own and hope someone merges your pull request

[rgpublic]

This is terrible. Does anyone at least know why it happens? Is it just random or is there a workaround? Autocrypt is enabled for sender and receiver. We've exchanged multiple mails. But still, new mails are not encrypted by default no matter what I try. Sorry for the harsh words but in my opinion that was a seriously dumb decision.

I have public keys from people in my key store for a reason. And then I write a mail, but still it isn't encrypted. You remove a perfectly simple and even for novices easy-to-understand option (you have a public key of someone, you write them encrypted mail), recommend enabling AutoCrypt (which would be perfectly okay for me as a workaround) but then enabling this option doesn't have any effect. You just can't make this stuff up.

And the blog post explaining why this is introduced is so extremely flawed in its argumentation that I just don't know where to begin with. If I'd put on my tinfoil hat for a moment, I'd almost assume this is done intentionally to keep people from encrypting mails.

But, okay, I understand there's probably no real way forward here (ironic how the blog post claims it's "the only way forward" while the exact opposite is true) since this mess seems to be intended.

AquaMail unfortunately doesn't support PGP. Would even pay for it. There is a new player called "FairEmail", but the author also has very peculiar ideas. For example, you have to confirm every link you click in a special dialog window. Unusable in a commercial environment where you get lots of mails from JIRA etc. everyday. But perhaps it works for some people.

Sad that in 2019 this is still so unnecessarily broken at a time where Thunderbird has vowed to modernize their PGP support and deliver it built-in without a plugin in the future. Now, we'd only need a decent mail client with PGP support for Android. Sigh...

[xandro0777]

And the blog post explaining why this is introduced is so extremely
flawed in its argumentation that I just don't know where to begin with.
If I'd put on my tinfoil hat for a moment, I'd almost assume this is
done intentionally to keep people from encrypting mails.

Intention or not, the result is exactly:

• fewer people encrypt
• key exchange is so easily sabotaged or spoofed that the resulting encryption is utterly useless
• additional few kilobytes email headers overhead for every email, encrypted or not

As a consequence I turned it completely off in k9 and only use email encryption in trusted MUAs. Fortunately you can install eg "mutt" in Termux and enjoy completely sane and trusted encryption.

I wish this Autocrypt had never been invented.

[theAkito]

I am very disappointed seeing the people in charge being so neglectant of encryption. In fact, I changed to K-9 in the first place, because the encryption did not really work in another competitor app.
I hope there will be a sufficient resolution to this issue, ASAP.

I want encryption for all e-mails to be the absolute default. I personally do not want to have an option to send unencrypted messages. I would rather prefer to disable the way to send unencrypted messages, than making it extra tedious to send encrypted ones.

[doak]

Is this issue still valid?
I've tested beta build ~v5.702~ (edited: v5.703) in respect of that and it seems to work like expected:

• Creating a new message to someone with Autocrypt mutal mode enabled encrypts automatically. It is possible to disable it manually.
• Creating a message to someone with an available key (but w/o mutual mode) enables a button to switch encryption on manually.
• Adding some recipient w/o mutual mode disables encryption but leaves the option to switch it one manually.
• Adding some recipient w/o a public key disables encryption but shows a red warning icon and informs that encryption is not possible.
• A small indicator icon (a lock) is shown during email address selection if a key is available.

Look fine so far.
Thanks @cketti, btw :)

Be aware that this beta still contains several important issues (no IMAP push, buggy subject encryption, missing gestures, etc.), thus is imho not recommended for broader use.

[theAkito]

Is this issue still valid?

Be aware that this beta still contains several important issues (no IMAP push, buggy subject encryption, missing gestures, etc.), thus is imho not recommended for broader use.

I think it'd be fine closing it, if it works completely when released, i.e. when coming out of beta.

[mdosch]

Still happens for me in 5.704 fdroid so I guess it's still not fixed.

[doak]

@mdosch, are you aware that the last received/processed message from the corresponding contact needs to have mutual mode switched on (prefer-encrypt=mutual) to let Autocrypt enable encryption by default? If so, how did you double check that?

See also https://autocrypt.org/level1.html#autocrypt-internal-state.

[mdosch]

I used k9 to write an email to my wife also using k9. Both of us have mutual set but only replys are encrypted new messages are not.
I also had a look at the header of the last messages and mutual is set there.

Am February 11, 2020 9:35:38 AM UTC schrieb doak [e-mail]:

@mdosch, are you aware that the last received/processed message from the corresponding contact needs to have mutual mode switched on (prefer-encrypt=mutual) to let Autocrypt enable encryption by default? If so, how did you double check that?

See also https://autocrypt.org/level1.html#autocrypt-internal-state.

[doak]

@mdosch, if you don't mind I will contact you via email (your blog email address). Let's see if (and how) it works the encrypted way.

[lemmy]

I'm observing the exact same behavior (only replies are automatically encrypted) as @mdosch describes above

[doak]

@mdosch and me tested it with each other without previous knowledge of keys which worked. We forgot to try to create a new e-mail (but only replied to each other). I just tried it right now and it worked as well.

He still has issues with another contact, like @kuppe.

We need to catch that issue ...
Could it be that some internal state of previous versions interfere? Can you both try it with a fresh configuration?

Regards,
doak

On 11 February 2020 17:55:27 CET, Markus Alexander Kuppe [e-mail] wrote:

I'm observing the exact same behavior (only replies are automatically encrypted) as @mdosch describes above

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/3451#issuecomment-584735674

[mdosch]

I'll check with a fresh install when I find time.
Maybe during the weekend.

On 11.02.2020 09:18, doak wrote:

@mdosch and me tested it with each other without previous knowledge of keys which worked. We forgot to try to create a new e-mail (but only replied to each other). I just tried it right now and it worked as well.

He still has issues with another contact, like @kuppe.

We need to catch that issue ...
Could it be that some internal state of previous versions interfere? Can you both try it with a fresh configuration?

Regards,
doak

On 11 February 2020 17:55:27 CET, Markus Alexander Kuppe [e-mail] wrote:

I'm observing the exact same behavior (only replies are automatically encrypted) as @mdosch describes above

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/3451#issuecomment-584735674

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/3451#issuecomment-584747621

[rgpublic]

Still doesn't work for me. I found out, that the checkbox [x] Autocrypt mutual mode is unchecked after I reboot my smartphone. So it seems the checkbox state somehow doesn't get saved properly.

[Newbie1980]

I asked about this today hoping it was changed. It seems not and was told it won't be either.
Any alternatives?

[xandro0777]

Any alternatives?

Termux + Mutt is afaics the only working combination for email encryption on Android. I use it for classical PGP but supposedly also works with Autocrypt.

[Newbie1980]

Any alternatives?
Termux + Mutt is afaics the only working combination for email encryption on Android. I use it for classical PGP but supposedly also works with Autocrypt.

Thanks. That already sounds above my head.
I was looking for something similar to K9 that would send only encrypted and not have the room for error of someone sending non encrypted mails.

Right now im using an ancient version of K9

[cketti]

Tested with 5.717. Composing a new message when both I and the recipient have Autocrypt mutual mode enabled automatically enabled encryption for me. This didn't work when composing a message to myself. I created issue #4867 for that bug.

If this is still not working for you in a current beta version please create a new issue and provide detailed steps to reproduce the issue. Please also include a debug log.

Closing and locking this issue. For finding another client or other discussions please use the support forum. This repository is watched by over 350 people who will all be notified for every new comment.