New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMEMO encryption #117

Merged
merged 3 commits into from Jun 2, 2017

Conversation

Projects
None yet
4 participants
@vanitasvitae
Contributor

vanitasvitae commented Mar 16, 2017

I cleaned the code up, fixed all gradle checkstyle issues and targeted 4.2

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Mar 16, 2017

Contributor

This PR contains #116

Contributor

vanitasvitae commented Mar 16, 2017

This PR contains #116

@GitCop

This comment has been minimized.

Show comment
Hide comment
@GitCop

GitCop Mar 18, 2017

There were the following issues with your Pull Request

  • Commit: be2af1f
  • Your subject line is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

GitCop commented Mar 18, 2017

There were the following issues with your Pull Request

  • Commit: be2af1f
  • Your subject line is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

@alibitek

This comment has been minimized.

Show comment
Hide comment
@alibitek

alibitek Mar 30, 2017

@vanitasvitae What options are there for someone who would like to use the XEP-0384: OMEMO Encryption capabilities of Smack without the GPLv3 licensed dependency -- smack-omemo-signal?

In the docs Encrypting messages with OMEMO I read that:

It is also possible, to port smack-omemo to other libraries implementing the double ratchet algorithm.

Can you give any hints as to what needs to be implemented for such a port?
You would need to have an implementation similar to smack-omemo-signal or do you also need to change code inside smack-omemo?

The XMPP OMEMO spec says:

This XEP defines a protocol that leverages Olm [3] encryption to provide multi-end to multi-end encryption, allowing messages to be synchronized securely across multiple clients, even if some of them are offline. Olm is a cryptographic double ratched protocol based on work by Trevor Perrin and Moxie Marlinspike first published as the Axolotl protocol.

OMEMO currently uses version 1 Olm protocol. Instead of an Axolotl key server, Personal Eventing Protocol (XEP-0163) [6] (PEP) is used to publish key data.

Suggesting that an OMEMO implementation should use Olm (v1)?

Matrix provides end-to-end encryption via the Olm and MegaOlm cryptographic ratchets, which are implementations of the Double Ratchet cryptographic ratchet in C++: https://matrix.org/git/olm/tree/, licensed under Apache License 2.0

If there was a Java implementation for Olm and MegaOlm could this be used instead of libsignal-protocol-java ?
i.e. the crypto component of matrix-android-sdk

For more info about Olm see (starting from slide 23 onwards):

alibitek commented Mar 30, 2017

@vanitasvitae What options are there for someone who would like to use the XEP-0384: OMEMO Encryption capabilities of Smack without the GPLv3 licensed dependency -- smack-omemo-signal?

In the docs Encrypting messages with OMEMO I read that:

It is also possible, to port smack-omemo to other libraries implementing the double ratchet algorithm.

Can you give any hints as to what needs to be implemented for such a port?
You would need to have an implementation similar to smack-omemo-signal or do you also need to change code inside smack-omemo?

The XMPP OMEMO spec says:

This XEP defines a protocol that leverages Olm [3] encryption to provide multi-end to multi-end encryption, allowing messages to be synchronized securely across multiple clients, even if some of them are offline. Olm is a cryptographic double ratched protocol based on work by Trevor Perrin and Moxie Marlinspike first published as the Axolotl protocol.

OMEMO currently uses version 1 Olm protocol. Instead of an Axolotl key server, Personal Eventing Protocol (XEP-0163) [6] (PEP) is used to publish key data.

Suggesting that an OMEMO implementation should use Olm (v1)?

Matrix provides end-to-end encryption via the Olm and MegaOlm cryptographic ratchets, which are implementations of the Double Ratchet cryptographic ratchet in C++: https://matrix.org/git/olm/tree/, licensed under Apache License 2.0

If there was a Java implementation for Olm and MegaOlm could this be used instead of libsignal-protocol-java ?
i.e. the crypto component of matrix-android-sdk

For more info about Olm see (starting from slide 23 onwards):

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Mar 30, 2017

Contributor

@mnemonicflow First of all, a non-GPL client would have to use a library that provides the same ratcheting capabilities as libsignal. I think it also has to use the same elliptic curve parameters.

Since all other implementations of OMEMO are using libsignal at the moment, I guess it isn't trivial to create a non-signal module that is fully compatible.

Olm needs to be patched in order to be interoperable with libsignal I guess. I heard they're using some different crypto parameters and all in all another wire format, but I haven't looked into it.

The OMEMO XEP is in the process of moving away from Olm as ratchet basis. Instead the goal is to define the crypto library independent (ODR = OMEMO Double Ratchet), so that it will be possible for non-GPL clients to use another library that is compatible in the future. Take a look at xsf/xeps#460 for more information. This is the reason why I split smack-omemo and smack-omemo-signal in the first place.

If you take a look at smack-omemo-signal, you see that there is not much complicated code there, so it should be pretty straight forward to write smack-omemo-XYZ, provided library XYZ has a similar form to libsignal.

TL;DR
Olm must be more or less heavily patched for compatibility, but non-signal libraries should be possible (provided someone is willing to write them ;P). Writing smack-omemo-XYZ is the least complicated part of the work.

Edit: In an ideal world, smack-omemo can stay untouched :)

Contributor

vanitasvitae commented Mar 30, 2017

