Additionally keep static qr codes for offline out-of-band verification?

[Hocuri]

The advantages:

• works offline (for people who do not have a mobile data flatrate)
• The QR codes could even be printed on visiting cards or similar

The disadvantages:

• Actually only one direction is verified (if Alice scans Bob’s code, A can be sure that she chats with B. - But Eve could scan B’s code and do as if she was A without B noticing). So, B can’t be able to add A to a verified group.
• B could ask A whether the verification worked and then be sure that he chats with A but DC won’t know

My opinion is that nevertheless, this should be added as an additional feature (like, if a scanned QR code is “too old” or there is no internet connection, show a warning to the user and do a one-direction offline out-of-band verification).

Update: Related to Release the basic QR-Code "contact scanning" feature independently

Any opinions?

[Hocuri]

Continuing https://github.com/deltachat/deltachat-android/issues/756 here.

[adbenitez]

what about doing the offline verification in-time but using a direct connection via Bluetooth or wifi???

[adbenitez]

I don’t know how this qr verification process work but I am not sure why this need to use Internet/email-server to do a physical qr scan verification

[Hocuri]

@adbenitez

what about doing the offline verification in-time but using a direct connection via Bluetooth or wifi???

Generally a good idea, if this can be implemented user-friendly… From my experience something like this tends to be buggy but in general, good idea.

@adbenitez

I don’t know how this qr verification process work but I am not sure why this need to use Internet/email-server to do a physical qr scan verification

r10s:

the verification is not only about transferring a key but also about receiving the key of the other side and about knowing that the other side knows that you have the key. this requires a network connection.
even if we could delay this in a way, there would be no clear verification result after scanning and it would be confusing ux-wise when and if you can add the contact eg. to a verified group.

[adbenitez]

@Hocuri

this requires a network connection

I agree with this, what I say is that it would be even better if that network connection is a private direct connection between the two devices, or there are a real need for this to be transported using the email?

[Hocuri]

I just cited r10s to answer your other question, and he probably didn’t think of this.

And stil…

@Hocuri

Generally a good idea, if this can be implemented user-friendly… From my experience something like this tends to be buggy but in general, good idea.

[adbenitez]

@adbenitez

I agree with this, what I say is that it would be even better if that network connection is a private direct connection between the two devices, or there are a real need for this to be transported using the email?

answering to myself, probably it is easier to just use the email, in the end you want to use the email to send the message to the other peer, and it is easier to just use the email, than implementing a way to connect offline

[testbird]

@adbenitez

probably it is easier to just use the email, in the end you want to use the email to send the message to the other peer, and it is easier to just use the email, than implementing a way to connect offline

I really don’t think the QR+hidden-system-emails mechanism has been easier to implement. The introduction of hidden system messages even introduces additional security risks. And that mechanism has for sure nothing to do with the widely recognized out-of-band key verification, and calling it key verification is misleading.

Deltachat’s current QR-contact-setup protocol is highly controversial. It’s rather a chained remote key installing mechanism. (QR verfication · Issue #168 · deltachat/deltachat-core · GitHub)

But implementing a real two-way out-of-band (offline) verification should actually not be hard, given that all the necessary parts for the one-way out-of-band transmission are already there. See this thread:

Release the basic QR-Code "contact scanning" feature independently

@r10s, who wanted to have this discussed here: Two things to improve for releasing a basic version of the current QR-Code “contact scanning” feature from the current “lab code”: Show the own QR-Code during QR scanning. Keep the scanner running after a successful scan, to allow further scans (by the other side to let both sides add the OOB contact data, or scan further contacts in a group meetings). Advantages: solves usability issues with current code have a basic, classic “two-way” contac…

[Hocuri]

@testbird

See this thread: […]

This has the disadvantage that it’s not as easy for users to use. (esp, you have to explain it to them while “Scan this QR code” is quite obvious)

@testbird

calling it key verification is misleading.

Why? The keys are verified, I do not know how s.o. could do a MitM attack

[testbird]

[The two-way scanning] has the disadvantage that it’s not as easy for users to use. (esp, you have to explain it to them while “Scan this QR code” is quite obvious)

I’d consider it just as easy, with actually less required coordination, and no risk of conflicting modes.

It works on the intuitive “you scan my, and I scan your credentials” basis (after opening the unified “QR scanning and displaying activity”. It’s intuitive for both (or all persons present) to get credentials that are transmitted through a separate channel. (No problems with missing network connections either.)

The keys are verified, I do not know how s.o. could do a MitM attack

Are you sure about the word “verified”? I am not saying that a new chain-of-trust-remote-key-installing mechanism may not provide any degree of trustability. But the actual keys or fingerprints are never compared as one would expect from something talking about “verified contacts”.

Even for those people presenting the new scheme as a solution, it should be better to call it differently, to be clear about it, and better claim the full fame. Something along the lines of trust-chain or chained-channel-trust, maybe.

Anyway, IMHO there is an even greater bummer in the further idea that the scheme delegates (trusts) any QR scanned contact to remotely install and change keys for further (third-party) contacts (very convenient for setting up a MitM). How believable is it to call contacts whose keys can be exchanged by other contacts “verified”?