Secure-Join protocol may have bugs / produce inconsistencies #1177

flub · 2020-01-15T08:14:50Z

Bob verifies Alice even if Alice's vg-member-added or vc-contact-confirm message was not signed/encrypted
QR-joining a non-verified group relies on this bug. The current flow of messages does not allow for Bob to verify Alice in this case, but the implementation verifies Alice.

So question is how should we fix this? The protocol for QR-joining non-verified groups needs to change, but which way?

Do we want to keep the property that QR-joining a non-verified group verifies the inviter & invitee?
If not can we come up with a much shorter group-join option?

flub · 2020-01-15T08:24:31Z

For a non-secure-join we could be concerned about someone changing the first message from bob to alice. In which case we need to run a full setup-contact flow first, after which alice can join bob to the group. For this we'd probably need tweaks to the QR-code and state so alice knows there is still something to do at the end.

hpk42 · 2020-01-15T08:53:16Z

I am not convinced yet it is true what you are claiming quite factually here :)
Could you state the line numbers in securejoin.rs where you think something goes wrong or is missing?
To me appears on first glance that the checks for proper encrypt+signed status of messages is ok for the setup-contact part of the securejoin protocols.

flub · 2020-01-15T09:13:50Z

deltachat-core-rust/src/securejoin.rs

Line 602 in 8f8db0c