@mnemonicflow First of all, a non-GPL client would have to use a library that provides the same ratcheting capabilities as libsignal. I think it also has to use the same elliptic curve parameters.

Since all other implementations of OMEMO are using libsignal at the moment, I guess it isn't trivial to create a non-signal module that is fully compatible.

Olm needs to be patched in order to be interoperable with libsignal I guess. I heard they're using some different crypto parameters and all in all another wire format, but I haven't looked into it.

The OMEMO XEP is in the process of moving away from Olm as ratchet basis. Instead the goal is to define the crypto library independent (ODR = OMEMO Double Ratchet), so that it will be possible for non-GPL clients to use another library that is compatible in the future. Take a look at xsf/xeps#460 for more information. This is the reason why I split smack-omemo and smack-omemo-signal in the first place.

If you take a look at smack-omemo-signal, you see that there is not much complicated code there, so it should be pretty straight forward to write smack-omemo-XYZ, provided library XYZ has a similar form to libsignal.

TL;DR
Olm must be more or less heavily patched for compatibility, but non-signal libraries should be possible (provided someone is willing to write them ;P). Writing smack-omemo-XYZ is the least complicated part of the work.

Edit: In an ideal world, smack-omemo can stay untouched :)

@alibitek

This comment has been minimized.

Show comment
Hide comment
@alibitek

alibitek Apr 6, 2017

Does Smack support XEP-0334: Message Processing Hints ?

I couldn't find it here:

As the latest XEP-0384 OMEMO encryption specification says this:

As the asynchronous nature of OMEMO enables currently offline devices to decrypt received messages at a later time, clients MUST include a Message Processing Hints (XEP-0334) [9] hint in their OMEMO messages.
Otherwise, server implementations of Message Archive Management (XEP-0313) [6] will generally not retain OMEMO messages, since they do not contain a <body />

alibitek commented Apr 6, 2017

Does Smack support XEP-0334: Message Processing Hints ?

I couldn't find it here:

As the latest XEP-0384 OMEMO encryption specification says this:

As the asynchronous nature of OMEMO enables currently offline devices to decrypt received messages at a later time, clients MUST include a Message Processing Hints (XEP-0334) [9] hint in their OMEMO messages.
Otherwise, server implementations of Message Archive Management (XEP-0313) [6] will generally not retain OMEMO messages, since they do not contain a <body />

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Apr 6, 2017

Contributor

Isn't this a thing clients have to support?

Edit: Oh wait, I thought of the wrong thing.
smack-omemo adds a MAM storage hint to OMEMO messages.

Contributor

vanitasvitae commented Apr 6, 2017

Isn't this a thing clients have to support?

Edit: Oh wait, I thought of the wrong thing.
smack-omemo adds a MAM storage hint to OMEMO messages.

@GitCop

This comment has been minimized.

Show comment
Hide comment
@GitCop

GitCop Apr 19, 2017

There were the following issues with your Pull Request

  • Commit: c636e72
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

GitCop commented Apr 19, 2017

There were the following issues with your Pull Request

  • Commit: c636e72
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

@Flowdalic

This comment has been minimized.

Show comment
Hide comment
@Flowdalic

Flowdalic Apr 22, 2017

Member

I've pushed support for Hints and EME into the 4.2 branch. You may want to merge. :)

Member

Flowdalic commented Apr 22, 2017

I've pushed support for Hints and EME into the 4.2 branch. You may want to merge. :)

@Flowdalic

This comment has been minimized.

Show comment
Hide comment
@Flowdalic

Flowdalic May 27, 2017

Member

Just noticed: Could you s/elements/element/ in the package names?

Member

Flowdalic commented May 27, 2017

Just noticed: Could you s/elements/element/ in the package names?

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae May 28, 2017

Contributor

@Flowdalic Done :)

Contributor

vanitasvitae commented May 28, 2017

@Flowdalic Done :)

vanitasvitae added some commits Jun 2, 2017

Add OMEMO support (XEP-0384)
This fixes Smack-743. This commit adds the modules smack-omemo and smack-omemo-signal.
smack-omemo is licensed under the Apache license like the rest of the smack project.
smack-omemo-signal on the other hand is licensed under the GPLv3.
Due to the fact, that smack-omemo is not of much use without smack-omemo-signal,
the OMEMO feature can currently only be used by GPLv3 compatible software.
This may change in the future, when a more permissively licensed module becomes available.

@vanitasvitae vanitasvitae reopened this Jun 2, 2017

@GitCop

This comment has been minimized.

Show comment
Hide comment
@GitCop

GitCop Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

GitCop commented Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

@GitCop

This comment has been minimized.

Show comment
Hide comment
@GitCop

GitCop Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

GitCop commented Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

@GitCop

This comment has been minimized.

Show comment
Hide comment
@GitCop

GitCop Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

GitCop commented Jun 2, 2017

There were the following issues with your Pull Request

  • Commit: 687cada
  • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/igniterealtime/Smack/wiki/Guidelines-for-Smack-Developers-and-Contributors


This message was auto-generated by https://gitcop.com

@vanitasvitae vanitasvitae merged commit 3babca3 into igniterealtime:4.2 Jun 2, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
coverage/coveralls Coverage decreased (-0.007%) to 34.777%
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment