Re: [Standards] OMEMO Key Agreement
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 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
Re: [Standards] OMEMO Key Agreement
On 6 Jun 2017 14:14, "Richard van der Hoff" 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. As a matter of general principle, by posting to this list you have satisfied one of the many possible ways of becoming as much as member of the XMPP community as anyone else... Please do feel free to post messages like this, I for one found it very useful. 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/abo ut/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 t
Re: [Standards] Encrypted Jingle File Transfer
On 06.06.2017 17:11, Vanitas Vitae wrote: > * Implement the security element > o - leaves metadata in the clear > o + more flexible and easier to implement > o + integrates better into existing XEPs > o implementations that do not support this can still transfer the > (encrypted) file/stream (not sure, if this is positive/negative) o + is agnostic, can (theoretically) be used with every already specified use case > * Transport metadata and key serialized/xmlenc encrypted > o + hides metadata > o - not trivial to do > o - more likely to require addon-XEPs o - requires extra per use-case Both approaches require add-on XEPs. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Encrypted Jingle File Transfer
Hi Goffi! I actually already thought about the securiy element as well. It seems like there are two different possibilities here: * Implement the security element o - leaves metadata in the clear o + more flexible and easier to implement o + integrates better into existing XEPs o implementations that do not support this can still transfer the (encrypted) file/stream (not sure, if this is positive/negative) * Transport metadata and key serialized/xmlenc encrypted o + hides metadata o - not trivial to do o - more likely to require addon-XEPs While the second solution is more preferable from a privacy standpoint, I'm thinking of going the first route first and maybe later tackle the second way. Am 06.06.2017 um 16:36 schrieb Goffi: > I would like that we avoid something tied to File Transfert, so we can > use > encryption with any application (or transport), and for this we need > to have encryption layer between application and transport. I thought about it and in theory the "partial-stanza-encryption" method should also be applicable on other applications like voice/video. This requires some more thought though... Vanitasvitae ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 6/2/17 9:18 PM, Sebastian Verschoor wrote: I also noted that although Olm has been audited [9], the scope of the audit only concerns the double ratchet. Given that Olm differs from Signal only in the handshake, I find this strange. Has the handshake not been audited? Am I missing something? The handshake was included in the scope of the DR audit (even if the abstract doesn't specifically call it out) - findings NCC-Olm2016-001 and NCC-Olm2016-009 explicitly highlight the need for ephemeral keys to be signed, and the risk of an unknown key-share attack in the handshake. We chose to mitigate these at the application level (updating the Olm documentation to spell out the mitigations required). That said, as Richard said on the earlier mail, please do let us know if you still think Olm should be doing X3DH (possibly off-list, as it's increasingly non-OMEMO/XMPP specific :) Matthew -- Matthew Hodgson Matrix.org ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Encrypted Jingle File Transfer
Le dimanche 4 juin 2017, 15:01:45 CEST Vanitas Vitae a écrit : > Hi! > > As part of my GSoC project I'd like to think of a way to enable > end-to-end encrypted Jingle file transfer. [...] Hi, really nice to see somebody working on that. I haven't read your stuff in details yet (running out of time right now), but may I suggest that you have a look a security preconditions (https://xmpp.org/extensions/ xep-0166.html#preconditions) which is exactly there for encryption. I would like that we avoid something tied to File Transfert, so we can use encryption with any application (or transport), and for this we need to have encryption layer between application and transport. Please keep us up to date on this list, I would follow your work. Thanks and good luck Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
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: standards-
Re: [Standards] Encrypted Jingle File Transfer
While based on the old eSessions specification, it might well be worth looking at XEP-0200 for full-stanza encryption. ISTR it was implemented by Gajim back in the day, but I may be wrong - this specification was last updated just over a decade ago.#, and my memory really isn't *that* good... On 4 Jun 2017 16:47, "Fabian Beutel" wrote: > Hey, > > I very much like the idea of having the option to encrypt complete > stanzas! I think this could be implemented transparently and would allow > all kind of jingle session meta data to be secret. > > I wrote about this on this list on two occasions already: > https://mail.jabber.org/pipermail/standards/2016-October/031475.html > https://mail.jabber.org/pipermail/standards/2016-September/031440.html > > > Basically, I would love to see a specification which describes how to > transparently encrypt arbitrary stanzas (or parts of stanzas). > This should be kept in a separate XEP from encrypted > Jingle-Filetransfer, however, the latter could then refer to the > stanza-encryption-XEP for not leaking meta data etc. > > Best regards, > Fabian > > > On 04.06.2017 15:31, Remko Tronçon wrote: > > Hi Vanitasvitae! > > > > I wonder if it would make sense to use something like xmlenc to have a > > 'generic' way to encrypt (parts of) stanzas. This way, you can decouple > > the encryption key info etc. from the things you want to encrypt, and > > you can choose to encrypt entire elements, or just parts of elements. > > > > For example, if you want to encrypt the entire metadata: > > > > > > > > > > BASE64ENCODED... > > BASE64ENCODED... > > ... > > > > > >>action='session-initiate' > >initiator='romeo@montague.example/dr4hcr0st3lup4c' > >sid='851ba2'> > > > > > > > > http://www.w3.org/2001/04/xmlenc#"; > > Type="http://www.w3.org/2001/04/xmlenc#Element";> > > > Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> > > http://www.w3.org/2000/09/xmldsig#";> > > omemo > > > > > > > > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/ > 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj > wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/ > uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p > > > > > > > > > > > > > > > > Or, if you just want to encrypt only parts of the (e.g. not the > hash) > > > > > > > > > > BASE64ENCODED... > > BASE64ENCODED... > > ... > > > > > >>action='session-initiate' > >initiator='romeo@montague.example/dr4hcr0st3lup4c' > >sid='851ba2'> > > > > > > > > > algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48= > > > > > > http://www.w3.org/2001/04/xmlenc#"; > > Type="http://www.w3.org/2001/04/xmlenc#Content";> > >> Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> > > http://www.w3.org/2000/09/xmldsig#";> > > omemo > > > > > > > > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/ > 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj > wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/ > uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p > > > > > > > > > > > > > > > > > > KeyInfo could be used to distinguish where the key material is coming > > from for encryption (e.g. OMEMO element at the top of the IQ). > > > > I'm not saying xmlenc is very elegant, and it's very broad, but it has > > the advantage that you may get an implementation for free in your > > language? It might need some restricting of possible algorithms/keys/... > > for clients that need to implement this themselves if they don't have > > xmlenc available. > > > > Remko > > > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
