chatmail
SecureJoin: encrypt `{vc,vg}-request` message
Currently if Bob scans a SecureJoin QR code and has no Alice's key corresponding to the encoded fingerprint, he sends Alice an unencrypted vc-request with INVITENUMBER to request the key from Alice. This is the only unencrypted message in SecureJoin protocol that requires special handling by chatmail filter that otherwise does not allow unencrypted messages (the other exception is MDNs, but with #5175 merged it can be removed).
A way to fix this would be to include the same keydata as we include in Autocrypt header in the QR code if it is small enough. Then if Bob does not currently have an Autocrypt key for Alice, he can use this keydata from the QR code. For backwards compatibility we should still keep the fingerprint.
I have tested with ed25519 keys, QR code can be generated with qrencode. It is more dense than our typical QR codes, so scanning may be more difficult and we may need to (re)move the avatar that we currently overlay on top of the QR code. qrencode-encoded image with added &keydata= in the end works with the current Delta Chat, keydata is properly ignored.
Including keydata in the QR code could simplify expiring QR codes (#5126) as only AUTH token will expire and INVITENUMBER is not used at all, so Bob can still scan the QR-code later and send the first message encrypted, while Alice does not need to worry about someone using old INVITENUMBER to request the key and monitor Alice's online presence.
As a first step I suggest adding a feature flag settable via config table to start including keydata if it is small enough. The limit should be large enough to include all keys generated by Delta Chat but not too large so QR code remains readable and not extremely dense or impossible to generate if huge keys are used. With this feature flag we can already make automated tests and start rolling out releases that can read this keydata and use it to skip vc-request.
As a second step we can enable this feature flag so clients actually start generating this QR codes. There is no need to wait for too long as feature is backwards-compatible, one release apart is enough.
Once enough clients support this, we can change chatmail to stop accepting any non-encrypted mails at all.
There might be security implications of accepting the Autocrypt key from a QR code claiming that it is a key for some email address without ever receiving a message with this email address. It seems relatively safe if we have no existing Autocrypt key for the contact, but otherwise I think we should not overwrite Autocrypt key currently in use. We should probably also postpone moving the key to verified slot until we receive any encrypted (+signed) message from Alice, if possible this key should not be saved anywhere at all and only used to send vc-request-with-auth. We are immediately encrypting AUTH token to this key as the next step, but if attacker controls the QR code then attacker also knows AUTH token encoded in this QR code.
Marking as discussion as it is a draft so nobody jumps into implementing this right now until there is more agreement on this.
When I tried QR codes containing the pub key half a year ago with @hpk42, I actually didn't manage to scan the QR code with my phone camera. To be fair, my phone camera was not that good, and I actually often had problems scanning QR codes (not only related to Delta Chat). Still, this is a problem to consider.
Apart from that, having the pub key in the QR code would save us quite some problems, to summarize:
- It would help with https://github.com/deltachat/deltachat-core-rust/issues/5126
- It would help with chatmail
- It would make securejoin go faster
All in all, while I was against this idea half a year ago, I'm +/-0 right now
Maybe there should be an UI fallback like "can't scan the QR code?" link below it which toggles the key out and explains the limitations.
On Sun, Jan 14, 2024 at 02:20 -0800, link2xt wrote:
I have tested with ed25519 keys, QR code can be generated with
qrencode. It is more dense than our typical QR codes, so scanning may be more difficult and we may need to (re)move the avatar that we currently overlay on top of the QR code.qrencode-encoded image with added&keydata=in the end works with the current Delta Chat, keydata is properly ignored.
I assume you encoded the full PGP key -- how about rather encoding the ~51 bytes of an actual ED25519 key like this:
-
Alice generates a separate nomral ED25519 PGP key for each invite and fishes the ED25519 encryption public keydata out via RPGP and presents it as an invite number
-
Bob will take this invitenumber/key data, call into RPGP to send a properly encrypted message to Alice (Step 4b in securejoin) containing the AUTH secret
-
Alice will in step 5 decrypt the regularly encrypted PGP-message from Bob, do all the checks and signal success to Bob who will then forward-verify the fingerprint of Alice's Autocrypt with the QR code.
This would land us at the theoretical optimum of only two network messages whereby Alice and Bob prove to each other their control of e-mail addresses, and the QR code (step 0 here) would only grow by ~68 characters.
However, I don't know how much effort this is (with rpgp APIs, core, db state etc.).
Chatmail is pretty fast so 2.5 roundtrips are not that bad usually
but then again the above scheme would work for any MTA
and also for all users including ones with Autocrypt RSA keys.
With a non-upgraded DC app Bob will use the invite number like today
and Alice would do the "3.d) vc-auth-required message with AC header"
like it does today.
This scheme would not allow to learn actual Autocrypt keys from Alice so bidirectional offline QR-code scans would not results in knowing their keys but it would provide the fingerprints so if any messages does arrive from either Alice or Bob their key can be marked as verified according to the offline scanned fingerprint.
Including the whole OpenPGP key will not work for v6/crypto-refresh, because we will eventually need to transmit two keys (v4 and v6) and larger PQC keys. Instead of trying to put OpenPGP key into the QR code we can instead share a passphrase and encrypt the first message with this passphrase, placing session key into SKESK (symmetric-key encrypted session key packet). Symmetric encryption is simpler and is not affected by potential PQ upgrades in the future. The only problem is then how Alice finds which passphase was used when she receives Bob's message: we may still have to include invite token into the plaintext header to allow for the QR code lookup.