axolotl, OMEMO vs OpenPGP

[Ben McGinnes]

On Mon, Mar 21, 2016 at 04:33:34PM +0100, Bernhard Reiter wrote:
> Hi Friends of GnuPG,
> 
> right now I am thinking about the properties and use cases
> for OpenPGP compared to axolotl [1] and OMEMO [2].
> 
> The advertisment page for Conversation's OMEMO support [3]
> claims that it is superior to OpenPGP:
> 
> | OMEMO not only gives you a better encryption features than OpenPGP
> | and OTR but is also much easier to setup.

I just had a quick look at that page and it looks like they're playing
a little fast and loose with the truth.  With the link to an
(obsolete) XMPP Foundation document and reading through that as well;
what they're actually saying is specifically within the context of
past attempts to implement encryption for XMPP using OpenPGP.
Apparently this was what some developers tried before developing OTR.

Now specifically within the context of implementing OpenPGP compliant
features with XMPP, the current claim is probably correct.  What they
decided not to mention was that this statement refers to that
attempted implementation and not, for example, to GPG.  Nor do they do
anything else to discourage misinterpretation of the statements by
anyone else.

The only bit that's unclear is whether this is intentional ow whether
they're just so wrapped up in the focus on solutions for XMPP that
they haven't realised how their statements could be read.

> And I wonder in which situations this is true.
> OMEMO says it does the trick of being "forward secret" and 
> offline capable. Is this even possible while being end-to-end, 
> e.g. not trusting a service provider?

The Confidant Mail project has already achieved something similar with
GPG as the base for it (by rotating encryption subkeys).  Though it
sticks with the UID model rather than the device ID (and I wonder how
that model would handle something like cloning a smartphone).

> If I am offline I could not create ephemeral session keys
> or does this depend on previously exchanged keys?

There still needs to be some form of secure key exchange, either via
previously established master keys or a real time exchange (with out
of band confirmation).

> Any thoughts?
> Does somebody has pointer to in depth analysis?

Personally I suspect this will turn out to be a bit like the OpenPGP
statement; it will be true within a very specific context which sounds
more impressive than the technical details will allow.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: </pipermail/attachments/20160323/103e7bca/attachment.sig>