Use case: We need to establish a long-lived key. In this phase, it is unlikely attacker will either sniff or the modify communication, but we want to cover even this case. So we use Diffie-Hellman or ECDH with some kind of authentication (in order to prevent MITM) for the initial key exchange. We can also assume that both parties don't reuse their DH keypairs. So far, pretty standard situation.

Now, let's assume that RNG of one peer is seriously flawed and attacker can guess (EC)DH private key of this peer. The other peer has unbreakable RNG. My intuition is this in not any worse than simple TOFU (Trust On First Use) key exchange where the party with a high-quality RNG generates the secret and transfers it in plain, hoping there is no attacker in the initial phase. (If we aren't confident about either party's RNG, we could xor random values provided by both parties.)

Note that a flawed RNG does not imply a complete failure. Consider a RNG that is OK for generating unique values (so nonces for encryption are good enough for some modes), but they can be predictable. For sake of simplicity, let's assume attacker can simply learn the key with 100% probability and full accuracy.

In other words, you can imagine a scenario: You have missed the initial (EC)DH key exchange, so you can neither read it nor influence it. You can capture and intercept any subsequent communication, which is encrypted and authenticated using the key exchanged in the handshake you have missed. You have an oracle that can give you the private key used by one party in the initial (EC)DH key exchange. Your task is to learn something about the key or the communication itself. Anything you can learn without knowledge of the oracle is not considered as a gain.

My reasoning about its security is pretty simple:

  1. When the attacker has captured the initial phase, we are flawed in either case, so flawed DH is not worse than TOFU.
  2. When the attacker does not have captured the initial phase, we are pretty secure in case of TOFU. In case of Diffie-Hellman, attacker might have the group, one party's private key (as one peer has a flawed RNG), but she doesn't have other party's public key, as it was present just in initial handshake. Without this, attacker should be unable to learn anything about the secret.

My intuition might be right, but it is far from a proof. Is there any proof of this?

Theoretically, if my intuition above is wrong, both parties can generate random nonces and xor both nonces with the secret. As at least one nonce is unknown for attacker that doesn't know the initial handshake, so the resulting secret is secure in the same way as with TOFU. This is something I can prove to be secure at least as TOFU even in case of flawed RNG on one peer, but it is also some non-standard (and probably unnecessary) addition to DH that requires collecting some additional entropy.


1 Answer 1


There are a few things missing from this question.

First of all, TOFU (trust-on-first-use) is not a scheme and cannot therefore be compared with DH. TOFU is more a property of a protocol than anything else.

Second, you say you would use "some kind of authentication". This is what TOFU "solves", establishing trust without which it is impossible to authenticate. You cannot just skip over that part of the protocol if you want to compare schemes.

Third, I don't see any comparison between active attacks and passive attacks. If an attacker can create the private key then passive (eavesdropping) attacks would be possible. It is not clear if passive attacks are possible for TOFU as it is not a protocol or scheme in itself. That said, I think it is tricky to think of a scheme where a broken RNG isn't an issue in itself.

Finally, for your own scheme you say that you "generate random nonces" but it is unclear how these nonces are shared or what they would add if they would be shared publicly.

  • $\begingroup$ This is not a direct answer, but given the question there is at least not much more that I can do. $\endgroup$
    – Maarten Bodewes
    Jun 11, 2017 at 12:53
  • $\begingroup$ I agree TOFU is vague, but I explain it as transferring the secret in plaintext, so I mean the dumbest TOFU implementation. The authentication is not the part you can attack in the scenario, as it is some communication that has happened in the past. Maybe my edit with paragraph “In other words…” and the preceding paragraph about RNG will make it more clear. $\endgroup$
    – v6ak
    Jun 12, 2017 at 21:29
  • $\begingroup$ Note that I assume just the (EC)DH private key is leaked to the attacker, not any encryption key. I don't see how can one passively eavesdrop the communication without knowledge of the corresponding public key, which is never reused. $\endgroup$
    – v6ak
    Jun 12, 2017 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.