OTR not interoperable with pidgin
persmule opened this issue · 6 comments
aTalk 2.2.4 seems not able to finish OTR handshaking with pidgin. When observed with XMPP console of pidgin, it seems that aTalk does not respond to any message containing "?OTR" sent by peer to perform OTR handshaking.
In XEP-0201: Best Practices for Message Threadsl; it is recommended that all chat messages should include message threads.
....
</body>
<thread>
2PG9X0
</thread>
</message>
However aTalk current implementation makes this a mandatory requirement. I have changed aTalk to accept chat message without a thread id. Will be included in the next release.
================ pidgin OTR message ================
2020-05-16 08:30:11.858 31957-32210/org.atalk.android D/SMACK: RECV (0):
<message xml:lang='en' to='swordfish@atalk.sytes.net/atalk' from='swan@atalk.sytes.net/pidgin' type='chat' id='purplea3866d4e'>
<active xmlns='http://jabber.org/protocol/chatstates'/>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
<p>
?OTRv23?
<span style='font-weight: bold;'>
swan@atalk.sytes.net/pidgin
</span> has requested an
<a href='https://otr.cypherpunks.ca/'>
Off-the-Record private conversation
</a>. However, you do not have a plugin to support that. See
<a href='https://otr.cypherpunks.ca/'>
https://otr.cypherpunks.ca/
</a> for more information.
</p>
</body>
</html>
<body>
?OTRv23?
swan@atalk.sytes.net/pidgin has requested an Off-the-Record private conversation <https://otr.cypherpunks.ca/>. However, you do not have a plugin to support that.
See https://otr.cypherpunks.ca/ for more information.
</body>
</message>
The thread problem seems to remain present on v2.2.5, released via F-Droid. It can even manifests as aTalk refuses to reply an unencrypted message sent by a pidgin peer (obviously without a thread id) , with an error notification "thread must not be null nor empty".
Sorry, the next aTalk release is actually referring to v2.2.6. v2.2.5 was already released when the problem was first reported.
Just release v2.3.0. Please verify.
The OTR implementation of aTalk v2.3.0 remains not interoperable with pidgin, as well as other clients using libotr. When inspecting via XMPP Console, it seems that the Reveal Signature Message ("?OTR:AAMR...") and Signature Message ("?OTR:AAMS...") generated by aTalk are considered invalid by libotr. Further more, they are obviously larger than corresponding OTR handshaking messages generated other implementations.
OTR messages can further be inspected with otr_parse tool provided with libotr. It shows that Reveal Signature Message and
Signature Message generated by aTalk contain a larger (886B) Encrypted Signature, while for for interoperable implementations this field is only 466B.
aTalk considers OTR handshaking is completed after it sends an (invalid) Reveal Signature Message with no Signature Message from peer received, which effectly breaks the standard of OTR.
aTalk will save the cryptographic context of OTR session even after the account is explicitly signed out and aTalk is quitted. Encrypted data messages can even be sent after the next login, with no OTR handshaking taking place, though they usually cannot be decrypted because most OTR implementation never save the cryptographic context when quitting, to prevent the context from being fetched by offline attackers, breaking the secrecy and deniability.
Please refer to the online info on aTalk OTR
[OTR Messaging](https://cmeng-git.github.io/faq.html#otr_01
I have just tested aTalk v2.3.0 with pidgin v2.13.0 (on ubutu). OTR is working as expected, without any problem.
Please note, aTalk OTR implementation only support OTR versions V1, V2 and V3. There is no future plan to enhance aTalk to support v4. With aTalk supporting OMEMO, user is encouraged to move to OMEMO. Actually aTalk is also considering to follow Conversations to remove OTR in future.