let vg_expect_encrypted = if join_vg {

is problematic. The problem is that for bob to know alice is verified in the verified-group protocol alice needs to send a signed & encrypted vg-member-added. But instead we are trying to allow this to be not verified while later verifying alice anyway:

deltachat-core-rust/src/securejoin.rs

Line 626 in 8f8db0c

if mark_peer_as_verified(context, &scanned_fingerprint_of_alice).is_err() {

.

From verified-group or setup-contact protocol point of view at this point we need a signed & encrypted message from alice. For joining a non-verified group alice may need to send the Chat-Group-Member-Added message plain text.

And finally I'm not sure if bob can know if they're joining a verified group or not (the line at

deltachat-core-rust/src/securejoin.rs

Line 604 in 8f8db0c

let (_, is_verified_group, _) = chat::get_chat_id_by_grpid(context, group_id);

just always says it is not a verified group because that's its failure mode and the chat doesn't exist yet so it fails)

hpk42 · 2020-01-15T11:58:03Z

On Wed, Jan 15, 2020 at 01:13 -0800, Floris Bruynooghe wrote: https://github.com/deltachat/deltachat-core-rust/blob/8f8db0c43108e8a9386f89df23bee7ed45836a3f/src/securejoin.rs#L602 is problematic. The problem is that for bob to know alice is verified in the verified-group protocol alice needs to send a signed & encrypted vg-member-added. But instead we are trying to allow this to be not verified while later verifying alice anyway: https://github.com/deltachat/deltachat-core-rust/blob/8f8db0c43108e8a9386f89df23bee7ed45836a3f/src/securejoin.rs#L626.

L626 Bob calling "mark_peer_as_verified()" will return an error if Alice's autocrypt-key does not match the QR-mediated key-fingerprint of Alice. So Bob will only mark Alice as verified if she has been sending the proper key (in the previous step 4 with the vc-auth-required message). There is thus no chance here that Bob will mark Alice wrongly as verified.

From verified-group or setup-contact protocol point of view at this point we need a signed & encrypted message from alice. For joining a non-verified group alice may need to send the Chat-Group-Member-Added message plain text.

An attacker could replace alice's member-added message to Bob with a different cleartext Member-added message so that a) Bob thinks he joined an opportunistic group b) Alice thinks she added Bob to a verified group Note1, however, that the verified group members, which Alice produced the QR-invite code for, will send encrypted messages to Bob's actual key. The attacker can not gain access to those messages. Note2, that Bob might send cleartext messages to - what he believes to be - the opportunistic group. But those messages will not appear as proper content in the verified chat of the verified group Alice invited for. Note3, that the attacker can not send a modified encrypted member-added message because he would need to sign it with Alice's proper key which he doesn't have. Regarding Note3, however, i think we need to modify https://github.com/deltachat/deltachat-core-rust/blob/master/src/securejoin.rs#L614 to ensure if the message is encrypted that it is signed with alice's proper key. This Note3 attack should be addressed in the current code because otherwise Bob could send an encrypted message that the attacker can read -- but Bob will do this to an opportunistic group, i.e. his chat UX does not carry a "verified" sign. Opportunistic group are naturally vulnerable to active attacks so Bob has not been mislead but it's still better to fix it.

And finally I'm not sure if bob can know if they're joining a verified group or not (the line at https://github.com/deltachat/deltachat-core-rust/blob/8f8db0c43108e8a9386f89df23bee7ed45836a3f/src/securejoin.rs#L604 just always says it is not a verified group because that's its failure mode and the chat doesn't exist yet so it fails)

Let's indeed consider extending the QR-invite code to include information whether the group-to-be-joined is a verified group or not. See #1178.

flub · 2020-01-15T13:07:19Z

A very rough note: the claims to this being correct mean that the

deltachat-core-rust/src/securejoin.rs

Line 626 in 8f8db0c

if mark_peer_as_verified(context, &scanned_fingerprint_of_alice).is_err() {

line is sufficient to verify alice and even that this can be done in the vg-member-added step of bob. This also implies that all of

deltachat-core-rust/src/securejoin.rs

Lines 602 to 624 in 8f8db0c

    
           let vg_expect_encrypted = if join_vg { 
        
               let group_id = get_qr_attr!(context, text2).to_string(); 
        
               let (_, is_verified_group, _) = chat::get_chat_id_by_grpid(context, group_id); 
        
               // when joining a non-verified group 
        
               // the vg-member-added message may be unencrypted 
        
               // when not all group members have keys or prefer encryption. 
        
               // So only expect encryption if this is a verified group 
        
               is_verified_group 
        
           } else { 
        
               // setup contact is always encrypted 
        
               true 
        
           }; 
        
           if vg_expect_encrypted 
        
               && !encrypted_and_signed(mime_message, &scanned_fingerprint_of_alice) 
        
           { 
        
               could_not_establish_secure_connection( 
        
                   context, 
        
                   contact_chat_id, 
        
                   "Contact confirm message not encrypted.", 
        
               ); 
        
               context.bob.write().unwrap().status = 0; 
        
               return Ok(HandshakeMessage::Propagate); 
        
           }

could be removed.

flub · 2020-01-15T21:32:08Z

Regarding Note3, however, i think we need to modify
https://github.com/deltachat/deltachat-core-rust/blob/master/src/securejoin.rs#L614
to ensure if the message is encrypted that it is signed with alice's proper key.

I think the encrypted_and_signed() call you point to already does that? it ensures the message is signed with the key from the QR code

r10s · 2020-01-15T21:37:30Z

yip, i also think, the whole vg_expect_encrypted part can be removed. it can be easily bypassed anyway and seems not to add any security.

flub · 2020-01-22T17:47:39Z

I believe the discussion at nextleap-project/countermitm#83 points out that when we do not check whether vc-contact-confirm|vg-member-added is signed&encrypted Bob can only mark Alice as uni-directionally verified and not as bi-directionally verified. But uni-directionally verified is not a status we or countermitm currently use (and is likely only going to cause confusion to users)

flub · 2020-08-30T18:31:57Z

Just a quick note I'm looking at finally resolving this. I'm investigating introducing a non-user-visible UnidirectionalVerified status (or rather start using the existing one). I'll try and describe the effect of that on the 3 scenarios: 1. setup-contact 2. join-group and 3. secure-join

flub · 2020-09-01T17:05:08Z

So here's my proposal, I've thought through this by now and think this works.
Given this current definition of a contact:

#[derive(Debug, PartialEq, Eq, Clone, Copy, FromPrimitive)]
#[repr(u8)]
pub enum VerifiedStatus {
    /// Contact is not verified.
    Unverified = 0,
    // TODO: is this a thing?
    Verified = 1,
    /// SELF and contact have verified their fingerprints in both directions; in the UI typically checkmarks are shown.
    BidirectVerified = 2,
}

After step 4a Bob has Alice VerifiedStatus::Verified. This is uni-directional verified, Bob knows he has the right key for Alice. He does not know whether Alice has the right key for him. This state would never be exposed to the user I guess.
After step 6a Alice has Bob VerifiedStatus::BidirectVerified. She knows Bob has her key and she she has Bob's key.
If vg-member-added was sent signed+encrypted by Alice in step 6b, then Bob has Alice VerifiedStatus::BidirectVerified after step 6b. If this message was not signed+encrypted the status of Alice will remain the previous VerifiedStatus::Verified from the first bullet point here. The user visible behaviour change is now that when Alice invites Bob to a non-verified group, Bob may not always end up with Alice as verified (meaning BidirectVerified). Currently this is the case. However for Alice there is no change, Bob will still be shown as verified after this.

I think this upholds the security properties of the secure-join and setup-contact protocols while still allowing it to be used to join opportunistic groups as it does today. The behaviour change for users is minimal.

I'll follow up with PRs to implement this.

flub · 2020-09-03T06:59:38Z

Aspirational doc comment, making clear where verification happens and what the deviations from countermitm are:

//! Verified contact protocol implementation.
//!
//! This module implements the setup-contact and secure-join protocols [from the countermitm
//! project](https://countermitm.readthedocs.io/en/stable/new.html)
//!
//! The implementation here has 3 variations of the protocol:
//!
//! 1. **setup-contact**: This verifies two users bi-directionally protecting against active
//!       MITM atacks.
//!
//! 2. **secure-join**: This adds a new user to a verified group, as a side-effect the
//!       inviter and invitee will also verify each other according to *setup-contact*.
//!
//! 3. **invite**: This adds a user to an un-verified group.  While very similar to
//!       *secure-join* the inviter and invitee will not be fully verified contacts at the
//!       end.
//!
//! # setup-contact
//!
//! This is the [setup-contact
//! summary](https://countermitm.readthedocs.io/en/latest/new.html#setup-contact-protocol)
//! from the countermitm project.  See the description there for details of steps, a few
//! important variations and clarifications are noted here:
//!
//! - The shortcut when Bob knows Alice_FP is shown.
//! - The [VerifiedStatus] state changes are highlighted.
//! - The additional *vc-contact-confirm-received* message is shown.
//!
//! ```text
//!               +-------+                                      +-----+
//!               | Alice |                                      | Bob |
//!               +-------+                                      +-----+
//!                   |                                             |
//!                   |       1.a) bootstrap code (QR-code)         |
//!                   |-------------------------------------------->|
//!                   |                                             |
//!   1.b) track bootstrap per INVITENUMBER                         |
//!                   |                               2.a) check for existing key -->----+
//!                   |                                             |                    |
//!                   |    2.b) vc-request msg with INVITENUMBER    |                    |
//!                   |<--------------------------------------------|          if Alice is already
//!                   |                                             |          known with this FP
//!     3.a) look up bootstrap by INVITENUMBER                      |                    |
//!     3.b) abort if invite expired                                |                    |
//!     3.c) process AC header                                      |                     \
//!                   |                                             |                      \
//!                   |   3.d) vc-auth-equired msg with AC header   |                       \
//!                   |-------------------------------------------->|                        \
//!                   |                                             |                         |
//!                   |                  4.a) abort if key does not match FP from bootstrap   |
//!                   |                                             |                         |
//!                   |                                             |<------------------------+
//!                   |                                             |
//!                   |                           +-----------------------------------+
//!                   |                           | Alice is uni-directional verified |
//!                   |                           +-----------------------------------+
//!                   |                                             |
//!                   |  4.b) vc-request-with-auth msg              |
//!                   |       with Bob_FP and AUTH                  |
//!                   |<--------------------------------------------|
//!                   |                                             |
//!      5.a) verify AUTH and key                                   |
//!      5.b) on failure alert user and abort                       |
//!                   |                                             |
//!  +--------------------------------+                             |
//!  | Bob is bi-directional verified |                             |
//!  +--------------------------------+                             |
//!                   |                                             |
//!     6.a) signal success to user                                 |
//!                   |                                             |
//!                   |        6.b) vc-contact-confirm msg          |
//!                   |-------------------------------------------->|
//!                   |                                             |
//!                   |                           +----------------------------------+
//!                   |                           | Alice is bi-directional verified |
//!                   |                           +----------------------------------+
//!  6.c) clear bootstrap data for INVITENUMBER                     |
//!                   |                                7. signal success to user
//!                   |                                             |
//!                   |      vc-contact-confirm-received msg        |
//!                   |<--------------------------------------------|
//!                   |                                             |
//!               +-------+                                      +-----+
//!               | Alice |                                      | Bob |
//!               +-------+                                      +-----+
//! ```
//!
//! # secure-join
//!
//! This is the [secure-join
//! summary](https://countermitm.readthedocs.io/en/latest/new.html#joining-a-verified-group-secure-join)
//! from the countermitm project.  See the description there for details of steps.
//!
//! We reproduce the entire diagram again here for clarity, the protocol starts similar as
//! with setup-contact above however, with different names for the messages.
//!
//! Some differences:
//!
//! - The shortcut when Bob knows Alice_FP is shown.
//! - The [VerifiedStatus] state changes are highlighted.
//! - In step 6.b the *vg-member-added* message is used instead of the *vg-member-setup*
//!   message from the spec.
//! - Correspondingly the last message from Bob to Alice is *vg-member-added-received*.
//!
//! ```text
//!               +-------+                                      +-----+
//!               | Alice |                                      | Bob |
//!               +-------+                                      +-----+
//!                   |                                             |
//!                   |       1.a) bootstrap code (QR-code)         |
//!                   |-------------------------------------------->|
//!                   |                                             |
//!   1.b) track bootstrap per INVITENUMBER                         |
//!                   |                               2.a) check for existing key -->----+
//!                   |                                             |                    |
//!                   |    2.b) vg-request msg with INVITENUMBER    |                    |
//!                   |<--------------------------------------------|          if Alice is already
//!                   |                                             |          known with this FP
//!     3.a) look up bootstrap by INVITENUMBER                      |                    |
//!     3.b) abort if invite expired                                |                    |
//!     3.c) process AC header                                      |                     \
//!                   |                                             |                      \
//!                   |   3.d) vg-auth-equired msg with AC header   |                       \
//!                   |-------------------------------------------->|                        \
//!                   |                                             |                         |
//!                   |                  4.a) abort if key does not match FP from bootstrap   |
//!                   |                                             |                         |
//!                   |                                             |<------------------------+
//!                   |                                             |
//!                   |                           +-----------------------------------+
//!                   |                           | Alice is uni-directional verified |
//!                   |                           +-----------------------------------+
//!                   |                                             |
//!                   |  4.b) vg-request-with-auth msg              |
//!                   |       with Bob_FP and AUTH                  |
//!                   |<--------------------------------------------|
//!                   |                                             |
//!      5.a) verify AUTH and key                                   |
//!      5.b) on failure alert user and abort                       |
//!                   |                                             |
//!  +--------------------------------+                             |
//!  | Bob is bi-directional verified |                             |
//!  +--------------------------------+                             |
//!                   |                                             |
//!     6.a) signal success to user                                 |
//!                   |                                             |
//!                   |        6.b) vg-member-added msg             |
//!                   |-------------------------------------------->|
//!                   |                                             |
//!                   |                           +----------------------------------+
//!                   |                           | Alice is bi-directional verified |
//!                   |                           +----------------------------------+
//!  6.c) clear bootstrap data for INVITENUMBER                     |
//!                   |                                7. signal success to user
//!                   |                                             |
//!                   |       vg-member-added-received msg          |
//!                   |<--------------------------------------------|
//!                   |                                             |
//!  Notify user Bob securely joined group                          |
//!                   |                                             |
//!               +-------+                                      +-----+
//!               | Alice |                                      | Bob |
//!               +-------+                                      +-----+
//! ```
//!
//! # invite
//!
//! The invite flow is used by Alice to add Bob to a non-verified group using a QR code.  It
//! does the same as *secure-join* with **one major difference**: the *vg-member-added*
//! message is not necessarily signed and encrypted by Alice.
//!
//! If this message is not encrypted it means Bob will not set the
//! [VerifiedStatus::BidirectVerified] state for Alice and will instead have Alice in the
//! [VerifiedStatus::Verified] state at the end of the protocol.

hpk42 · 2020-10-10T17:18:47Z

Thanks for writing this aspirational doc comment, very useful, and helps thinking about it. For a long time i pondered that step 6ff are not needed for both sides to mark the other as verified. Due to the two-generals problem we can never have both sides end up in "bidirectionally verified" state and being sure that the other side also knows that. So i think we can simply have unverified/verified contacts and we have to live with the fact that it might be one-sided. IOW, the "bi-directionally verified" state is not needed. However, we will need to explore the error cases/issues arising from only one side marking the other as "verified" (also can happen with dropped messages/spam-sorted etc.). Not doing that here right now.

This is more about the claim that we can (aim to) already have step 5 result in both sides reaching "verified state" with each other. There might be a few refinements we need to do for Bob's "2 b) vg-request" message and Alice's "3 d) vg-auth-required" reply. We can send a challenge (if we don't already implicitly do) such that Alice's signed and encrypted message "vg-auth-required" arrives, Bob knows that:

Alice controls the e-mail address shown in the QR code,
Alice uses precisely the Alice_key that Bob saw in the QR code,
Alice knows Bob's proper key,
Alice has signed that she encrypted to Bob's proper key (not sure if the pgp signed/encrypted semantics already provide this)

The last point is important because Bob's vg-request message was unencrypted (he only knows A's fingerprint at this point) and a MITM could exchange Bob's key before handing the vg-request message to Alice. But Bob does know Alice's fingerprint, and as soon as Bob receives Alice's "vg-auth-required", and she has correctly signed off on using Bob's proper key, Bob can conclude that the email and privatekey is controlled by Alice's device as indicated on the QR code. Bob can mark Alice as "verified". This means that Bob can send messages to Alice that only she can decrypt, and that when Alice sends a message to Bob, that nobody except him can decrypt it. Thus Bob "having verified Alice" means that any message to/from Alice is MITM-safe and that Alice is in control of her e-mail pipeline.

Now in step 5, after Bob send an encrypted+signed vg-request-with-auth message to Alice, which entails the QR-contained "auth" token, Alice knows that Bob actually got the QR code (we assume that Alice and Bob have an unobservable second channel). Therefore, Alice marks Bob as verified. She knows that any message to/from Bob is MITM-safe, and that Bob is control of the associated e-mail pipeline.

There is now no need to send "contact-confirmed" anymore, and we don't need to mix it with "member-added".
If this holds, then the verification-protocol might get a bit simpler, and have one less network message for "setup-contact".

Happy to do a little A/V about this sometime.

flub · 2020-10-10T18:36:10Z

I almost entirely agree with all you're saying here. You're essentially spelling out what the uni-directional verified state means, which I think in short is: contact matches/controls their email and associated key. You then also argue that there's no need to get to the bi-directional verified state (at least for Bob, since Alice knows uni- and bi-directional state in the same step). And for a long time I thought so too, due to the two-generals problem. But our conversations around this topic when this issue was initially filed changed my mind.

When Alice has Bob bi-directionally verified she knows that both: 1) Bob matches his email and key, 2) Bob knows Alice by her email and key. When Bob has Alice bi-directionally verified he also knows this of Alice. The two-generals problem only results in Alice never knowing whether Bob ever made it to bi-directional verified, for all she knows he might be stuck on the uni-directional verified state.

I think it's better to keep the UI's idea of what verified means as bi-directional and not downgrade it to uni-directional. For one, Alice can never have Bob as uni-directional so it would make the protocol asymmetric. Secondly countermitm figured all this stuff out for us, and using it only costs us one extra message.

hpk42 · 2020-10-11T13:56:09Z

I almost entirely agree with all you're saying here. You're essentially spelling out what the uni-directional verified state means, which I think in short is: contact matches/controls their email and associated key.

I spelled out the definition of "verified" a bit more above (in an edit update) ....

When Alice has Bob bi-directionally verified she knows that both: 1) Bob matches his email and key, 2) Bob knows Alice by her email and key.

