[Standards] OMEMO Key Agreement (v2)

Ignat Gavrilov ignat.gavrilov at mailfence.com
Wed May 31 20:27:02 UTC 2017


> "Remko Tronçon" <remko at el-tramo.be> wrote:
> Here's a proposal for the OMEMO key exchange that requires *no* 
> changes to libsignal: Public Identity keys are Ed25519 keys with the
> highest bit (sign bit) 0.
> - LibSignal-based clients convert their internal Curve25519 identity key 
>   to Ed25519 right before the device bundle publish IQ, and convert the 
>   peer key to Curve25519 when fetching the bundle IQ.
> - On device initialization, non-libsignal clients guarantee a keypair that 
>   LibSignal can handle by generating identity keypairs until the highest 
>   bit of the public key is set to 0 (there's a 1 in 2 chance).

1. Does this even work? I think the Signatures made using Ed25519 on your 
   "non-libsignal" side (which not necessarily includes all non-libsignal
   implementations) will not be verifiable on the libsignal side and
2. Why is the key conversion step on the libsignal side? Couldn't it be as 
   well on the non-libsignal side, minimizing the migration-effort for 
   existing implementations (and those who don't want to use a 
   libsodium/olm-based impl)? What's the rationale behind this choice?

> The keys (and so existing authentications) stay valid, but if there would
> have been fingerprints printed, these would indeed become invalid. I'm not
> sure if printing fingerprints is something that is done in practice today
> with OMEMO anyway (as opposed to PGP).

Many people might have published their fingerprint all over the internet.
Changing those can be a hassle, especially as there is no standard for
key rollover in this case.

Please bear in mind that some clients may want to have a migration-phase where
they are able to do the current implementation *and* the new one. If at this
state a fingerprint exchange is not reliable (because it's unknown what kind
of fingerprint the other user expects) or the user has to choose the right one
from two fingerprints, this would greatly harm user experience.

> I'm not a cryptographer [...]
> We change X3DH [...]

I wonder how these two statements can come from the same person...


Von: ignat.gavrilov at mailfence.com
Bis: "XMPP Standards" <standards at xmpp.org>
31.05.2017 14:26:49
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 814 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170531/cfbdcc16/attachment.sig>

More information about the Standards mailing list