Thanks, I that clears some things up for me, not so worrisome after all, I now believe that the users are properly authenticated. I have thought about the Matrix protocol with seperated DH/signing keys some more and discussed it with a colleague and we believe it is fine. A very minor points springs to my mind, but I think you can judge for yourself if you think this is an acceptable risk: Eve can impersonate Bob when she compromises a private Curve25519 key that is signed by Bob's Ed25519 key without compromising the Ed25519 private key itself. This should not be possible under normal circumstances, but I can think of two scenario's: (1) Eve tricks Bob into signing a Curve25519 key generated by her. This should never happen as long as the only thing that Bob signs is his own locally generated public keys; (2) Bob's random number generator is weak during some identity-key generation, so Eve can guess/bruteforce his private Curve25519 key. Compare this to X3DH where a RNG failure results in the loss of security for a session, not an identity.
I don't know how likely either scenario is in your context: you can better judge that for yourself. On 6 June 2017 at 09:14, Richard van der Hoff <[email protected]> wrote: > At the risk of turning the standards list into a forum discussing the > finer points of cryptographic key exchange, I thought it might be useful > weigh in on some of the issues raised, in the hope of clearing up some > confusion. > > As Matthew has previously said: it's certainly not our intention to > attempt to railroad the decisions of the XMPP community - just trying to > make sure that the information on which such decisions are made is sound. > > Sebastian Verschoor wrote: > > 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). >> >> > That's correct, as far as it goes. It's worth reiterating that, in the > libolm implementation, IK_A and IK_B have previously been signed by the > relevant user's (long-term) Ed25519 key. > > We don't consider that part of the core Olm protocol (which assumes you > are starting with identity keys you trust, and focusses on the triple-DH > and double ratchet); indeed an alternative implementation is possible in > which you don't bother with the Ed25519 keys and treat the IKs as long-term > instead, but since the only implementation of Olm I know of uses the > Ed25519 key as the long-term key, we may as well forget it. > > In Matrix, at least, we also have Bob sign OTK_B which avoids the > potential loss of forward secrecy if Eve later compromises IK_B, though it > does come with a trade-off in deniability. > > I've tried to explain both of these points at > https://matrix.org/git/olm/about/docs/signing.rst. (Sebastian previously > described that document as 'worrisome' [1] but I wonder if that was based > on some misunderstandings which have since been cleared up. If not, I'd be > very glad to discuss your worries.) > > One other point here: although we refer to Alice's short-term key in this > exchange as a one-time-key (hence OTK_A here), it is never "published" > outside the Olm setup, so that makes it analogous to an ephemeral key in > the Signal terminology. so E_A might be a better symbol for it. (In general > the Olm spec is, regrettably, somewhat inconsistent in the use of the terms > 'ephemeral key' vs 'one-time key' vs 'single-use key' and tends to treat > them all interchangeably.) > > 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 is a valid analogy. > > 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... >> > > It's true that such an exchange doesn't identify the other party by > itself. Assuming you're using a system whereby you use the Ed25519 key as > the long-term key and periodically rotate the Curve25519 olm 'identity' > key, this works as follows: > > 1. Alice and Bob exchange and verify each other's public Ed25519 keys > out-of-band - or exchange them in-band and TOFU. > > 2. Alice publishes a message including her (current) public Curve25519 > identity key IK_A and signs it with her Ed25519 key. In doing so she is > claiming control of the private part of IK_A (though there is no evidence > of this yet). In other words: this signature prevents an eavesdropper Eve > masquerading as Alice and publishing a key she controls in place of > Alice's; it does *not* prevent Alice publishing someone else's Curve25519 > key as her own. > > 3. Bob downloads Alice's signed key, and likewise publishes his own signed > key IK_B - again, claiming but not proving control of the private part of > that key. > > 4. Alice now downloads Bob's signed key (along with one of his one-time > keys), and initiates the 3DH exchange. She uses it to encrypt a pre-key > message which *must* include her public Ed25519 key, as well as Bob's user > ID. > > 5. Bob receives the pre-key message, and decrypts it. He must now check > that the Ed25519 key embedded within the message matches that he has > verified for Alice. This check prevents Alice publishing someone else's > Curve25519 key as her own. > > (Bob also checks the user ID, to mitigate an unknown key-share attack > whereby Mallory publishes Bob's IK_B as her own, and Alice thinks she is > talking to Mallory, but Mallory is forwarding the messages to Bob, and Bob > thinks the message was intended for him.) > > 6. Bob replies to the pre-key message including his own Ed25519 key, to > allow Alice to finally verify that Bob controls IK_B. > > > Regards > > Richard > > > [1] https://mail.jabber.org/pipermail/standards/2017-June/032866.html > > _______________________________________________ > 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] _______________________________________________
