Opened 4 years ago

Last modified 17 months ago

#16537 new plugin request

TextSecure libpurple support

Reported by: onny Owned by: EionRobb
Milestone: Component: plugins
Version: 2.10.11 Keywords:
Cc: calestyo, ben42, ampere, kevinoid, boris-petrov, swistak35


Hey, somone is working on a Go library for the WhisperSystem? TextSecure? secure mobile messaging protocol The original Android program can be found here

So someone with good C skills could now easily write a libpurple protocol, right?

I might give it a try but I'm not that good in such things ...

Best regards, Jonas

Change History (19)

comment:1 Changed 4 years ago by EionRobb

Probably worth having a link to the protocol docs for reference

comment:2 Changed 4 years ago by salinasv

  • Component changed from unclassified to plugins
  • Type changed from defect to plugin request

comment:3 Changed 4 years ago by calestyo

Anything new on this?

TextSecure? (the protocol, not the way the app uses it) seems to be superior over it would be great to have it in pidgin.

comment:4 Changed 4 years ago by mmcco

The protocol is known as Axolotl. There's a link to its specification above.

It's superior to OTR in the sense that it's a self-contained protocol rather than a protocol-agnostic layer. This makes things like file and media transfer easier. OTR is generally considered pretty bulletproof in terms of pure security, though. I think the difference between the two might be less than you think because TextSecure offers lots of nice features that no common OTR-supporting client does.

My main question is how much the Pidgin version would be able to interact with TextSecure proper. With the official client you need to register your phone number with SMS verification, right? Where would people be getting their accounts, and who could they chat with?

I agree that it would be interesting, but I don't think anyone's working on it. If there's an appropriately licensed and stable C library for Axolotl, it might be easy. If you have any ideas, please share.

comment:5 Changed 4 years ago by guillaume

There's a python library for Axolotl:

"Python port of libaxolotl-android, originally written by Moxie Marlinspik"

On On

Some clients using Axolotl:

Last edited 4 years ago by guillaume (previous) (diff)

comment:6 Changed 4 years ago by mmcco

IIUC, we wouldn't be able to use a Python implementation (or any non-C implementation) until GObjectification (#35) is complete. There's also a Golang implementation, which I'd be more apt to trust because static languages are generally far safer for crypto. My two cents.

comment:7 Changed 4 years ago by EionRobb

A C library of axolotl is available at but it uses (the currently GPL incompatible) OpenSSL

comment:8 Changed 4 years ago by mmcco

It would probably work with LibreSSL as well. That may not be GPL-compatible either due to 4-clause BSD licensed parts. However, maybe the fact that it's dependent on a multiply implemented API (OpenSSL's) rather than a specific library changes things.

Last edited 4 years ago by mmcco (previous) (diff)

comment:9 Changed 4 years ago by Alex71


comment:10 Changed 4 years ago by doctorlard

The README indicates that libaxolotl-c only requires OpenSSL for its unit tests, not when integrating libaxolotl.

comment:11 Changed 4 years ago by doctorlard

Venn Diagram moment: There also may be some overlap with implementing OMEMO in Pidgin, which uses Axolotl over XEP-0163 Personal Eventing Protocol. See ticket #16801.

comment:12 Changed 3 years ago by EionRobb

looks like libaxolotl-c has a ssl layer in it (struct axolotl_crypto_provider) to be able to specify ssl implementations, so that it doesn't have to rely on one crypto lib (libpurple has a similar thing with ssl backends)

Unfortunately, it requires implementations of hmac-sha256, sha512 and aes, of which libpurple only has ciphers for hmac-sha256

still, more good news about not needing openssl

comment:14 Changed 3 years ago by salinasv

Glib have hmac and checksums

It is true, this is only for glib 2.30 and 2.42... but.. you know, we can always bump or do a compatibility layer. ;-)

comment:15 follow-up: Changed 3 years ago by herbsmn

Would it be wise to merge this ticket with ?

comment:16 in reply to: ↑ 15 Changed 3 years ago by EionRobb

Replying to herbsmn:

Would it be wise to merge this ticket with ?

It would be unwise to merge. That ticket is about adding OMEMO support to XMPP whereas this ticket is about adding a new protocol.

They do coincidentally require the same libaxolotl backend though.

comment:17 Changed 3 years ago by kaptoxic


comment:18 Changed 2 years ago by ampere

I would make use of this if it existed. Are there any technical limitations or is the only lacking ingredient a person to do the coding?

comment:19 Changed 17 months ago by kip


Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!