Add Omemo Encryption Support #37

Closed
DreamFlasher opened this Issue Jan 20, 2017 · 15 comments

Comments

Projects
None yet
9 participants
@DreamFlasher

DreamFlasher commented Jan 20, 2017

Please add support for the new OMEMO XEP: http://xmpp.org/extensions/xep-0384.html

OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption: ​http://conversations.im/omemo/ It offers Forward Secrecy and deniability while allowing you to keep the benefits of message synchronization and offline delivery.

OMEMO uses the Double Ratchet algorithm to establish secure sessions between every combination of devices: ​https://en.wikipedia.org/wiki/OMEMO

It's current support status in other XMPP clients is tracked here: http://www.omemo.top

@Kev

This comment has been minimized.

Show comment
Hide comment
@Kev

Kev Jan 23, 2017

Member

Thanks for the suggestion. It's something we're considering for the future, but is not currently on the roadmap.

Member

Kev commented Jan 23, 2017

Thanks for the suggestion. It's something we're considering for the future, but is not currently on the roadmap.

@Kev Kev closed this Jan 23, 2017

@Kev

This comment has been minimized.

Show comment
Hide comment
@Kev

Kev Apr 3, 2017

Member

@remko's been having a bit of a look at this recently, and there's ongoing discussion on the mailing lists about the appropriate things for OMEMO to be doing to allow independent implementations, but yes - Swiften and Swift support would be required for this.

Member

Kev commented Apr 3, 2017

@remko's been having a bit of a look at this recently, and there's ongoing discussion on the mailing lists about the appropriate things for OMEMO to be doing to allow independent implementations, but yes - Swiften and Swift support would be required for this.

@remko

This comment has been minimized.

Show comment
Hide comment
@remko

remko Jun 12, 2017

Contributor

Nothing new on the Swift side of things.

Maybe some background: OMEMO has not been standardized yet, and isn't quite there yet either. The non-standardized version currently used by other clients cannot be implemented in Swift due to licensing issues. There have been many discussions in the past months on how to get to a version that is broadly implementable, but no agreements have been reached yet. I hope this will change soon. Once things are unblocked there, the protocol still needs to be further discussed and defined (e.g. I think there are still some things missing to improve usability).

Hopefully, by the time the standard is ready for implementation (which nobody knows how long it will take), I will have a Swift implementation ready as well (although I can't promise anything at this point).

Contributor

remko commented Jun 12, 2017

Nothing new on the Swift side of things.

Maybe some background: OMEMO has not been standardized yet, and isn't quite there yet either. The non-standardized version currently used by other clients cannot be implemented in Swift due to licensing issues. There have been many discussions in the past months on how to get to a version that is broadly implementable, but no agreements have been reached yet. I hope this will change soon. Once things are unblocked there, the protocol still needs to be further discussed and defined (e.g. I think there are still some things missing to improve usability).

Hopefully, by the time the standard is ready for implementation (which nobody knows how long it will take), I will have a Swift implementation ready as well (although I can't promise anything at this point).

@sergeevabc

This comment has been minimized.

Show comment
Hide comment
@sergeevabc

sergeevabc Jun 12, 2017

Are we OMEMO yet?” website gives an overview of the status of implementation across XMPP clients.

sergeevabc commented Jun 12, 2017

Are we OMEMO yet?” website gives an overview of the status of implementation across XMPP clients.

@tdemin

This comment has been minimized.

Show comment
Hide comment
@tdemin

tdemin Nov 14, 2017

@remko hasn't it? It has got its XEP number (XEP-0384) in December 2016.

tdemin commented Nov 14, 2017

@remko hasn't it? It has got its XEP number (XEP-0384) in December 2016.

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Nov 14, 2017

@remko Yeah, OMEMO is standardized a long time again (see previous comment), the license issues also have been resolved back then, and the protocol is also stable and defined :) The standard is ready for implementation, and a lot of clients have implemented it. www.omemo.top

@remko Yeah, OMEMO is standardized a long time again (see previous comment), the license issues also have been resolved back then, and the protocol is also stable and defined :) The standard is ready for implementation, and a lot of clients have implemented it. www.omemo.top

