discussion at deltachat

[testbird]

Sorry, issues can't be moved between projects.

Please read deltachat/deltachat-core#168

[testbird]

Here is a part from another thread that I don't quite understand:

Beware "verfied" may rather mean "someone has captured your QR that can be freely copied and abused" not "key exchange has been one-to-one confirmed through another channel" => deltachat/deltachat-core#168

but this cannot happen without you will notice it.

How would two parties notice that their QRs got captured, or after they meet and think their devices verified each other's keys (because the wording makes them think so), they are actually switched to set up contacts to a mitm?

(A MITM sending "verification" requests to both parties, and promoting other MITMs to replace further contacts -> Verified Group protocolset-up-by-third-parties protocol)

[azul]

Hi @testbird ,

Sorry for taking so long to get back.
Just read the delta-core issue and another one linked from it.

I think it might be helpful to destinguish different things here. The idea of countermitm is to explore different approaches and explain which level of security can be reached that way.
Delta.chat (and other messangers) then need to pick a concrete option that meets their usability goals and security requirements. You pointed out briar in the delta issue and I think that's a good choice for at risk groups. From my understanding delta.chat focusses on ease of use rather than protection against targetted attacks. So they pick a different set of approaches.

For me the more interesting question wrt countermitm is your claims that we are promissing security the algorithms do not deliver.
We introduced expiry for the QR codes and made it clear they need to be transfered in a confidential way.

https://moderncrypto.org/mail-archive/messaging/2018/002544.html has a detailed workflow for a one side scan of the QR code plus a short verification code checked at the end. However this construction requires a Diffie Hellman key exchange for the verification messages. It's great for a tool like briar and I would be very happy to see it being used. However for the email context we do not have a widely agreed upon standart of performing such handshakes let alone libraries in the different environments to handle this well.

I'm not sure i understand why you would want to use a short authentication string in addition to a bidirectional transfer of QR codes including the key fingerprints. To me that seems redundant. But maybe you can elaborate.

Another longer term option that I look forward to investigate is including the entire key in the QR code. This becomes feasible with eliptic curve keys. But they cannot be used in all OpenPGP contexts yet. It would somewhat address your comments regarding rotating QR codes.

[azul]

My understanding also is that QR codes currently already change every time they are displayed because the INVITE and AUTH codes change.

[testbird]

The idea of countermitm is to explore different approaches and explain which level of security can be reached that way.

That's laudable. I think the problem only come from starting with using the same language (established wording of public key verification schemes) when actually doing something different, i.e. never ever comparing a key (verify). Instead of explaining the new method in different, more appropriate words (e.g. based on secrets and challenges) and to compare it to the established method afterwards.

I'm not sure i understand why you would want to use a short authentication string in addition to a bidirectional transfer of QR codes including the key fingerprints. To me that seems redundant. But maybe you can elaborate.

Hm, the idea for that optional advanced check was to validate whether the person belongs to the device by verbally requesting to unlock the device and include some string in the qr code.

Another longer term option that I look forward to investigate is including the entire key in the QR code.

Yeah, that should be the solution. The QR Version 33 code carrying 1700 characters may still be a little bulky for handheld devices, so rather with using secure enough shorter keys, higher capacity and possibly rectangular codes (e.g. the iQR code), QRStream (f-droid), or own code to split the key data into multiple QR codes: https://gist.github.com/joostrijneveld/59ab61faa21910c8434c.