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. > 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?). thanks! Remko [1] https://www.whispersystems.org/blog/safety-number-updates/
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
