Thank you for the suggestion. We are definitely thinking about implementing it however I can't give you a specific timeline. We would also accept contributions (given Tigase software is opensource).

I've reviewed XEP and documentation for this feature and it looks like OMEMO, while being open specification uses libsignal-protocol-java GPLv3 compliant library, which would force us to:

• implement it from scratches (most likely forcing us to use OpenSSL and some kind of Curve25519 implementation)
• embed GPLv3 libsignal-protocol-c library and wrap it for use in Swift (or use a wrapper from https://github.com/ChatSecure/SignalProtocol-ObjC)

To be honest, I'm not sure if we should embed those libraries. And even if we would decide to do so, we should do this in a separate library or directly in the client (not in TigaseSwift).

Either way, there is one more thing to consider. At libsignal-protocol-c there is a following statement:

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code.

As for cryptography support, we were also considering support for PGP/GPG for message exchange. In this case we could use some library, ie. ObjectivePGP which could be easily used in Swift, but we would need to check if licensing is correct for us. If so, then I would still put this feature only in the Messenger and not in the library). Alternatively, we would need to implement it on our own and most likely use OpenSSL to deal with encryption.

Note: From what I've seen access to encryption algorithms is very limited on iOS and macOS and requires usage (embedding) of cryptography library like ie. OpenSSL and our software may be classified as:

Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms.

Artur, let me know what you think about this. Should we implement or not? which route should we choose?

Andrzej Wójcik wrote:

Artur, let me know what you think about this. Should we implement or not? which route should we choose?

It would be really cool to have, however, it is not a priority to us at the moment. What I mean by this, is this:

1. I would give green light to do it now if it takes no more than 3 days of work
2. I agree, that if we use any third-party libraries it should only go to the client code, not the library code
3. We should use as little third-part libraries as possible