Hi! In one of your previous mails [1] you suggest to use the fact, that libraries like LibSodium support Ed to Curve conversion, to remove the requirement for XEdDSA from the X3DH protocol.
Instead of sending the encryption key as part of your public X3DH bundle you would send the signature verification key and other clients could easily derive the encryption key from it using built-in functions/methods provided by many libraries. This is exactly what I wanted to suggest before I remembered searching through the mail archives :D I really like this approach, it uses most of the original signal protocol, only requires minor changes to libsignal and allows for easier new implementations. In fact I recently finished a python implementation of the DoubleRatchet and X3DH protocols written from scratch that uses exactly this approach (I want to do a little more testing and documentation before releasing it) and I can confirm it makes things a lot easier if you don't have to implement XEdDSA. I would prefer this approach a LOT over using two key-pairs and tying them together using signatures. Is there any particular reason you discarded the approach I described in favor of the one you mentioned in this mail? (Maybe I missed a mail in the archives?) Best regards, Syndace [1]: https://mail.jabber.org/pipermail/standards/2017-May/032765.html On 15.10.2017 13:42, Remko Tronçon wrote: > Hi, > > A few months ago, there were discussions around the OMEMO key > agreement protocol, which we said we'd revisit once the XEP was > changed to document the historical SIACS protocol, and we then could > move on to making OMEMO future-proof. With all that out of the way, > i'm picking this up again now. > > The problem with the current key agreement is that it relies on > XEdDSA, a custom cryptographic primitive, not generally available in > established libraries (OpenSSL, LibSodium, ...), blocking further > adoption of OMEMO. It would be better for both practical, risk, and > consistency reasons to only rely on accepted and widely available > cryptographic primitives. > > One of the proposed solutions was to switch from a single X25519 > keypair for both DH and signing keys (using XEdDSA) to an X25519 > keypair for DH + an Ed25519 keypair for signing keys (using EdDSA, > widely accepted), and tying both keypairs together using a signature. > This is also the approach taken by Matrix in their Olm protocol. > > This impacts the key agreement implementations of existing SIACS > clients, but we were hoping people would care less about this once the > siacs XEP was published. That said, AFAICT, this stays limited to a > (local) change in the implementation only, and doesn't impact the > already generated keys: the currently used X25519 keys can be > converted to Ed25519 keys (something which XEdDSA relies on already), > so existing key validations of your contacts keys don't have to be > invalidated. From the user's perspective, only fingerprints that were > sent out-of-band between the switch to the new protocol will be > invalidated, which is a very limited impact. > > Any comments on this? > > thanks, > Remko > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
