Gossip in verified groups should not affect key used in non-verified chats

[link2xt]

Currently DC uses three keys:

• public key, received in Autocrypt header
• gossip key, received in Autocrypt-Gossip
• verified key, received in Setup Contact protocol or in verified key gossip

Consider the following situation:

• A installed DC and generated key K1
• B has verified key K1 with A
• B created a verified group A-B-C with A and C and gossiped verified key K1 to user C there. C now knows verified key K1 of user A and uses it as verified.
• A has reinstalled DC and generated key K2.
• A has started a non-verified chat with C. C now uses key K2 to encrypt messages to A in non-verified chats, but uses key K1 to encrypt messages to A in verified chats.
• B sends a message in group A-B-C and gossips key K1. C applies it as a gossiped key.
• C sends a message to A in non-verified chat. It is encrypted with K1.
• A can't decrypt the message.

The problem is that gossip in verified groups may distribute old key indefinitely, until B verifies a new key with A or A gets a new verified key via verified group gossip. Until then, A will always gossip key K1 in verified groups, while B will distribute key K2 in Autocrypt header.

To fix this, Autocrypt-Gossip processing in verified groups should be changed to only affect the verified keys. There are two places that needs to be changed:

1. mimeparser calling apply_gossip, or apply_gossip itself:

   deltachat-core-rust/src/mimeparser.rs

   Line 882 in ca95f25

   peerstate.apply_gossip(header, message_time);

2. dc_receive_imf calling set_verified for gossiped key:

   deltachat-core-rust/src/dc_receive_imf.rs

   Line 1555 in ca95f25

   peerstate.set_verified(

Instead of saving the key as gossiped key and then updating the verified key, the verified key should be updated directly, without changing the gossiped key.

[link2xt]

C sends a message to A in non-verified chat. It is encrypted with K1.

Well, this is actually not true. peerstate.take_key and peer_state.peek_key use public_key and only fallback to gossip_key if there is no public_key. So the only problem in this case is the annoying system message saying that parameters have changed when gossip_key is updated to K1 -> K2 -> K1 -> ...

Gossiped key is only used if C has never received an Autocrypt header from A and has public_key for A set to null.

[link2xt]

Related issue from the comment in dc_receive_imf.rs: nextleap-project/countermitm#46

[link2xt]

Related PR which makes this problem much less annoying: #1829

Verified group gossip may change gossip_key, but as long as you have public_key which is not changed, messages about setup change will not appear.