Bidirectional verification

[link2xt]

This PR separates the concepts of "forward verification" (moving the key into verified_key slot of the peerstate) and "backward verification" (getting an indication that contact has verified our key by receiving a Chat-Verified header, vc-contact-confirm message or vc-request-with-auth message).

Forward verification is now set when fingerprint is checked. Bob forward-verifies Alice when {vc,vg}-request-with-auth is received or immediately after scanning the QR code when taking a shortcut.

Bob sets backward verification when vc-contact-confirm is received or vg-member-added adding Bob by Alice is received. This is not supposed to be secure, tricking Bob into believing that Alice has correct verified key for Bob is not very interesting. Backward verification is also set when a message with a Chat-Verified header is received to opportunistically recover from the case when vc-contact-confirm/vg-member-added is lost, but in general Bob should just rescan if green checkmark did not appear.

Alice sets both forward and backward verification when {vc,vg}-request-with-auth is received.

Closes #1177
Closes #5062
Replaces #4914

[Hocuri]

link2xt: The main point of this PR is moving forward verification to the correct place where we check the fingerprint or AUTH code. Backward verification is added to avoid breaking existing behavior and marking the contact as verified before the protocol completes.

iequidoo: The PR overall is fine, i'm only about that part adding the backward verification to the peerstate and the db.

The point of this PR is to split up verification into forward verification (i.e. I verified my contact) and backward verification (i.e. I think that my contact verified me). Leaving away the backward verification now would introduce new bugs; sure, we don't know how bad these bugs would be in practice, but I don't really want to try it out. E.g. if I have no indication that a contact verified me, then I shouldn't just add them to a verified group. Sure, sometimes this information is stale, but in many cases it's not. And as discussed in #4932, it would be nice to let QR codes expire; in this case, it will be nice that Bob can do a one-sided verification if he already knows Alice's key.

TL;DR: I do think that we need backward verification, and this PR looks fine overall, even though I didn't have time for a detailed review.

[iequidoo]

The point of this PR is to split up verification into forward verification (i.e. I verified my contact) and backward verification (i.e. I think that my contact verified me). Leaving away the backward verification now would introduce new bugs; sure, we don't know how bad these bugs would be in practice, but I don't really want to try it out. E.g. if I have no indication that a contact verified me, then I shouldn't just add them to a verified group. Sure, sometimes this information is stale, but in many cases it's not.

I'd not call it "bugs", but "probability of unwanted behaviour". I just worry that the backward verification may be restrictive and sometimes stay on the way of secure communication. E.g. impossibility of adding a contact to some chat if we missed a verification message. E.g. not showing a green checkmark when we actually can trust the contact (this may stop the user from communicating with the contact). But if we're ok with all this, then the only question remains for me:

But if we have Alice's key verified via gossip, probably Alice has our key verified via gossip too, no? Doesn't it work this way now (so we can add gossip-verified Alice to protected chats)? And don't we restrict this too much with requiring the backward verification?

So, from now we need to wait for any message from gossip-verified Alice to be sure we're backward-verified. Before this, Alice will be shown to us w/o a green checkmark (while being in the same protected chat), so we even can't contact them safely (at least we would think so).

[Hocuri]

Sorry, I'm still not fully done reviewing, but I'm almost through and don't think I will find anything else (what's left is verifying that the refactorings didn't introduce any accidental changes) - from my side, only #5089 (comment) ("This will break compatibility...") is actually a blocker, the others are more nice-to-haves.

[link2xt]

I have merged #5116 into this PR.
There is #5167 on top that I would also like to merge.

[link2xt]

This is really ready for review, would like to merge soon so we have time to test it before next release.

[iequidoo]

The only question remaining for me -- if Alice adds Bob to a protected chat with Claire so that they become gossip-verified for Bob, what are we going to have as compared to the current behaviour? Can Bob safely communicate to Claire? I think that yes, but how the user should know that?

[link2xt]

The only question remaining for me -- if Alice adds Bob to a protected chat with Claire so that they become gossip-verified for Bob, what are we going to have as compared to the current behaviour? Can Bob safely communicate to Claire? I think that yes, but how the user should know that?

See mark_recipients_as_verified, we optimistically mark the contact as forward-and-backward verified assuming it received the gossip by calling peerstate.set_verified() and setting backward_verfified_key_id. This might be wrong if some contacts did not receive "member added" message, but not worse than before this change.