I think Alice already knows this without a confirmation message.

I think it's better to keep the UI's idea of what verified means as bi-directional and not downgrade it to uni-directional. For one, Alice can never have Bob as uni-directional so it would make the protocol asymmetric. Secondly countermitm figured all this stuff out for us, and using it only costs us one extra message.

My suggestion is to no use "uni/bi" at all and just use "verified/unverified" with "X marked as verified" meaning that I:

know that X is in control of the respective email/key and that sent/received messages can not be read or modified in-transit without detection
know that X knows my own key/email and that my device is in control of the pipeline and the respective secret key.

IOW, the "verification" flag is not one-sided, because we learn that the other side learned of us properly.

When Alice receives Bob's vg-request-with-auth mail, the can mark Bob as verified in the exact same sense: She knows that Bob is in control of his email/key and she knows that Bob knows her proper key.

flub · 2020-10-11T19:02:56Z

I think the uni-bi directional conversation has confused us a bit. I entirely agree with that the user should only know of a "verified" or not state. Currently the implementation calls this state bi-directional verified and I explicitly introduced an intermediate step as uni-directional in order to deal with Bob not reaching the verified state in join-group (i chose this name also only because there was already such a state defined in an enum). There is no reason at all to even keep this state in the implementation and we could get rid of the name entirely if that helps. The only part that mattered in my proposal is that when joining a non-verified group (vg-member-added was sent in clear text), Bob does not mark Alice as a verified contact.

