feat(discovery): secret zeroization, request limits, error sanitization

[m-kus]

Implement SecretFelt for Sensitive Key Management

This PR enhances security by implementing proper handling of sensitive cryptographic material throughout the discovery service:

• Adds SecretFelt wrapper for sensitive keys with:

  • Automatic zeroization on drop (via zeroize crate)
  • Debug redaction ([REDACTED] instead of key values)
  • No Copy trait to prevent accidental duplication
  • Controlled serialization/deserialization

• Applies SecretFelt to all sensitive keys:

  • viewing_key in API requests
  • channel_key in cursors and channel objects
  • All key parameters in crypto primitives

• Improves error sanitization:

  • Decryption errors no longer leak channel indices or internal details
  • RPC/storage errors are logged server-side but not forwarded to clients

• Adds HTTP-level protections:

  • Request body size limit (default 100KB)
  • Request timeout (default 30s)
  • Server budget minimum enforcement (MIN_SERVER_BUDGET = 3)

• Updates security documentation to reflect implemented mitigations

This change is

[m-kus]

• feat(discovery-service): add optional tls termination #511
• feat(discovery): secret zeroization, request limits, error sanitization #510 👈 (View in Graphite)
• fix(discovery-core): handle note probing gap #554
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Yoni-Starkware]

@Yoni-Starkware reviewed 3 files and all commit messages, and made 2 comments.
Reviewable status: 3 of 43 files reviewed, 2 unresolved discussions (waiting on m-kus).

---

crates/discovery-core/src/test_fixtures.rs line 73 at r2 (raw file):

    pub auditor_public_key: Felt,
    pub user_addr: Felt,
    pub user_private_key: Felt,

Anything else that should be marked as secret?

Code quote:

    pub auditor_private_key: Felt,
    pub auditor_public_key: Felt,
    pub user_addr: Felt,
    pub user_private_key: Felt,

---

crates/discovery-core/src/privacy_pool/types.rs line 79 at r2 (raw file):

        Felt::deserialize(d).map(SecretFelt::new)
    }
}

Why in a separate mod?

Code quote:

pub mod secret_felt_serde {
    use super::*;
    use serde::{Deserializer, Serializer};

    pub fn serialize<S>(secret: &SecretFelt, s: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        Felt::serialize(&secret.0, s)
    }

    pub fn deserialize<'de, D>(d: D) -> Result<SecretFelt, D::Error>
    where
        D: Deserializer<'de>,
    {
        Felt::deserialize(d).map(SecretFelt::new)
    }
}

[Yoni-Starkware]

@Yoni-Starkware made 1 comment.
Reviewable status: 3 of 43 files reviewed, 2 unresolved discussions (waiting on m-kus).

---

crates/discovery-core/src/privacy_pool/types.rs line 79 at r2 (raw file):

Previously, Yoni-Starkware (Yoni) wrote…

Why in a separate mod?

I.e., why not make these the default serde for SecretFelt?

[m-kus]

@m-kus made 2 comments.
Reviewable status: 3 of 43 files reviewed, 2 unresolved discussions (waiting on Yoni-Starkware).

---

crates/discovery-core/src/test_fixtures.rs line 73 at r2 (raw file):

Previously, Yoni-Starkware (Yoni) wrote…

Anything else that should be marked as secret?

These are for tests anyways, I just made secret the ones we need - to reduce the casting boilerplate

---

crates/discovery-core/src/privacy_pool/types.rs line 79 at r2 (raw file):

Previously, Yoni-Starkware (Yoni) wrote…

I.e., why not make these the default serde for SecretFelt?

To avoid unintentional serialization

[Yoni-Starkware]

@Yoni-Starkware reviewed 2 files, made 1 comment, and resolved 1 discussion.
Reviewable status: 5 of 43 files reviewed, 2 unresolved discussions (waiting on m-kus).

---

crates/discovery-core/src/discovery/cursor.rs line 82 at r2 (raw file):

pub struct ChannelCursor {
    // TODO: Consider encrypting/masking channel_key in the serialized cursor
    // to avoid exposing it in plaintext (sensitive value).

The channel key is still exposed in the serialized cursor, right? Was this your intention? It doesn't seem so

Code quote:

    // TODO: Consider encrypting/masking channel_key in the serialized cursor
    // to avoid exposing it in plaintext (sensitive value).

[m-kus]

@m-kus made 1 comment.
Reviewable status: 4 of 46 files reviewed, 2 unresolved discussions (waiting on Yoni-Starkware).

---

crates/discovery-core/src/discovery/cursor.rs line 82 at r2 (raw file):

Previously, Yoni-Starkware (Yoni) wrote…

The channel key is still exposed in the serialized cursor, right? Was this your intention? It doesn't seem so

Resolved (likely rebasing artifact)

[Yoni-Starkware]

@Yoni-Starkware made 1 comment and resolved 1 discussion.
Reviewable status: 4 of 46 files reviewed, 1 unresolved discussion (waiting on m-kus).

---

crates/discovery-core/src/discovery/cursor.rs line 82 at r2 (raw file):

Previously, m-kus (Michael Zaikin) wrote…

Resolved (likely rebasing artifact)

No, I mean that the serde of channel_key looks like a normal Felt serde, while your TODO says that you want to mask it in the serialized cursor.

[m-kus]

@m-kus made 1 comment.
Reviewable status: 4 of 46 files reviewed, 1 unresolved discussion (waiting on m-kus and Yoni-Starkware).

---

crates/discovery-core/src/discovery/cursor.rs line 82 at r2 (raw file):

Previously, Yoni-Starkware (Yoni) wrote…

No, I mean that the serde of channel_key looks like a normal Felt serde, while your TODO says that you want to mask it in the serialized cursor.

Ah got it, yeah that's the intention - use secretfelt for sensitive keys, not adding additional app-level encryption (rely on tls)

[Yoni-Starkware]

@Yoni-Starkware partially reviewed 42 files and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on m-kus).