> Aztec.nr API reference, v6.0.0 (mainnet and testnet). Index: https://docs.aztec.network/aztec-nr-api/v6.0.0/llms.txt

# Function get_shared_secrets

Module: `noir_aztec::oracle::shared_secret`

```rust
pub unconstrained fn get_shared_secrets(
    address: AztecAddress,
    eph_pks: EphemeralArray<EmbeddedCurvePoint>,
    contract_address: AztecAddress,
) -> EphemeralArray<Field>
```

Returns app-siloed shared secrets between `address` and someone who knows the secret keys behind the given ephemeral public keys.

Each returned Field `s_app` is computed as:

```text
S     = address_secret * ephPk          (raw ECDH point)
s_app = h(DOM_SEP, S.x, S.y, contract)  (app-siloed scalar)
```

where `contract` is the address of the calling contract. The oracle host validates this matches its execution context.

Without app-siloing, a malicious contract could call this oracle with public information (address, ephPk) and obtain the same raw secret as the legitimate contract, enabling cross-contract decryption. By including the contract address in the hash, each contract receives a different `s_app`, preventing this attack.

Callers derive indexed subkeys from `s_app` via `derive_shared_secret_subkey`.

Returns an empty array when the PXE does not hold `address`'s keys and therefore cannot derive any secrets. This happens when syncing the scope of an address the PXE does not control, and is an expected outcome rather than an error. Any other response length mismatch is a malformed oracle response.