For the other part, if I understand correctly you're questioning whether step 6b vc-contact-confirm is really needed to for Bob to mark Alice verified, suggesting he could mark Alice verified after step 4a (after vc-auth-required was sent). A way of looking at this is to ask what Bob knows after he received 6b vc-contact-confirm which he did not know after he received 3d vc-auth-required.

This list of yours, of what Bob knows after 3d vc-auth-required is pretty good. I'm re-writing it here a little, because I think it should be fully symmetric as afterwards it does not matter who started the process (and I collapsed your last two bullet points into one):

Peer controls their email they shared (shared in qr code or in 2b vc-request)
Peer controls their key they shared (shared in qr code or in 2b vc-request)
Peer confirmed they know you by your key and email.

This is what I think we would like the verified state to be. But I do not think point 3 is satisfied after 3d vc-auth-required. The problem is that Alice does not yet know whether Bob has been intercepted or not, so Alice does not yet know the first two points at this stage. And thus while Bob knows the first two, he does not know the third. Before Alice knows Bob really controls his email and his key, she needs to receive the AUTH key in a secure way from Bob (the 4b vc-request-with-auth step).

hpk42 · 2020-10-12T12:18:20Z

* Peer controls their email they shared (shared in qr code or in 2b vc-request)

* Peer controls their key they shared (shared in qr code or in 2b vc-request)

