[Standards] OMEMO and Olm

Remko Tronçon remko at el-tramo.be
Fri Jun 2 07:59:02 UTC 2017


Hi,

I don't think this has much impact on the current discussion, but I'd like
to come back to this for the record (and it may be relevant as an upgrade
path):

On 31 May 2017 at 01:40, Chris Ballinger <chrisballinger at gmail.com> wrote:

> I don't have opposition to using Olm for any other reason than it will be
> costly to rewrite all of the existing clients.


Thinking about this a bit more, I don't think switching libsignal-based
clients to use Olm (the algorithm) with split identity keypairs would cause
a rewrite, or even lose any current identity keys. In fact, it would
probably even less work than my first proposal for a key agreement
compromise. I think the choice of terminology was making this sound worse
than it was.

What Olm (and the PR) calls the 'fingerprint key' and 'identity key'
correspond in libSignal terms to 'identity key' (long-standing key,
authenticated, never changes) and 'signed prekey' (a key that is signed by
the authenticated key, and changed from time to time).

With this terminology change, switching LibSignal-based clients to use Olm
would require 3 local changes:

- LibSignal's internal Curve25519 identity keys are converted to Ed25519
before publishing. (same as in my key agreement proposal). This is 1 extra
call to a function (of which the code is already in libsignal) right before
publishing the identity key, outside libsignal.
- Signature verification is changed to use EdDSA instead of XEdDSA (same as
in my key agreement proposal). This is a matter of changing one function
call to another in libsignal (this function is already in libsignal)
- Shared secrets are computed using 3DH on (signedPreKey, oneTimeKey_a,
oneTimeKey_b) instead of X3DH on (identityKey, signedPreKey, oneTimeKey_a,
oneTimeKey_b). This requires deleting 1 function call in libsignal.

Applying these local changes should be enough to change any existing
libsignal-based client into an Olm-compatible client. The difference with
my first key agreement proposal is that this brings us back to a reviewed
protocol (instead of a slightly modified libsignal one), and does not
require adding the Ed2Curve conversion function to libsignal (all the
required functions are already there).

Remko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170602/33e65b35/attachment.html>


More information about the Standards mailing list