Bug 515818

I'm working on OMEMO 2 interop between my client (DinoX) and Kaidan. Sending from DinoX to Kaidan works fine, but Kaidan refuses to send back — it shows "Nachricht kann nicht versendet werden" (message cannot be sent).

After digging into this for a while I found the cause: Kaidan sets the security policy to TOAKAFA (Trust On Adding Key After First Authentication) in OmemoController.cpp. This means once an Authenticated key (trustLevel=32) exists for a contact, any new key is automatically marked AutomaticallyDistrusted (trustLevel=2). Since trust level 2 is not part of ACCEPTED_TRUST_LEVELS (8|16|32), encryptStanza() refuses to encrypt entirely.

The real issue is that there's no way to deal with this in Kaidan's UI. You can't view keys, you can't manually trust them, and you can't remove old ones.


How I ran into this:

A contact originally had a Montgomery identity key which Kaidan stored as Authenticated (32). After a key format correction (Ed25519 instead of Montgomery, as specified by XEP-0384 v0.8+), Kaidan automatically classified the new key as AutomaticallyDistrusted (2). From that point on, no messages could be sent.

The only way I could fix it was going directly into the SQLite database:

  DELETE FROM trustKeys WHERE ownerJid = 'contact@server.example';
  DELETE FROM omemoDevices WHERE userJid = 'contact@server.example';

Then restart Kaidan — the initial trust logic kicks in and the new key gets AutomaticallyTrusted (8). Obviously that's not something a regular user can do.


What would help (any of these):

1) Key management in the UI — show the OMEMO fingerprints for a contact, let users trust, revoke, or delete individual keys. Similar to what Conversations does.

2) Make the security policy configurable — let users choose between TOAKAFA and BTBV (Blind Trust Before Verification). BTBV is much more interop-friendly since new keys automatically get trustLevel 8 and are accepted.

3) A "Reset encryption" button per contact that clears all trust data and sessions and forces a fresh key exchange.


Environment:
- Kaidan: current Flatpak release
- Other side: DinoX with OMEMO 2 support (XEP-0384 v0.8+)
- OS: Linux
- This affects any OMEMO 2 client combination where keys can change (reinstallation, device change, key format correction, etc.)

Am I reading the TOAKAFA logic correctly here, or am I missing something? Happy to provide more details if needed.

-- Ralf / DinoX developer