If an attacker can perform discrete logs over EC, and a collision attack is found on SHA-3, then an attacker can encapsulate a malicious secret in Kyber, which when hashed with the 3 ECDH values force the session keys for communications with that attacker to be attacker-chosen values.
In the context of Signal, this means that in a case where an attacker would know the session keys anyway (being one of the parties to the handshake), if ECDH and SHA-3 are both broken, then the attacker could force the session keys to values of their choice.
Certainly there would be cases where this could be a problem, but in the case of Signal, the most disastrous attack I can think of would be maybe some kind of backward MitM attack where two users think they're both talking with the attacker, but they're actually talking with each other. C.H.A.O.S. gets the NSA and GCHQ on a chat where they both think they're trying to exploit C.H.A.O.S., and then when they accidentally exploit each other and establish a persistent compromise, C.H.A.O.S. goes in through the backdoors that the NSA and GCHQ have set up, quickly before either the NSA or GCHQ realizes they've exploited the wrong target?
Maybe an attacker colludes with a third party where they arrange encryption keys ahead of time, and then the third party could more easily eavesdrop on communications between the innocent user and the attacker. However, in that case, why doesn't the attacker just leak the session keys to the third party after the fact rather than agreeing beforehand? I could contrive some situation where you've got malware infiltrated into a very locked-down environment where Signal is the only communications channel back out of the environment, preventing two-way communication with the malware, but I feel we're getting pretty far into contrived situations there.
What am I missing? Yes, the proposed key derivation function ads negligible overhead and looks sound. All else being equal, it's strictly better to not allow the attacker to force the session keys to a attacker-determined values if both ECDH and SHA-3 are broken. However, in this context, the risks associated with a larger code change seem to outweigh the risks of an attacker being able to choose session keys, particularly as it seems a security proof of the proposed key derivation function still seems to be a work in progress.
In the context of Signal, this means that in a case where an attacker would know the session keys anyway (being one of the parties to the handshake), if ECDH and SHA-3 are both broken, then the attacker could force the session keys to values of their choice.
Certainly there would be cases where this could be a problem, but in the case of Signal, the most disastrous attack I can think of would be maybe some kind of backward MitM attack where two users think they're both talking with the attacker, but they're actually talking with each other. C.H.A.O.S. gets the NSA and GCHQ on a chat where they both think they're trying to exploit C.H.A.O.S., and then when they accidentally exploit each other and establish a persistent compromise, C.H.A.O.S. goes in through the backdoors that the NSA and GCHQ have set up, quickly before either the NSA or GCHQ realizes they've exploited the wrong target?
Maybe an attacker colludes with a third party where they arrange encryption keys ahead of time, and then the third party could more easily eavesdrop on communications between the innocent user and the attacker. However, in that case, why doesn't the attacker just leak the session keys to the third party after the fact rather than agreeing beforehand? I could contrive some situation where you've got malware infiltrated into a very locked-down environment where Signal is the only communications channel back out of the environment, preventing two-way communication with the malware, but I feel we're getting pretty far into contrived situations there.
What am I missing? Yes, the proposed key derivation function ads negligible overhead and looks sound. All else being equal, it's strictly better to not allow the attacker to force the session keys to a attacker-determined values if both ECDH and SHA-3 are broken. However, in this context, the risks associated with a larger code change seem to outweigh the risks of an attacker being able to choose session keys, particularly as it seems a security proof of the proposed key derivation function still seems to be a work in progress.