[Standards] OMEMO Key Agreement

Sebastian Verschoor sebastian.verschoor at gmail.com
Mon Jun 5 20:12:08 UTC 2017


Hi Remko,

On 3 June 2017 at 05:29, Remko Tronçon <remko at el-tramo.be> wrote:

> Hi Sebastian,
>
> 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 [1] (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 [1], 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.
>

I think you are right here, the blogpost mentions how unintended publishing
of the (old style) fingerprints was hurting users privacy.


> > 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?
>

TBH: I don't know enough about Olm to answer that. From what I read in the
specs they do 3DH: s = DH(IK_A, OTK_B) || DH(OTK_A, IK_B) || DH(OTK_A,
OTK_B).


> 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?).
>

So there is no long-term key involved in the key agreement? I don't think
that such a protocol authenticates the other party... If that is true the
protocol has bigger problems than just deniability...

In X3DH, there are four DH computations (
https://whispersystems.org/docs/specifications/x3dh/#sending-the-initial-message
):
- DH(IK_A, SPK_B) authenticates Alice
- DH(EK_A, IK_B)  authenticates Bob
- DH(EK_A, OPK_B) adds forward secrecy for honest parties
- DH(EK_A, SPK_B) adds forward secrecy with dishonest parties

Imagine the last DH (and thus Bob's signature on his prekey) is missing.
Then Eve can impersonate Bob by publishing a prekeybundle with her own
one-time prekeys and Bob's public key.  When Alice sends her messages to
Eve (thinking she is sending a message to Bob), Eve collects and stores the
ciphertext, which she can't decrypt yet.  Later, she compromises Bob's
device and with his long-term private key, she can decrypt the collected
messages. This attack thus breaks the forward-secrecy of the initial
messages. The signed prekey prevents this attack, because Eve can no longer
publish a prekey bundle impersonating Bob (as that would require forging a
signature).


>
> thanks!
> Remko
>
> [1] https://www.whispersystems.org/blog/safety-number-updates/
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170605/c33ffffa/attachment.html>


More information about the Standards mailing list