https://bugs.kde.org/show_bug.cgi?id=515818
Bug ID: 515818
Summary: TOAKAFA trust policy blocks new keys with no way to
fix it from the UI
Classification: Applications
Product: kaidan
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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 = '[email protected]';
DELETE FROM omemoDevices WHERE userJid = '[email protected]';
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
--
You are receiving this mail because:
You are watching all bug changes.