* Peer confirmed they know you by your key and email.
This is what I think we would like the verified state to be. But I do not think point 3 is satisfied after 3d vc-auth-required. The problem is that Alice does not yet know whether Bob has been intercepted or not, so Alice does not yet know the first two points at this stage. And thus while Bob knows the first two, he does not know the third. Before Alice knows Bob really controls his email and his key, she needs to receive the AUTH key in a secure way from Bob (the 4b vc-request-with-auth step).

If Alice's vg-auth-required message to Bob contains her signature on the info "Encrypted-To bob email/key" and Bob can verify the signature from the QR, then Bob can be sure of point 3 of your definition, i.e. he knows that Alice knows his proper keys and email. He thus does not need to wait for contact-confirm to mark Alice as verified. Note in order for what i said to become true we might have to modify Alice's vg-auth-required method to let her ascertain/sign where she encrypted/mailed to. See also https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-09.html#section-5.2.3.29 for an effort to do this at the pgp level.

flub · 2020-10-12T17:50:13Z

Oh, thanks for pointing out that currently autocrypt/pgp doesn't have the property of signing the intended recipient. I think I've known this is the past but was assuming that was already true - but it of course is not.

However I still don't think that if we had this, Bob would have Alice verified after her 3d vc-auth-required message. At this point Bob knows she has his key, but crucially Alice still doesn't know this. And the 3rd bullet point above says the peer has to confirm they know you by your key and email.