@netro

This comment has been minimized.

Show comment
Hide comment
@netro

netro Jan 6, 2018

Hello,
I'm new to Swift; Is there any news from last year ? ^^
Is it on the roadmap now ?
Where can we find the roadmap ?

netro commented Jan 6, 2018

Hello,
I'm new to Swift; Is there any news from last year ? ^^
Is it on the roadmap now ?
Where can we find the roadmap ?

@remko

This comment has been minimized.

Show comment
Hide comment
@remko

remko Jan 6, 2018

Contributor

No news. Nothing has happened on the protocol to address the concerns mentioned before, so nothing has happened on the Swift side either.

Contributor

remko commented Jan 6, 2018

No news. Nothing has happened on the protocol to address the concerns mentioned before, so nothing has happened on the Swift side either.

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jan 6, 2018

That's quite incorrect. As previous comments pointed out everything is good on the Omemo side.

That's quite incorrect. As previous comments pointed out everything is good on the Omemo side.

@Kev

This comment has been minimized.

Show comment
Hide comment
@Kev

Kev Jan 6, 2018

Member

Hi, a bit of an update to the ticket on the standardisation side:
Until recently, the thing that was implemented by clients wasn't what was specified as OMEMO by the XSF, but was something else that also called itself OMEMO - obviously confusing. The XSF decided, as a compromise, to take a two-stage approach OMEMO. Stage 1 was to publish what the current clients implement, so they're able to refer to a particular version of the spec, without resolving the current licensing etc. issues, and stage 2 is to then do the necessary work to update the spec to resolve the current issues (which include, but aren't limited to, licensing). As things stand we're at stage 1, and there's currently no-one who's stepped forward to do the necessary stage 2 work.

So, as Remko says, we're not currently where we need to be for Swift to be implementing it.

Member

Kev commented Jan 6, 2018

Hi, a bit of an update to the ticket on the standardisation side:
Until recently, the thing that was implemented by clients wasn't what was specified as OMEMO by the XSF, but was something else that also called itself OMEMO - obviously confusing. The XSF decided, as a compromise, to take a two-stage approach OMEMO. Stage 1 was to publish what the current clients implement, so they're able to refer to a particular version of the spec, without resolving the current licensing etc. issues, and stage 2 is to then do the necessary work to update the spec to resolve the current issues (which include, but aren't limited to, licensing). As things stand we're at stage 1, and there's currently no-one who's stepped forward to do the necessary stage 2 work.

So, as Remko says, we're not currently where we need to be for Swift to be implementing it.

@Echolon

This comment has been minimized.

Show comment
Hide comment
@Echolon

Echolon Feb 27, 2018

@Kev but as I understand, you are generally willing to implement, once there is a sufficient standardisation, correct?

Cheers

Echolon commented Feb 27, 2018

@Kev but as I understand, you are generally willing to implement, once there is a sufficient standardisation, correct?

Cheers

@Kev

This comment has been minimized.

Show comment
Hide comment
@Kev

Kev Feb 28, 2018

Member

It's not currently a priority for us spending time on, but (once the issues are resolved), we'd be likely to accept a well-crafted patch that added it if someone wanted to make one (in some way that didn't break anything else).

Member

Kev commented Feb 28, 2018

It's not currently a priority for us spending time on, but (once the issues are resolved), we'd be likely to accept a well-crafted patch that added it if someone wanted to make one (in some way that didn't break anything else).

@sergeevabc

This comment has been minimized.

Show comment
Hide comment
@sergeevabc

sergeevabc Feb 28, 2018

In the age of surveillance, when privacy is trampled daily, when EFF’s founder demise truly saddens and Signal’s ascent is encouraging, at this very time @Kev — without batting an eye — admits Swift’s priority is anything, but not keeping pace with how communication medium should be secured. Then delegates this crucial and sensitive task to the periphery at the mercy of random people. What a staggering vision!

sergeevabc commented Feb 28, 2018

In the age of surveillance, when privacy is trampled daily, when EFF’s founder demise truly saddens and Signal’s ascent is encouraging, at this very time @Kev — without batting an eye — admits Swift’s priority is anything, but not keeping pace with how communication medium should be secured. Then delegates this crucial and sensitive task to the periphery at the mercy of random people. What a staggering vision!

@dwd

This comment has been minimized.

Show comment
Hide comment
@dwd

dwd Feb 28, 2018

At this time, I'd highly recommend awaiting MLS. Probably won't be a long wait, and it feels very promising to have an Open Standard in this area we can build on instead of using whatever happens to be flavour of the month.

dwd commented Feb 28, 2018

At this time, I'd highly recommend awaiting MLS. Probably won't be a long wait, and it feels very promising to have an Open Standard in this area we can build on instead of using whatever happens to be flavour of the month.

@morgothdidnothingwrong

This comment has been minimized.

Show comment
Hide comment
@morgothdidnothingwrong

morgothdidnothingwrong Jul 14, 2018

Hello,

As you can see in my history, I don't know how to code and I'm not a good contributor. I'm doing my best to improve it anyway !

But @Kev, prior to someone building an OMEMO plugin “without breaking anything else”, they should read your code structure without any specific documentation (AFAIK) and I doubt it will ever happen. Libreoffice has like less than 40 contributors, and although adding OMEMO to Swift would be a cool project, and make one's resume shine a little, I doubt someone will implement the OMEMO protocol – at least for free.

AFAIK, it doesn't only implement encrypted group chat but also encrypted file sharing and offline encryption (against OTR), and I specifically looked for Swift on https://omemo.top because I'd be downloading it now if you had implemented OMEMO. Although I understand that a lot of chat clients already implement this, and that your project may be somewhat different, but I'd like to be part of it without giving up either my contacts or everyone's E2E encryption in the group chat… (It's also worth noting that there's probably someone in the group who specifically uses XMPP for its encryption ! Should they give up the reasons why they're here for 70% of their communications, or just leave the group chat ?)

So if I had the honour of leading such an XMPP client I'd add a bounty on https://bountysource.com, this being said without, I hope, condescension or anything. I just think implementing OMEMO is important, not only for the encryption itself, but for everyone using other clients.

Best regards !

morgothdidnothingwrong commented Jul 14, 2018

Hello,

As you can see in my history, I don't know how to code and I'm not a good contributor. I'm doing my best to improve it anyway !

But @Kev, prior to someone building an OMEMO plugin “without breaking anything else”, they should read your code structure without any specific documentation (AFAIK) and I doubt it will ever happen. Libreoffice has like less than 40 contributors, and although adding OMEMO to Swift would be a cool project, and make one's resume shine a little, I doubt someone will implement the OMEMO protocol – at least for free.

AFAIK, it doesn't only implement encrypted group chat but also encrypted file sharing and offline encryption (against OTR), and I specifically looked for Swift on https://omemo.top because I'd be downloading it now if you had implemented OMEMO. Although I understand that a lot of chat clients already implement this, and that your project may be somewhat different, but I'd like to be part of it without giving up either my contacts or everyone's E2E encryption in the group chat… (It's also worth noting that there's probably someone in the group who specifically uses XMPP for its encryption ! Should they give up the reasons why they're here for 70% of their communications, or just leave the group chat ?)

So if I had the honour of leading such an XMPP client I'd add a bounty on https://bountysource.com, this being said without, I hope, condescension or anything. I just think implementing OMEMO is important, not only for the encryption itself, but for everyone using other clients.

Best regards !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment