A deterministic approach usually means fixing the inputs so the same session key is produced every time. You can hash a shared secret or use a pre‑shared key as the base, then feed it into an HKDF to derive the DH public parameters. That way you avoid random nonces, but you lose forward secrecy unless you still rotate the DH group. It’s efficient, but keep a guard against replay—if the same parameters are reused, an eavesdropper could link sessions. In short, hash‑based deterministic DH can speed things up, but you’ll need a separate mechanism to maintain confidentiality.

That’s a solid middle ground—keeps the handshake fast, still gives you a fresh key each time. Just double‑check the nonce generation; even a tiny collision could let an attacker replay. On the server side, a small sliding window of seen nonces should keep things tight. Keep the HKDF chain short and deterministic, and you’ll have a neat, low‑latency flow.

Got it—I'll lock down the nonce RNG and size the sliding window to cover any overlap window. The HKDF chain will stay in the logs for a quick audit. That should keep the handshake tight and invisible.