Add Omemo Encryption Support #153

Open
DreamFlasher opened this Issue Jan 20, 2017 · 14 comments

Comments

Projects
None yet
10 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

@Flowdalic

This comment has been minimized.

Show comment
Hide comment
@Flowdalic

Flowdalic Jan 20, 2017

OMEMO is no longer a ProtoXEP. It became XEP-0384.

OMEMO is no longer a ProtoXEP. It became XEP-0384.

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jan 20, 2017

Thank you, great point, I'll update the initial request accordingly.

Thank you, great point, I'll update the initial request accordingly.

@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Jan 21, 2017

Owner

thanks for this issue. this is a duplicate of #101. unfortunately I don't have time atm to implement omemo, if you happen to have time, please send a PR along.

Owner

hannesm commented Jan 21, 2017

thanks for this issue. this is a duplicate of #101. unfortunately I don't have time atm to implement omemo, if you happen to have time, please send a PR along.

@hannesm hannesm referenced this issue Jan 21, 2017

Closed

omemo support #101

@Kagami Kagami referenced this issue in bascht/omemo-top Feb 2, 2017

Merged

Ticket closed note #19

@jfrederickson

This comment has been minimized.

Show comment
Hide comment
@jfrederickson

jfrederickson Feb 7, 2017

I'd like to note that OMEMO is useful for more than just offline delivery. I saw in one of your recent blog posts...

There is (AFAIK) no encrypted group messaging via XMPP

However, Conversations supports OMEMO in MUCs under certain circumstances, so there is an option.

I'd like to note that OMEMO is useful for more than just offline delivery. I saw in one of your recent blog posts...

There is (AFAIK) no encrypted group messaging via XMPP

However, Conversations supports OMEMO in MUCs under certain circumstances, so there is an option.

@infinity0

This comment has been minimized.

Show comment
Hide comment
@infinity0

infinity0 Feb 8, 2017

Contributor

A prerequisite to doing this would be to implement XEP-0163 which is used to distribute pre-keys in OMEMO. This would be useful for an end-to-end encrypted messaging protocol that I'm doing as well - which is architecturally very different from OMEMO, but could use XMPP/Matrix as "dumb transports".

Implementing XEP-0163 is probably best done either in ermine/xmpp or as a separate opam package, and not in jackline itself.

Contributor

infinity0 commented Feb 8, 2017

A prerequisite to doing this would be to implement XEP-0163 which is used to distribute pre-keys in OMEMO. This would be useful for an end-to-end encrypted messaging protocol that I'm doing as well - which is architecturally very different from OMEMO, but could use XMPP/Matrix as "dumb transports".

Implementing XEP-0163 is probably best done either in ermine/xmpp or as a separate opam package, and not in jackline itself.

@sternenseemann

This comment has been minimized.

Show comment
Hide comment
@sternenseemann

sternenseemann Feb 10, 2017

Contributor