In other words if you aborted at after 3d vc-auth-required then Alice can still not store anything about what she learned from the handshake. However if you aborted after 4b vc-request-with-auth Bob can actually store some info about Alice, even though that's currently not done. Perhaps we should actually do this?

So using the uni- and bi-directional terminology again, I think uni-directional means you have point 1&2, but not point 3. And for 6a to be reached perhaps it should even be a requirement that Bob stores the uni-directional verified state ("you know this is Alice, she might not know you are Bob").

dumblob · 2022-11-10T09:22:30Z

@flub did your merged PR above solved all or most of the concerns you raised here? What are the remaining concerns? Thanks!

flub · 2022-12-08T13:52:10Z

@dumblob I don't think it resolves everything here yet. Not sure everything that remains, I didn't re-read this entire thread. One thing that remains is figuring out what single vs bi-directional verification means. There was some recent offline discussion where it seemed that distinguishing those two may make some sense. Basically bi-directional means you can introduce others into verified groups, where a uni-directional verification can't do that.

link2xt · 2023-11-29T03:47:36Z

I am refactoring securejoin in #5059. I remove {vc-contact-confirm,vg-member-added}-received steps which are not part of https://securejoin.readthedocs.io/

Then I am going to add a column to peerstates table with our own fingerprint that we think is verified by other contacts to track bidirectional verification. Only if it matches our own fingerprint we are bidirectionally verified.

