DeltaChat app stops encrypting messages

[wojtekbogusz]

we were testing DeltaChat with a friend. initially both of us on Android phones. app version 0.304.0. then we exported keys (my friend public, i both public and private) and i imported them into Mailvelope (PGP browser extension) and i started to communicate from web mail encrypting messages with Mailvelope. after the first message sent encrypted from web mail with Mailvelope my friends DeltaChat app stopped encrypting messages. i do not know if it makes any difference, but in the first message i was trying to mimic the internal headers of DeltaChat in the body of the message, things like: """ Chat-Disposition-Notification-To: email@address... Subject: =?utf-8?Q?Chat=3A?= text text Content-Type: text/plain; charset="utf-8"; protected-headers="v1" Content-Transfer-Encoding: quoted-printable

text text -- =20 Sent with my Delta Chat Messenger: https://delta.chat """ but then i realised i do not have to. the messages were decrypted and shown properly in DeltaChat app. so i stopped doing headers in the body of the email.

i think it is a bug that my friends app stopped encrypting. i would expect that all messages sent from the app will be encrypted once app has key for the given email address. my friend did not realise that messages are not encrypted because you only see are they encrypted after you send the message with this super tiny padlock on the bottom of the message. i think padlock should be there beside send button same size. it should be locked or unlocked different colours indicating will message be encrypted or not.

one side thing. messages encrypted with Mailvelope did not have padlock showing that they are encrypted even that they were.

ps: thanks for this brilliant app! :-) keep up good work

[r10s]

hi @wojtekbogusz ,

not sure if i understand the issue at all, but here are some common hints that may help:

in general, the encryption of Delta Chat is opportunistic - this means, that encryption stops eg. if your friend changes prefers to use unencrypted messages or if messages were sent in between eg. from a webmailer as googlemail. in these case, the encryption shall not stay in the way of communication. as soon as encryption is possible again, Delta Chat will encrypt again automatically. https://autocrypt.org gives some more information about that.

currently, the log at "settings / advanced / log" may give some hints about way encryption was pauses. i think, in the future, these information will be easier accessible, however, currently, they're only there.

btw. there is also the option to enforce encryption using verified groups.

wrt the lock shown or not: Delta Chat only shows the lock if messages are encrypted and signed - a long click on a message and then selecting "info" may give some hints for a concrete message.

[hpk42]

On Thu, May 09, 2019 at 12:46 -0700, björn petersen wrote:

not sure if i understand the issue at all, but here are some common hints that may help:

i guess the point here is that one non DC user encrypted the mail to a DC user but because of a missing autocrypt header DC replied unencrypted.

This is a corner case that is not explicitely discussed with the Autocrypt spec. Arguably the spirit of autocrypt would be to recognize that the mail was encrypted and if we reply and can do so with encrypting to the key that signed the encrypted mail we are replying to -- we should do so IMO. This requires more precise interaction with the decryption machinery to memorize who signed a message. @r10s if you generally agree (modulo details) we should create a core issue and close this one here.

[r10s]

i guess the point here is that one non DC user encrypted the mail to a DC user but because of a missing autocrypt header DC replied unencrypted.

hm. but replies to encrypted messages should be encrypted anyway - assuming the key is known. however, to be recognized as an "encrypted messages" (having a lock), messages have to be encrypted and signed.

[hpk42]

On Thu, May 09, 2019 at 14:12 -0700, björn petersen wrote:

i guess the point here is that one non DC user encrypted the mail to a DC user but because of a missing autocrypt header DC replied unencrypted.

hm. but replies to encrypted messages should be encrypted anyway - assuming the key is known. however, to be recognized as an "encrypted messages" (having a lock), messages have to be encrypted and signed.

yes, when i say "encrypted" here i always mean encrypted+signed :) are you sure that DCC does not take a missing autocrypt header to mean that the sender lost ability to encrypt ("recommendation: reset or disabled")?

[wojtekbogusz]

Mailvelope was just encrypting but not signing messages. DC was decrypting those messages ok and showing them on the phone decrypted. nevertheless, if i understand correctly, DC considered them not "fully encrypted" (maybe because of missing headers or missing signature) and turned to keep responding unencrypted. not intuitive for me at all :-| obviously there is a difference between a message that is just encrypted and one that is encrypted+signed. maybe they need to be graphically presented differently. but IMHO when DC has a public key for a given email address i think it should always lean towards encryption. and give user a choice to switch encryption off - for example with the log tap on the send button that would give a choice to encrypt or not-encrypt. i think user must know before sending a message will it be send encrypted or not encrypted. user may not want to send some information not encrypted. of course knowing for each already sent message was it encrypted is also important. but there is a need for both. be well :-)

[hpk42]

@wojtekbogusz "always encrypting if key available" goes against Autocrypt logic -- see the prae-ambel of https://autocrypt.org/level1.html and the note on message signing in the FAQ: https://autocrypt.org/faq.html#how-does-autocrypt-interact-with-message-signing

Please take further discussion to https://support.delta.chat as this is not considered as a bug report anymore, but more a feature suggestion and one that needs to be considered in the larger context of the above links.

On Fri, May 10, 2019 at 02:50 -0700, wojtekbogusz wrote:

Mailvelope was just encrypting but not signing messages. DC was decrypting those messages ok and showing them on the phone decrypted. nevertheless, if i understand correctly, DC considered them not "fully encrypted" (maybe because of missing headers or missing signature) and turned to keep responding unencrypted. not intuitive for me at all :-| obviously there is a difference between a message that is just encrypted and one that is encrypted+signed. maybe they need to be graphically presented differently. but IMHO when DC has a public key for a given email address i think it should always lean towards encryption. and give user a choice to switch encryption off - for example with the log tap on the send button that would give a choice to encrypt or not-encrypt. i think user must know before sending a message will it be send encrypted or not encrypted. user may not want to send some information not encrypted. of course knowing for each already sent message was it encrypted is also important. but there is a need for both. be well :-)

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/deltachat/deltachat-android/issues/902#issuecomment-491230732

[r10s]

yes, when i say "encrypted" here i always mean encrypted+signed :)

i know :) however, i wanted to point out that, if delta receives an encrypted-only message it does not treat the message as being encrypted correctly. as a result, the lock is not shown and the "encrypted" state is not set - and replies won't be encrypted as the "reply encrypted to encrypted messages" does not match.

are you sure that DCC does not take a missing autocrypt header to mean that the sender lost ability to encrypt ("recommendation: reset or disabled")?

pretty sure:

1. if a message does no longer contain autocrypt headers, dc_apeerstate_degrade_encryption() is called that sets the peerstate to RESET

2. this RESET causes the all_mutal check to fail using encryption, however, the check for last_msg_in_chat_encrypted() overwrites this decision (all in prepare_msg())

however, again, if the message in 1. or a later message is only encrypted and not signed, this does not cause last_msg_in_chat_encrypted() to return true.

while writing this, the answer from @wojtekbogusz came in :)

Mailvelope was just encrypting but not signing messages. DC was decrypting those messages ok and showing them on the phone decrypted. nevertheless, if i understand correctly, DC considered them not "fully encrypted" (maybe because of missing headers or missing signature)

exactly the latter. proper encryption required encryption and signing. afaik this is also an autocrypt-requirement for various reasons, [OpenPGP Considerations, Part II: Encrypted-Only Mails](https://k9mail.github.io/2017/01/30/OpenPGP-Considerations-Part-II.html is a good read.)

while writing this @hpk42 close the issue :)

[r10s]

/me has to type faster in the future