[summoned by https://twitter.com/DwdDave/status/847908152561602561]
On 30/03/2017 09:09, remko wrote:
Hi,
The upcoming version of the OMEMO XEP relies on X3DH for establishing
an initial shared secret. In my extremely limited understanding of
it, I'm wondering whether this is the best approach for OMEMO.
X3DH relies on XEdDSA to be able to use Curve25519 keys to create
EdDSA-signatures. As far as I can tell, this solved a problem where
all long-standing identity keys in Signal were X25519, and they
needed them to create signatures (which you can't do without
conversion to Ed25519). I can't seem to find any public
implementation of XEdDSA yet, except in libsignal, so this sounds
like it makes implementing OMEMO pretty hard at the moment.
[disclaimer: I'm a bit rusty on this, and haven't worked on it directly,
but given the main crypto devs for Matrix are on holiday today I'll try
to respond...]
For libolm, we deliberately didn't follow Signal's behaviour of trying
to share identity & signing keys: it seemed overengineered and of
questionable value to add complexity in exchange for tracking one key
rather than two. So we just maintain two, and don't bother with all the
additional complexity X3DH complexity which results. It's possible that
we're missing some subtlety.
It looks like elsewhere in the thread folks are conflating the question
of signing one-time keys with the X25519 issue. As i understand it, the
two are unrelated: libolm leaves the question of whether to sign
pre-keys up to the application layer; if you want stronger PFS semantics
at the expense of reduced deniability, go for it. This is nothing to do
with whether you use X3DH or 3DH for key exchange.
http://matrix.org/docs/olm_signing.html attempts to describe this trade-off.
I'm a bit confused as to why the OMEMO community has moved away from Olm
in favour of creating a new ODR, to be honest - I assumed that by
releasing Olm under the Apache license and getting it publicly audited
NCC Group
(https://nccgroup.trust/us/our-research/matrix-olm-cryptographic-review)
it would be really useful for precisely this sort of use case. For
context, I know of no other publicly audited double ratchet
implementation (including libsignal...)
If there are security concerns with it, please can someone let us know?
Looking at https://github.com/xsf/xeps/pull/460, the only argument I've
seen so far for moving to ODR seems to be "We now use our own, new wire
format, making the protocol independent from third parties." - which
seems bizarre, given libsignal & olm share a very very similar
protobuf-based line protocol, and avoiding dependency on audited
liberal-licensed 3rd parties for the sake of it seems political at best :/
Matthew
--
Matthew Hodgson
Matrix.org
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