Bob should mark Alice as one-way verified (copy public key to verified key) after verifying that public key matches invite fingerprint. This happens when Bob receives vc-auth-required or immediately after scanning the QR code if we already have a key.

Alice should mark Bob as bidirectionally verified when she receives vc-request-with-auth, i.e. copy Bob's public key into verified key if AUTH token matches and put current self-fingerprint into Bob's peerstate column for bidirectional verification fingerprints if Bob correctly encrypted for Alice's current key.

Bob should mark Alice as bidirectionally verified when vc-contact-confirm is received or when a message signed with current verified key and Chat-Verified: 1 is received. I am making Alice send Chat-Verified: 1 in verified 1:1 chats as well so we don't rely on vc-contact-confirm, but going to keep processing vc-contact-confirm for backwards compatibility.

iequidoo · 2023-11-30T05:27:52Z

Bob should mark Alice as bidirectionally verified when vc-contact-confirm is received or when a message signed with current verified key and Chat-Verified: 1 is received. I am making Alice send Chat-Verified: 1 in verified 1:1 chats as well so we don't rely on vc-contact-confirm, but going to keep processing vc-contact-confirm for backwards compatibility.

But when a message containing Chat-Verified: 1 would be received? vc-contact-confirm is sent immediately, so if we just drop it, Bob would have Alice bidirectionally verified only eventually and before that Bob can't rely on that Alice has verified them.

link2xt · 2023-11-30T11:25:28Z

But when a message containing Chat-Verified: 1 would be received? vc-contact-confirm is sent immediately, so if we just drop it, Bob would have Alice bidirectionally verified only eventually and before that Bob can't rely on that Alice has verified them.

If vc-contact-confirm is lost, Alice will have Bob bidirectionally verified and have a verified 1:1 chat with Bob. As soon as Alice sends a 1:1 message to Bob or any message in a verified group chat with Bob (e.g. by adding Bob to a group), Bob will mark Alice as bidirectionally verified too.

iequidoo · 2023-12-02T20:55:09Z

... but going to keep processing vc-contact-confirm for backwards compatibility.

