Hi Sofía! 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 <[email protected]>: > > 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 [3]. > 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 [3]. 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 [11] (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 [4], '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'. Noted :) > - '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 [5]. Good idea! > - 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: > > 1. > 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. > > 2. > 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 > start. > > - The double ratchet algorithm has an interesting case for when both > parties start it at the same time. This is briefly covered on [6]: > > "(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 > proposed. 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! > Thanks! Thank you :) _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
