public static byte[] ecdh(XECPrivateKey privateKey, XECPublicKey publicKey) {
        try {
            var keyAgreement = KeyAgreement.getInstance("XDH");
            keyAgreement.init(privateKey);
            keyAgreement.doPhase(publicKey, true);
            byte[] sharedSecret = keyAgreement.generateSecret();
            // RFC 7748 recommends checking that the shared secret is not all zero bytes.
            // Furthermore, RFC 9180 states "For X25519 and X448, public keys and Diffie-Hellman
            // outputs MUST be validated as described in [RFC7748]".
            // Usually we won't get here at all since Java will throw an InvalidKeyException
            // from detecting a key with a low order point. But in case we _do_ get here, fail fast.
            if (SideChannelSafe.allZeros(sharedSecret)) {
                throw new IllegalArgumentException("Computed shared secret is all zeroes");
            }
            return sharedSecret;
        } catch (NoSuchAlgorithmException | InvalidKeyException e) {
            throw new RuntimeException(e);
        }
    }
Computes a shared secret using the Elliptic Curve Diffie-Hellman (ECDH) protocol for X25519 curves.
<p>
Let Bob have private (secret) key <code>skB</code> and public key <code>pkB</code>.
Let Alice have private key <code>skA</code> and public key <code>pkA</code>.
ECDH lets both parties separately compute their own side of:
</p>
<pre>
  ecdh(skB, pkA) == ecdh(skA, pkB)
</pre>
<p>
This arrives at the same shared secret without needing to know the secret key of
the other party, but both parties must know their own secret to derive the correct
shared secret. Third party Eve sneaking around in the bushes cannot compute the
shared secret without knowing at least one of the secrets.
</p>
<p>
Performs RFC 7748-recommended (and RFC 9180-mandated) check for "non-contributory"
private keys by checking if the resulting shared secret comprises all zero bytes.
</p>

@param privateKey X25519 private key
@param publicKey X25519 public key
@return shared Diffie-Hellman secret. Security note: this value should never be
        used <em>directly</em> as a key; use a key derivation function (KDF).

@see <a href="https://www.rfc-editor.org/rfc/rfc7748">RFC 7748 Elliptic Curves for Security</a>
@see <a href="https://www.rfc-editor.org/rfc/rfc9180.html">RFC 9180 Hybrid Public Key Encryption</a>
@see <a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH on wiki</a>
security-utils/src/main/java/com/yahoo/security/KeyUtils.java