On 31 March 2017 at 11:17, <[email protected]> wrote: > Hi Remko, > > I have some comments. > >> 1. We go back to Olm's protocol of establishing an initial shared >> secret, using regular 3DH instead of X3DH. >> >> + Moves us back to an audited, implementable algorithm >> >> + No need to change existing identity keys >> - This weakens the forward secrecy. I don't know enough about it >> to understand the consequence. > > > The attack is described in [1] and boils down to the following: > If Eve replaces Alice's ephemeral public keys with her own when they are > requested by Bob, she can decrypt messages sent from Bob to Alice in case > the learns Alice's long-term private key at any later point in time. > However, Alice herself cannot decrypt these messages, so it is a very > visible attack. >
Do I understand this correctly? To carry off this attack, Eve must intercept and override the keys published by Alice (easy to do if Eve is a server) and then also compromise Alice's private key, and in the meantime, Alice cannot decrypt the messages anyway? Surely this is trivial to fully mitigate by having Bob "ping" Alice over an encrypted message to ensure Alice can decrypt, prior to sending actual message data? > While I think that because of the noticability the possible damage is very > limited, I kind of agree that it is not acceptable by design. > One argument for 3DH might be its full deniability, which X3DH does not > provide, though. > > >> >> 2. We replace XEdDSA (the primitive on which X3DH relies) with EdDSA. >> ... >> 3. We stay with XEdDSA (the primitive on which X3DH relies) > > > X3DH does not rely on XEdDSA, it relies on any digital signature. > This addition of the signature was proposed in [1], which does not specify > an algorithm. > XEdDSA is just a scheme for re-using X25519 identity keys used in the key > exchange for a digital signature algorithm, i.e. mapping Curve25519 to > Ed25519. > > If all else fails, there is always the possibility to have both a X25519 and > a Ed25519 key, but I don't really think the conversion specified in [2] > qualifies as "crypto". I might be wrong but it seems to me like if it is not > implemented correctly it just won't work. As the resulting signature is > supposed to be compatible with EdDSA, it is easy to consult an "oracle" for > testing. > > > 1: Cas Cremers and Michele Feltz. One-Round Strongly Secure Key Exchange > with Perfect Forward Secrecy and Deniability. > https://eprint.iacr.org/2011/300 > > 2: https://whispersystems.org/docs/specifications/xeddsa/ > > _______________________________________________ > 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] _______________________________________________
