[Standards] OMEMO Key Agreement
remko at el-tramo.be
Sat Jun 3 09:29:39 UTC 2017
Thanks for your feedback, it's insightful.
> Remko, generally speaking there are some issues with your proposal.
I think we ended up agreeing that the way I was looking for compromises
wasn't ideal for future-proofness. Apparently, it also has cryptographical
problems. I don't think we should dig into this further or try to fix it.
> The fingerprints of the Signal protocol have been crafted such that you
can publish your fingerprint on long-term media (on your business-card
would be a typical scenario).
Right, I wasn't saying it wasn't. I was saying that breaking fingerprints
to get to a protocol where we are all comfortable with would be suboptimal,
but maybe wasn't a dealbreaker. Even Signal changed their fingerprints
AFAIK  (although perhaps in a way that people who really wanted to could
decompose the new format and still reuse their fingerprints)
As a sidenote, "crafted for printing" depends how you look at it. Signal
fingerprints are per-conversation. From , I understand that to get
something to put on a business card, you need to split the fingerprint,
figure out which half is yours, and the other party needs to know how to
interpret this and do the same. So it's not really part of the flow they're
trying to push, but it can be done if you really wanted to.
> This confuses me.
> This is not just a difference of terminology, but these are
cryptographically different operations.
The terminology comes from an Olm document. My point (and others pointed
this out to me as well) was indeed that this terminology was confusing, and
probably needs to change.
I also didn't mean to say that X3DH and 3DH are the same of course. My
point in that mail was to point out that I think that modifying libsignal
to do Olm's 3DH doesn't require a full rewrite of all clients. But I get
that reusing the identity key only for signing but not for 3DH might have
issues (and another upgrade path might need to be found).
> I don't think you are missing anything here. As long as you tie your keys
together (for example, by signing your DH-key with your signing key) this
sounds fine. The reason to introduce XEdDSA is not having to change the
key fingerprint, a usability point.
> Just introduce a fourth DH in your initial handshake and you get the best
of both worlds.
Am I understanding you correctly that using Olm as it is defined today
(combined with separate keys for signing and DH, and signing the DH key)
can work, but that the key agreement can be improved (i.e. add a 4th DH) to
get the extra properties that Signal gives you?
I don't understand yet what the 4th DH does, though. Given that I_b is
signed (and can be replaced from time to time), I was assuming this
corresponds to the signed prekey instead of the identity keys from X3DH.
This would mean that Olm's 3DH doesn't use a long-standing identity key in
its key agreement (it's only used to sign the prekey), and that Olm's 3DH
involves signed prekeys from both parties (does this impact deniability?).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards