[Standards] Review of XEP-0384: OMEMO Encryption
vanitasvitae at fsfe.org
Mon May 18 10:03:38 UTC 2020
Sorry for the late reply, your mail was not forgotten :)
Thank you very much for the valuable feedback, we'll strive to incorporate it in the next version of the XEP!
12.05.2020 01:22:16 Sofía Celi <cherenkov at riseup.net>:
> The notion of:
> - "Perfect forward secrecy: Compromised key material does not compromise
> previous or future message exchanges."
> is not completely correct. This definition is now referred a Forward
> Secrecy only. Forward secrecy refers to the fact that 'if the state of a
> party is leaked, none of the previous messages should get compromised
> (assuming they are erased from the state, of course).' It only deals
> with previous exchanged messages but not to future ones.
Ah bummer, that one slipped through indeed. We'll fix that.
> - Immutability: Every peer can ensure that a message was not changed by
> any intermediate node.
> I think this definition is actually called 'Integrity'.
That is indeed true and you are totally right. Put on the to-fix list as well :)
> - 'Plausible deniability: No participant can prove who created a
> specific message.'
> Plausible deniability is a legal definition, as far as I'm aware of .
> The notion of deniability in cryptography depends on which type wants to
> be given, as it is possible to deny authorship of a message (it is not
> possible to deny 'creation' in this terms) or participation in a whole
> conversation. Furthermore, the current notions of deniability in the
> literature also define it in terms of offline and online.
> X3DH is weakly
> offline deniable and provides no online deniability, as far as the
> research shows .
This goes beyond my limited knowledge of crypto tbh. I'll read up on that.
> - 'An attacker has permanent access to your device. Temporary access is
> covered by perfect forward secrecy.'
> I think that if an attacker have access to a device, there is no real
> forward secrecy, as this attacker have access to the log/screen of the
> device. Other protocols have taken further steps to enhance this by
> providing, for example, a 'Disappearing messages' option from a UI
> perspective. I don't know if this is something that applications that
> implement OMEMO use.
There is no implementation that I'm aware of indeed.
> - 'Implementations must use the birational map between the curves
> Curve25519 and Ed25519 to convert the public part of the IdentityKey
> whenever required, as defined in RFC 7748  (on page 5).'
> This is very interesting and quite possible. But I was wondering if
> there is a mechanism used to correctly handle the cofactor in this both
> cases, or a correct generation of the keys.
I happily refer you to Andy Straub or Tim Henkes, who have a better understanding of Curve cryptography than I do :P
> - 'deletion policy for skipped message keys
> Skipped message keys MUST be stored until MAX_SKIP message keys are
> stored. At that point, keys are discarded on a FIFO basis to make space
> for new message keys. Implementations SHOULD not keep skipped message
> keys around forever, but discard old keys on a different
> implementation-defined policy. It is RECOMMENDED to base this policy on
> deterministic events rather than time.'
> While this is nice idea, I think an attack might happen if it is
> implemented. As the Signal specification for the double ratchet
> algorithm states , 'a malicious sender could induce recipients to
> store large numbers of skipped message keys, possibly causing
> denial-of-service due to consuming storage space.', so it is a wise idea
> to have a MAX_SKIP parameter. But, if an attacker knows that after this
> limit is reached keys will start to get deleted, the attacker can induce
> to keep sending fake messages so authentic keys get deleted. I think a
> mitigation against this is jut to delete skipped message keys after an
> appropriate interval.
I think that the thread to communication can be omitted by storing MAX_SKIP keys per conversation and that only if the message that contains the high counter is actually a valid message (to prevent injection of raised counters into valid sessions). In that case all an attacker can do is waste MAX_SKIP keys worth of memory (per attacking account) as only keys of the attacking session are being deleted, but no other, unrelated keys.
> - 'HKDF-SHA-256 using the rk as HKDF salt, dh_out as HKDF input material
> and "OMEMO Root Chain" as HKDF info.', 'HMAC-SHA-256 using ck as the
> HMAC key, a single byte constant 0x01 as HMAC input to produce the next
> message key and a single byte constant 0x02 as HMAC input to produce the
> next chain key.'
> I think probably what 'rk' and what 'ck' is should be defined previously
> (or pointing out to the specific place on the double ratchet
> specification). It can get confusing ;)
> The same for 'mk'.
> - 'Generate 32 bytes of cryptographically secure random data, called key
> in the remainder of this algorithm.'
> It will be good to point out what is 'cryptographically secure random
> data'. Usually, linking to RF4086 is enough .
> - Multi-device synchronization
> I think this is a nice way to do multi-device synchronization, but I
> don't know if these two cases have been taken into account:
> Alice can try to start a conversation from device 1. Bob will receive
> this request on device 1 and ask for the list of devices from himself
> and from Alice (on device 1). Bob on device 1 will try to start the
> appropriate session with each of Alice's devices (and with his own). At
> the same time, Alice can try to start a conversation from device 2 with
> Bob on device 1, which will trigger device 1 from Bob to ask for the
> list of devices again. I'm not sure how this is handled.
> More difficult to solve is the situation when Alice tries to start a
> conversation from device 2 with Bob on device 2, when there is already a
> request from Alice on device 1 to Bob on device 1. What can happen in
> this case is that two sets of 'multi-device synchronized' sessions
> - The double ratchet algorithm has an interesting case for when both
> parties start it at the same time. This is briefly covered on :
> "(This assumes Alice begins sending messages first, and Bob doesn't send
> messages until he has received one of Alice's messages. To allow Bob to
> send messages immediately after initialization Bob's sending chain key
> and Alice's receiving chain key could be initialized to a shared secret.
> For the sake of simplicity we won't consider this further.)
> I'm not sure if this has been considered and if any solution has been
This race might indeed have slipped our eyes. Thanks for pointing it out :)
> Apologies if any of this is already resolved ;) I did not review neither
> the group chat details nor the SCE Profile ones.
> Hope this is helpful!
Very helpful, indeed!
Thank you :)
More information about the Standards