K-9: Can't send PGP message that is encrypted, but not signed, since 5.200

[boskamp]

Expected behavior

Compose new message. Select a recipient whose public PGP key I have. Enter message subject and body. Tap the lock symbol right to the sender (i.e. my) name. Change setting from "Encrypt if possible" to "Encrypt". Continue. Send message. Message is sent.

Actual behavior

Message CANNOT be sent. Popup shows the following text (translated from German): "No signing key is configured. Verify settings."

Steps to reproduce

I use a PGP environment with separate subkeys for signing and encryption. On mobile devices, I only have the encryption subkey, but not the signing subkey and also not the master key. Hence, I can decrypt only, but not sign. That's exactly what I want.

If your interested in the full rationale, German computer magazine c't has an in depth article about it in issue 27/2015.

It seems that starting with k-9 5.200, I can only sign and encrypt, but not encrypt only. This seems like a regression from 5.010 and earlier. In those versions, there were two separate checkboxes "Sign" and "Encrypt" in the compose new message dialog, so the "encrypt only" use case worked perfectly.

Here's my debug log, in case it helps: k9-log-2.txt

Environment

K-9 Mail version: 5.201 (also 5.200)

Android version: 4.4.4 (CM 11-20141115-SNAPSHOT-M12-i9100)

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

[SecTec]

I have to make a suggestion...
I dislike the encryptions slider since it was introduced, because it only sets the encryption mode.
Why not the slider for encryption and a tick for sign or not sign. (Or a second slider...)

EDIT: And yes I know that there is the tick in the
Settings --> Account --> Cryptography --> Sign every mail

It would be better placed in the dialog where the encryption slider is.

[Valodim]

Encryption without signing in the context of communication is a misfeature that should never have been introduced by implementations. We're not going to have it.

I'm going to write a blog post about this soonish.

[shtrom]

Hum, this is annoying. How to provide confidentiality while retaining plausible deniability without encrypt-only? Arguably, as the message is encrypted, the signature is harder to get to, but a rubber hose can help jump this issue.

[Valodim]

There is nothing "plausible" about any deniability properties in email, since so much metadata is leaked anyways.

[shtrom]

I agree it's a poor baseline medium for privacy due to most of the metadata being in the clear; this, however is a confidentiality problem; we can't encrypt the headers end-2-end. Email metadata is also very easily tampered with and forgeable, so it on its own is no guarantee of an authentic communication.

Signing applies to the (hopefully encrypted) content, not the metadata. There is quite a step between retaining a plausible deniability that you did not actually write this content by not signing communication, and positively claiming that you did indeed write this content, leaving anyone who comes across it and the signature to use as they please, potentially against you.

The ability to write communication that can be later forged for plausible deniability is what OTR uses, for example, for private communication even over media that would otherwise leak metadata (e.g., unencrypted XMPP). I think an similar feature is desirable for email communication, too.

[sharpe5]

@Valodim Quoted:

Encryption without signing in the context of communication is a misfeature that should never have been introduced by implementations. We're not going to have it.

What if I am the sender, and I am the receiver?

Example: I send an email from my Android mobile to my PC, that contains confidential meeting notes. In this use case, I don't want my public key on my android, as anybody can pick up my cellphone and grab my public key, then read my communications from that point on.

This is why I opened #2175, because I havn't been able to send PGP email using K9 since K9 switched to OpenKeyChain.

Note that OpenKeyChain supports this use case. I can encrypt to clipboard using OpenKeyChain, then paste this into K9. However, this is slow and nasty from a usability perspective. I've send thousands of emails this way over the last few years, and its just too slow to switch that method.

Why is K9 preventing this use case?

[Valodim]

(for the record) See this blog post for our reasoning:

https://k9mail.github.io/2017/01/30/OpenPGP-Considerations-Part-II.html