Smack v4.2 Introduces OMEMO Support!

This blogpost doubles as a GSoC update, as well as a version release blog post.

OMEMO Clownfish logo.

OMEMO Clownfish logo (conversations.im)

I have the honour to announce the upcoming release of Smack! Version 4.2.1 brings among bug fixes and additional features like Explicit Message Encryption (XEP-0380) and Message Processing Hints (XEP-0334) support for OMEMO Multi-End-Message-and-Object encryption (XEP-0384). The OMEMO protocol was developed by Andreas Straub for the Conversations messenger (also as a Google Summer of Code project) in 2015. Since then it got quite popular and drew a lot of attention for XMPP in the media. My hope is that my efforts to develop an easy to use Smack module will result in an even broader adoption.

The new Smack release is available from the Maven snapshot repository.

OMEMO is a protocol for multi-end to multi-end encrypted communication, which utilizes the so called Double Ratchet algorithm. It fulfills amongst the basic requirements of encrypted communication (confidentiality, authenticity and integrity) also the properties of deniability and forward secrecy as well as future secrecy. Smacks implementation brings support for encrypted single and group chats including identity management and session renegotiation.

Current implementations (as well as this one) are based upon the libsignal library developed by OpenWhisperSystems for their popular Signal (formerly TextSecure) messenger. Smack’s OMEMO support is structured in two modules. There is smack-omemo (APL licensed), which contains the logic specified in the XEP, as well as some basic cryptographic code. The other module smack-omemo-signal (GPLv3 licensed) implements some abstract methods defined by smack-omemo and encapsulates all function calls to libsignal.

Currently smack-omemo-signal is the only module available that implements the double ratchet functionality, but there has been a lot of discussion on the XMPP Standards Foundations mailing list regarding the use of alternative (more permissively licensed) libraries for OMEMO (like for example Olm, a double ratchet implementation from our friends over at the [matrix] project). So once there is a new specification that enables the use of other libraries, it should be pretty easy to write another module for smack-omemo enabling OMEMO support for clients that are not GPLv3 compatible as well.

Smack’s OMEMO modules are my first bigger contribution to a free software project and started as part of my bachelors thesis. I’m quite happy with the outcome

Smack Logo

Also Smack has a new Logo!

That was a lot of talking about OMEMO. Now comes the second functioning of this blog post, my GSoC update.

My project of implementing Jingle File Transfer (XEP-0234) for Smack is going relatively well. I’m stuck at some points where there are ambiguities in the XEP or things I don’t know yet, but most of the time I find another construction site where I can continue my work. Currently I’m implementing stanza providers and elements needed for file transfer. Along the way I steadily create Junit tests to keep the code coverage at a high level. Already it pays off when there are fiddly changes in the element structure. I already got file transfer over Jingle IBB working.

It’s a real pleasure to learn all the tools I never used before like code coverage reports or mocking and I think Flow does a good job introducing me to them one by one.

That’s all for now. Happy hacking

5 Likes

That’s awesome! Any chance you’re looking to put together an article that includes code samples showing encrypted communication between two clients?

1 Like

Funny that you ask

Here you go: Tutorial: Home-made OMEMO client « vanitasvitae’s blog

Does that mean openfire supports Omemo now?

Openfire is a server, while OMEMO is a client thing. I believe Openfire supports PEP, so it should support OMEMO .

1 Like

Thanks for fast reply Paul ) I know about client thing

Some people were complaining here : OMEMO encryption with Openfire?

i.e i believe PEP must add some features to support OMEMO )

By the look of things there is still something broken in OpenFire. Will look into it.

Thanks Paul. From the other side it looks like some guys are already using it. Hard to say.

For now i am on the line of analyzing whether OMEMO would work with openfire(latest versions) smoothly.

Could not find mentions of it on releases of openfire.

Bringing up a very old thread…

there has been a lot of discussion on the XMPP Standards Foundations mailing list regarding the use of alternative (more permissively licensed) libraries for OMEMO (like for example Olm, a double ratchet implementation from our friends over at the [matrix] project). So once there is a new specification that enables the use of other libraries, it should be pretty easy to write another module for smack-omemo enabling OMEMO support for clients that are not GPLv3 compatible as well.

Did this ever happen? What are non GPL options?

There is no (public) implementation available that I’m aware of.
However, the specification XEP-0384 was recently updated (version 0.4+), to make it easier to create non-GPL implementations. Smack-omemo has not been updated to that version yet however.

1 Like

Thank you. I hope Smack gets non-GPL Encryption. It is such a wonderful library!

1 Like