Hi Remko, On 3 June 2017 at 05:29, Remko Tronçon <[email protected]> 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: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