I think this kinda depends on a new xmpp implementation, because @hannesm wants to get rid of erm_xmpp (which is causing different issues, like #116).

Contributor

sternenseemann commented Feb 10, 2017

I think this kinda depends on a new xmpp implementation, because @hannesm wants to get rid of erm_xmpp (which is causing different issues, like #116).

@schoeke

This comment has been minimized.

Show comment
Hide comment

schoeke commented May 9, 2017

There was a bounty posted for this issue for $100. https://www.bountysource.com/issues/41164178-add-omemo-encryption-support

@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Apr 22, 2018

Owner

so I evaluated a bit our options to move forward here:

  • on the xmpp layer we need (as mentioned above) XEP 384
  • this uses pubsub from the xmpp spec, unclear about its support in (my branch of) erm_xmpp
  • also XEP 313, archive management is referenced (unclear to me whether required)
  • the crypto depends on the signal protocol library (or at least re-uses the double ratchet)

and down the stack, crypto requires some ECC operations:

I'd go another way, and interface the output (C code with only some intrinsics, and no external calls) of fia crypto, a ECC development in Coq, correct by construction - and then interface this simple C code from OCaml (similar to what nocrypto does atm). see a recent draft submission of that project https://people.csail.mit.edu/jgross/personal-website/papers/2018-fiat-crypto-pldi-draft.pdf

in the end, fiat-crypto contains a (rather complex) build chain, but is actively developed and they already have support for various ecc curves. i haven't checked whether they are sufficient for an omemo implementation (and am not sure about the exact differences between omemo and the noise protocol, neither between noise and signal). wireguard is another interesting project which is atm halted due to missing ecc (25519 as well? noise protocol framework?).

what do you think? /cc @cfcs @dinosaure would be great to have omemo in jackline in 2018!!!

Owner

hannesm commented Apr 22, 2018

so I evaluated a bit our options to move forward here:

  • on the xmpp layer we need (as mentioned above) XEP 384
  • this uses pubsub from the xmpp spec, unclear about its support in (my branch of) erm_xmpp
  • also XEP 313, archive management is referenced (unclear to me whether required)
  • the crypto depends on the signal protocol library (or at least re-uses the double ratchet)

and down the stack, crypto requires some ECC operations:

I'd go another way, and interface the output (C code with only some intrinsics, and no external calls) of fia crypto, a ECC development in Coq, correct by construction - and then interface this simple C code from OCaml (similar to what nocrypto does atm). see a recent draft submission of that project https://people.csail.mit.edu/jgross/personal-website/papers/2018-fiat-crypto-pldi-draft.pdf

in the end, fiat-crypto contains a (rather complex) build chain, but is actively developed and they already have support for various ecc curves. i haven't checked whether they are sufficient for an omemo implementation (and am not sure about the exact differences between omemo and the noise protocol, neither between noise and signal). wireguard is another interesting project which is atm halted due to missing ecc (25519 as well? noise protocol framework?).

what do you think? /cc @cfcs @dinosaure would be great to have omemo in jackline in 2018!!!

@dinosaure

This comment has been minimized.

Show comment
Hide comment
@dinosaure

dinosaure Apr 24, 2018

Ok, I think it's time to take my time again on curve25519, I just talked with @samoht about this implementation (for others purposes) and I just read some comments about dino/dino (like my surname) which is an XMPP client (specially fit for my family) with an OMEMO support. Too much signals about it, so I will restart callipyge.

Ok, I think it's time to take my time again on curve25519, I just talked with @samoht about this implementation (for others purposes) and I just read some comments about dino/dino (like my surname) which is an XMPP client (specially fit for my family) with an OMEMO support. Too much signals about it, so I will restart callipyge.

@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Apr 25, 2018

Owner

@dinosaure that is great to hear :) what are your plans for restarting callipyge?

Owner

hannesm commented Apr 25, 2018

@dinosaure that is great to hear :) what are your plans for restarting callipyge?

@dinosaure

This comment has been minimized.

Show comment
Hide comment
@dinosaure

dinosaure Apr 25, 2018

Focus on API and, like digestif, provide a C binding and an OCaml implementation. I need to figure out which implementation in C I will use. About coq-fiat, I have an idea but instrumentalize it to make an opam package should be little bit hard.

Focus on API and, like digestif, provide a C binding and an OCaml implementation. I need to figure out which implementation in C I will use. About coq-fiat, I have an idea but instrumentalize it to make an opam package should be little bit hard.

@samoht

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Apr 25, 2018

Maybe we can just host the generated C code from coq-fiat somewhere on GH (with the script to run to regenerate it) and just package it in opam.

samoht commented Apr 25, 2018

Maybe we can just host the generated C code from coq-fiat somewhere on GH (with the script to run to regenerate it) and just package it in opam.

@cfcs

This comment has been minimized.

Show comment
Hide comment
@cfcs

