<div dir="ltr">Hi Remko,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 3 June 2017 at 05:29, Remko Tronçon <span dir="ltr"><<a href="mailto:remko@el-tramo.be" target="_blank">remko@el-tramo.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Sebastian,<div><br></div><div>Thanks for your feedback, it's insightful.</div><span class=""><div><br></div><div>> Remko, generally speaking there are some issues with your proposal.<br></div><div><br></div></span><div>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.</div><span class=""><div><br></div><div>> 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).</div><div><br></div></span><div>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)</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I think you are right here, the blogpost mentions how unintended publishing of the (old style) fingerprints was hurting users privacy.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>> This confuses me. </div><span class=""><div>> This is not just a difference of terminology, but these are cryptographically different operations.<br></div><div><br></div></span><div>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.</div><div><br></div><div>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).</div><span class=""><div><br></div><div>> 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.</div></span><span class=""><div>> Just introduce a fourth DH in your initial handshake and you get the best of both worlds.</div><div><br></div></span><div>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?</div></div></blockquote><div><br></div><div>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).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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?).</div></div></blockquote><div><br></div><div>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...<br><br></div><div>In X3DH, there are four DH computations (<a href="https://whispersystems.org/docs/specifications/x3dh/#sending-the-initial-message">https://whispersystems.org/docs/specifications/x3dh/#sending-the-initial-message</a>):<br></div><div>- DH(IK_A, SPK_B) authenticates Alice<br></div><div>- DH(EK_A, IK_B)  authenticates Bob<br></div><div>- DH(EK_A, OPK_B) adds forward secrecy for honest parties<br></div><div>- DH(EK_A, SPK_B) adds forward secrecy with dishonest parties<br></div><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>thanks!</div><div>Remko</div><div><br></div><div>[1] <a href="https://www.whispersystems.org/blog/safety-number-updates/" target="_blank">https://www.whispersystems.<wbr>org/blog/safety-number-<wbr>updates/</a></div></div>
<br>______________________________<wbr>_________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/<wbr>mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
______________________________<wbr>_________________<br>
<br></blockquote></div><br></div></div></div>