If vc-contact-confirm is lost, Alice will have Bob bidirectionally verified and have a verified 1:1 chat with Bob. As soon as Alice sends a 1:1 message to Bob or any message in a verified group chat with Bob (e.g. by adding Bob to a group), Bob will mark Alice as bidirectionally verified too.

So, processing vc-contact-confirm is not only for backward compatibility and this message can't be removed from the protocol.

flub · 2024-01-10T07:18:56Z

Thanks for finally getting this done @link2xt !

flub added security bug labels Jan 15, 2020

flub self-assigned this Jan 15, 2020

hpk42 changed the title ~~Secure-Join protocol is wrongly implemented~~ Secure-Join protocol may have bugs / produce inconsistencies Jan 15, 2020

link2xt added bug Something is not working and removed bug2 labels Aug 7, 2020

flub mentioned this issue Jan 22, 2021

Refactor securejoin QR-code and bob state handling #2161

Merged

link2xt added discussion and removed bug Something is not working labels Apr 18, 2023

link2xt assigned link2xt and unassigned flub Nov 28, 2023

link2xt mentioned this issue Nov 29, 2023

Refactor securejoin #5059

Merged

link2xt mentioned this issue Nov 30, 2023

refactor(sql): recreate config and keypairs table #5064

Closed

link2xt mentioned this issue Dec 18, 2023

Bidirectional verification #5089

Merged

link2xt closed this as completed in #5089 Jan 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Secure-Join protocol may have bugs / produce inconsistencies #1177

Secure-Join protocol may have bugs / produce inconsistencies #1177

flub commented Jan 15, 2020

flub commented Jan 15, 2020

hpk42 commented Jan 15, 2020

flub commented Jan 15, 2020

hpk42 commented Jan 15, 2020 via email

flub commented Jan 15, 2020

flub commented Jan 15, 2020

r10s commented Jan 15, 2020

flub commented Jan 22, 2020

flub commented Aug 30, 2020

flub commented Sep 1, 2020

flub commented Sep 3, 2020

hpk42 commented Oct 10, 2020 •

edited

Loading

flub commented Oct 10, 2020

hpk42 commented Oct 11, 2020 •

edited

Loading

flub commented Oct 11, 2020

hpk42 commented Oct 12, 2020

flub commented Oct 12, 2020

dumblob commented Nov 10, 2022

flub commented Dec 8, 2022

link2xt commented Nov 29, 2023 •

edited

Loading

iequidoo commented Nov 30, 2023

link2xt commented Nov 30, 2023

iequidoo commented Dec 2, 2023 •

edited

Loading

flub commented Jan 10, 2024

Secure-Join protocol may have bugs / produce inconsistencies #1177

Secure-Join protocol may have bugs / produce inconsistencies #1177

Comments

flub commented Jan 15, 2020

flub commented Jan 15, 2020

hpk42 commented Jan 15, 2020

flub commented Jan 15, 2020

hpk42 commented Jan 15, 2020 via email

flub commented Jan 15, 2020

flub commented Jan 15, 2020

r10s commented Jan 15, 2020

flub commented Jan 22, 2020

flub commented Aug 30, 2020

flub commented Sep 1, 2020

flub commented Sep 3, 2020

hpk42 commented Oct 10, 2020 • edited Loading

flub commented Oct 10, 2020

hpk42 commented Oct 11, 2020 • edited Loading

flub commented Oct 11, 2020

hpk42 commented Oct 12, 2020

flub commented Oct 12, 2020

dumblob commented Nov 10, 2022

flub commented Dec 8, 2022

link2xt commented Nov 29, 2023 • edited Loading

iequidoo commented Nov 30, 2023

link2xt commented Nov 30, 2023

iequidoo commented Dec 2, 2023 • edited Loading

flub commented Jan 10, 2024

hpk42 commented Oct 10, 2020 •

edited

Loading

hpk42 commented Oct 11, 2020 •

edited

Loading

link2xt commented Nov 29, 2023 •

edited

Loading

iequidoo commented Dec 2, 2023 •

edited

Loading