cfcs Apr 28, 2018

  • curve25519:

    • everyone else seems to be excited about hacl-star
    • I think copy-pasting the wireguard C code will be easy since it's self-contained (no libc). I haven't done it because I don't feel fit to maintain it, and I have no idea about neither ECC crypto security nor writing secure C code. This is extremely critical C code because it will face untrusted input from the network.
    • ocaml-sodium: this will be a pain to package for mirage, so I hope anything that depends on that in jackline will be optional (I at least still want jackline in mirage at some point)
    • if we're going to be breaking our backs to get new fancy crypto in, why don't we look at some algorithms that aren't likely to be broken in 15 years? https://openquantumsafe.org/ and https://libpqcrypto.org/ come to mind. The fact that NSA has deprecated their recommendations for ECC is also interesting.
      • or at least use Ed448 or whatever stronger crypto primitive people are suggesting today
    • I guess I've kind of lost faith in ECC, sorry to be bitter.
  • OMEMO: I read the spec, I'm not convinced by it as a spec. The only thing that's nice is being able to send a message to an offline person, and the spec seemed very underspecified - you'd likely end up having to read the code of the other implementations. That also makes it hard to review it formally.

    • Basically anything OMEMO does can be done with the existing OTRv3 implementation, and then we don't have to introduce more potentially buggy cryptographic implementations. @hannesm recently suggested adding a new set of parameters to OTR bumping the security (moving away from AES-128, SHA1, DH-1536 - like to AES-256, SHA384, DH-4096 or whatever). I think that would be nice.

cfcs commented Apr 28, 2018

  • curve25519:

    • everyone else seems to be excited about hacl-star
    • I think copy-pasting the wireguard C code will be easy since it's self-contained (no libc). I haven't done it because I don't feel fit to maintain it, and I have no idea about neither ECC crypto security nor writing secure C code. This is extremely critical C code because it will face untrusted input from the network.
    • ocaml-sodium: this will be a pain to package for mirage, so I hope anything that depends on that in jackline will be optional (I at least still want jackline in mirage at some point)
    • if we're going to be breaking our backs to get new fancy crypto in, why don't we look at some algorithms that aren't likely to be broken in 15 years? https://openquantumsafe.org/ and https://libpqcrypto.org/ come to mind. The fact that NSA has deprecated their recommendations for ECC is also interesting.
      • or at least use Ed448 or whatever stronger crypto primitive people are suggesting today
    • I guess I've kind of lost faith in ECC, sorry to be bitter.
  • OMEMO: I read the spec, I'm not convinced by it as a spec. The only thing that's nice is being able to send a message to an offline person, and the spec seemed very underspecified - you'd likely end up having to read the code of the other implementations. That also makes it hard to review it formally.

    • Basically anything OMEMO does can be done with the existing OTRv3 implementation, and then we don't have to introduce more potentially buggy cryptographic implementations. @hannesm recently suggested adding a new set of parameters to OTR bumping the security (moving away from AES-128, SHA1, DH-1536 - like to AES-256, SHA384, DH-4096 or whatever). I think that would be nice.
@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Jun 10, 2018

Owner

I'm not entirely sure where this information belongs (it is broader than "omemo in jackline", but rather "ECC for OCaml"), there's hacl-ocaml-package which uses the exported hacl-c-code, vendored inside of tezos' repository (using a custom hacl branch): https://github.com/tezos/tezos/tree/master/vendors/ocaml-hacl see as well https://github.com/vbmithr/ocaml-hacl for an incomplete mirror thereof

may be worth looking into that if the path forward is to use hacl

Owner

hannesm commented Jun 10, 2018

I'm not entirely sure where this information belongs (it is broader than "omemo in jackline", but rather "ECC for OCaml"), there's hacl-ocaml-package which uses the exported hacl-c-code, vendored inside of tezos' repository (using a custom hacl branch): https://github.com/tezos/tezos/tree/master/vendors/ocaml-hacl see as well https://github.com/vbmithr/ocaml-hacl for an incomplete mirror thereof

may be worth looking into that if the path forward is to use hacl

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