Add Omemo Encryption Support

[dreamflasher]

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]

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

[dreamflasher]

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

[hannesm]

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.

[jfrederickson]

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]

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]

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]

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

[hannesm]

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:

• there is some pure (buggy, see issue 2?) OCaml 25519 code
• OCaml BIP32 ED25519 (don't know much aout this)
• ocaml-sodium (which interfaces the C lib).

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]

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]

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

[dinosaure]

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]

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]

• 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.