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).
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.
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.
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
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.
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:
[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”?
(for people who do not have a mobile data flatrate)