Delta Chat uses OpenPGP for encryption, which does not support forward secrecy.
Apart from backwards compatibility, the greatest obstacle to adding forward secrecy is multidevice support. Double Ratchet protocols (Signal protocol, XMPP OMEMO, Olm, Megolm) do not advance the ratchet on devices which are not participating in the chat, which could be a problem if one of the devices is offline for a long time. Since different devices use different keys, the protocol also depends on the server publishing cross-signatures for offline device keys (for example, via https://xmpp.org/extensions/xep-0060.html in case of OMEMO), which most email servers can’t do without extensions such as Web Key Service.
Another way to implement forward secrecy is to use Off-the-Record Messaging protocol. Unlike OpenPGP and Double Ratchet, it does not support multi-device, but it is designed to be used over existing chat protocols, such as XMPP and IRC. On the protocol level an OTR conversation can be created within existing OpenPGP chat between any two devices.
OTR chat is a separate chat type. User creates an invitation to OTR chat on one of the devices and sends it in 1:1 chat. Once it is accepted on the other side, a separate chat is created which is only available on two participating devices. OTR key could be additionally verified, but it is not strictly necessary as long as OpenPGP key was not compromised and no active attack was taking place at the time when OTR conversation started.
User experience of such chats would be similar to Telegram Secret Chats, which is already familiar to some users.
Wikipedia references https://lists.cypherpunks.ca/pipermail/otr-announce/2012-September/000058.html which talks about Pidgin plugin support for having multiple OTR chats with the same contact. It is not a protocol change to support multidevice or something like that. In DC each OTR chat could be shown as a separate item if you need to talk to multiple devices of the same contact.
Right, because of the forward secrecy, actually. I think it would be nice to have OTR as an option in delta.chat. Just a button [OTR], coupled with optional safe erasure… would be lovely.
I think it should be a menu item in 1:1 chat, saying “Start OTR chat”. It should create “pending” OTR chat which can’t be used until it is accepted by the other side.
OTR also has the ability to “close” session, which discloses signature keys, so both sides can forge additional messages in the conversations after that. It protects against disclosing of the signed messages to a third party. After closing the chat you can’t write additional messages in it and should open a new one.
Implementing it in DC requires a Rust implementation of OTR or bindings to existing library, compatible to core MPLv2 license (Rust “default” MIT/Apache2 or libotr LGPLv2+ will do). I have found none on crates.io.
The last time I used OTR, it worked only when both sides were online. This is an annoying requirement by itself and I think the experience won’t be better with a client like Delta Chat that has no online status indicator.
Just wanted to point out this potential flaw. Maybe it’s still good and important enough for at-risk users that it’s worth implementing.
That’s true, for OTRv3 users need to exchange messages to start a chat. That is why I talk about “pending” OTR chats above. The chat has to be accepted by the other side before you can send messages into it.
But there is no need for presence status (“online status indicator”) for OTR to work. It even works over IRC. You can try to open an OTR chat and keep using normal chat until your contact is online and accepts OTR chat. The only interactive part is the key exchange, after which devices can send messages while the other device is offline.
