buzz/crypto.md

# Buzz Cryptography And Key Review

Reviewed against the current checkout on 2026-06-25.

## Executive Summary

Buzz uses familiar primitives: BIP-340 Schnorr signatures over secp256k1 for
Nostr events, SHA-256 for event IDs and payload hashes, HMAC-SHA256 and
HKDF-SHA256 for keyed derivations, NIP-44 v2 for encrypted Nostr payloads, and
random bearer tokens for a smaller set of HTTP and workflow flows. I did not
find evidence that the project chose a broken primitive or implemented an
obviously broken signature scheme.

The problems are mostly at the composition and lifecycle layer. The highest
risk issue is that the mobile NIP-AB pairing target decrypts, deserializes, and
retains payload plaintext before the target user confirms the SAS, even though
the protocol explicitly makes that confirmation a local confidentiality
boundary. The second high-risk issue is that relay admission verifies NIP-OA
delegation signatures but does not enforce signed time conditions, while the
desktop currently mints managed-agent credentials with no expiry at all. That
turns a delegation credential into a durable bearer capability once the key and
tag are copied.

The remaining issues are narrower but real: Git Smart HTTP intentionally turns
NIP-98 into a short-lived repo-scoped bearer credential; generic NIP-98 body
binding is optional even on JSON POST routes; the managed-agent key store does
not enforce owner-only file permissions the way the human desktop key store
does; mobile pairing cleanup leaves ephemeral secret material referenced after
completion; the audit documentation claims HMAC-backed tamper evidence while
the implementation is only an unkeyed hash chain; and the mobile hand-written
NIP-44 parser accepts non-canonical padding.

This report does not count intended local agent authority as a cryptographic
finding. If a user deliberately runs an agent with shell and file access on
their machine, that agent is inside that machine's trust boundary. The crypto
question is whether keys and credentials have the properties the product and
protocols claim once they cross a boundary.

## Severity Model

- Critical: direct key recovery, signature forgery, or broad impersonation
  across an expected trust boundary with little precondition.
- High: an explicit cryptographic protocol guarantee is broken, or a credential
  intended to be bounded becomes materially more durable or replayable.
- Medium: a real composition, replay, or key-custody weakness that lowers a
  claimed guarantee but needs a narrower precondition.
- Low: parser strictness, defense-in-depth, or test coverage gaps that are worth
  fixing before they become interoperability or maintenance problems.

No Critical findings were identified in the reviewed code.

## Findings

### High

#### C-01. Mobile pairing deserializes and retains payload plaintext before dual consent

**Severity:** High

NIP-AB makes the target user's SAS confirmation a local confidentiality
boundary. The protocol allows the target to decrypt early only as much as is
necessary to classify a message type. It explicitly says the target must not
deserialize, extract, log, persist, or act on the `payload` field before the
transcript is verified and the target user approves the SAS; the safest behavior
is to buffer raw ciphertext until then. See
`crates/buzz-core/src/pairing/NIP-AB.md:316-318` and
`crates/buzz-core/src/pairing/NIP-AB.md:645-649`.

The mobile implementation does more than that. It decrypts and `jsonDecode`s
incoming pairing messages immediately in
`mobile/lib/features/pairing/pairing_provider.dart:276-333`. When the message
type is `payload`, it stores the full plaintext `Map<String, dynamic>` in
`_pendingPayload` before the user confirms the SAS in
`mobile/lib/features/pairing/pairing_provider.dart:380-389`. The actual `nsec`
is extracted later in `mobile/lib/features/pairing/pairing_provider.dart:416-456`,
but the sensitive plaintext is already resident in application memory and
available to any bug, instrumentation, crash capture, or future code path that
touches `_pendingPayload`.

The Rust reference state machine preserves the intended property. It moves the
target into `AwaitingConfirmation`, requires `confirm_target_sas()` before
`handle_payload()`, returns the secret in a `Zeroizing<String>`, and zeroizes
session material on drop. See `crates/buzz-core/src/pairing/session.rs:329-415`
and `crates/buzz-core/src/pairing/session.rs:740-750`.

This is not a theoretical nicety. The protocol is designed so that a target
device can receive an encrypted payload before the human has accepted the
channel, while still withholding the secret from the local application until
that final approval. The mobile code removes that distinction.

Recommended change: keep the incoming payload event or ciphertext opaque until
`confirmSas()` succeeds, then decrypt and deserialize exactly once. If early
message classification is unavoidable, parse only enough to distinguish
`payload` from other message types and do not retain any decoded payload fields.
Use mutable byte buffers for secret plaintext where practical so cleanup can do
more than drop references.

#### C-02. Relay admission drops signed NIP-OA time bounds and managed agents mint non-expiring delegation credentials

**Severity:** High

NIP-OA auth tags are signed delegation credentials. The SDK verifies the tag
signature and returns the owner pubkey, but it only syntax-checks conditions; it
does not evaluate them. See `crates/buzz-sdk/src/nip_oa.rs:33-109` and
`crates/buzz-sdk/src/nip_oa.rs:139-239`. The NIP-OA documentation is clear that
empty conditions impose no constraints and that verifiers must evaluate every
condition. See `docs/nips/NIP-OA.md:13-17`, `docs/nips/NIP-OA.md:43-71`, and
`docs/nips/NIP-OA.md:93-103`.

The relay admission path treats a valid auth tag signature plus owner
membership as sufficient delegated membership. It does not evaluate
`created_at<` or `created_at>` conditions when resolving the effective member
for NIP-42 authentication. See `crates/buzz-relay/src/api/mod.rs:54-158` and
`crates/buzz-relay/src/handlers/auth.rs:68-223`. NIP-AA requires those time
conditions to be evaluated during AUTH admission, in addition to the normal
NIP-42 freshness check. See `docs/nips/NIP-AA.md:71-125` and
`docs/nips/NIP-AA.md:143-167`.

There is one path that does enforce time conditions: the NIP-IA request-borne
identity archive path in `crates/buzz-relay/src/handlers/identity_archive.rs:245-347`.
Git signing also evaluates NIP-OA conditions against its signed envelope
timestamp in `crates/git-sign-nostr/src/lib.rs:600-629`,
`crates/git-sign-nostr/src/lib.rs:1034-1068`, and
`crates/git-sign-nostr/src/lib.rs:1264-1356`. That makes the relay admission
gap look like an omitted semantic check, not a deliberate protocol-wide rule.

The current desktop issuance path makes the problem worse by generating managed
agent auth tags with an empty condition string in
`desktop/src-tauri/src/commands/agents.rs:407-420`. Deleting the local agent
record only stops the process and removes local state; it does not revoke a
credential that has already been copied elsewhere. See
`desktop/src-tauri/src/commands/agents.rs:1045-1097`.
`crates/buzz-db/src/archived_identities.rs:1-6` also states that archive state
is a relay-local UI visibility hint, not an authorization revocation mechanism.

The result is that a copied managed-agent private key plus auth tag remains
usable as long as the owner remains a relay member, even if a future caller
believes it issued a time-bounded tag. `kind=` conditions are intentionally not
admission restrictions under NIP-AA, so the missing property is specifically
time-bound admission and credential retirement, not generic event-kind
restriction.

Recommended change: add a single NIP-AA admission verifier that accepts the
AUTH event timestamp and evaluates all admission-relevant NIP-OA conditions
after NIP-42 freshness verification. Make every relay admission caller use it.
Issue managed-agent credentials with an explicit short lifetime or add an
independent relay-side revocation/rotation mechanism keyed by the delegated
agent identity. Deleting or retiring an agent should revoke future admission,
not just remove the desktop process record.

### Medium

#### C-03. Git Smart HTTP uses NIP-98 as a replayable repo-scoped bearer credential

**Severity:** Medium

The Git Smart HTTP path intentionally relaxes NIP-98 request binding so that one
credential works across the multiple HTTP requests Git emits for a repository.
The relay strips a request down to the repo root URL, does not bind the
credential to the actual HTTP method, passes `body=None`, and intentionally
does not deduplicate event IDs. See
`crates/buzz-relay/src/api/git/transport.rs:111-175`. The credential helper
matches that behavior by minting a repo-root auth event in
`crates/git-credential-nostr/src/lib.rs:182-231`.

This means a captured credential is a short-lived bearer token for the same
repository, not a proof for one exact request. Within the verifier freshness
window, the holder can replay it against clone, fetch, or push endpoints for
that repository, subject to the original account's repo authorization and the
pre-receive push policy. The code comments acknowledge the need for this
tradeoff, but the actual scope is broader than an operation-specific signature.

This is not a broken signature scheme. It is a deliberate reduction from
"signed request" to "signed short-lived repo session". That can be a reasonable
engineering choice, but it should be treated and documented as a bearer
credential because its compromise behavior is different.

Recommended change: either document the Git token as an explicit short-lived
repo-scoped bearer credential, or add a protocol layer that binds the
credential to a smaller session scope and operation set. If the current design
remains, avoid describing it as method or service bound when the verifier
actually accepts the repo-root token across multiple Git endpoints.

#### C-04. Bridge NIP-98 body integrity is optional on body-carrying JSON routes

**Severity:** Medium

The generic NIP-98 verifier checks a SHA-256 payload tag only when both a
`payload` tag and a request body are present. A body-bearing request with no
`payload` tag is accepted. See `crates/buzz-auth/src/nip98.rs:34-130`; the test
that codifies this behavior is `crates/buzz-auth/src/nip98.rs:267-273`.

The HTTP bridge routes for `/events`, `/query`, and `/count` all pass request
bodies through this verifier and use a replay cache. See
`crates/buzz-relay/src/api/bridge.rs:23-105`,
`crates/buzz-relay/src/api/bridge.rs:167-234`,
`crates/buzz-relay/src/api/bridge.rs:241-325`, and
`crates/buzz-relay/src/api/bridge.rs:497-615`. First-party desktop, ACP, and
CLI callers do the stronger thing and include both a payload hash and a nonce.
See `desktop/src-tauri/src/relay.rs:94-136`,
`crates/buzz-acp/src/relay.rs:202-248`,
`crates/buzz-acp/src/relay.rs:311-336`, and
`crates/buzz-cli/src/client.rs:85-117`.

The replay cache limits repeated use, but it cannot make the first accepted body
be the body the signer intended if the auth event itself does not commit to a
payload hash. A captured no-payload auth event can be paired with a different
body before the intended request wins the race. The Git path needs weaker body
binding for streaming protocol reasons; JSON bridge routes do not.

Recommended change: split NIP-98 verification into explicit modes. Require a
`payload` tag for non-streaming body-carrying routes such as `/events`,
`/query`, and `/count`, and keep the Git exception local to the Git transport
code rather than making optional body integrity the generic verifier default.

#### C-05. Managed-agent key store does not enforce owner-only file permissions

**Severity:** Medium

Managed agent records contain the raw agent `nsec` and auth tag in plaintext.
See `desktop/src-tauri/src/managed_agents/types.rs:85-99` and
`desktop/src-tauri/src/commands/agents.rs:377-385`,
`desktop/src-tauri/src/commands/agents.rs:516-522`. The store writes JSON with
`std::fs::write` followed by rename in
`desktop/src-tauri/src/managed_agents/storage.rs:11-70`; it does not explicitly
set or validate owner-only permissions.

The desktop human identity store is stricter. It uses an atomic write path and
sets Unix mode `0600` for the key file in
`desktop/src-tauri/src/app_state.rs:127-234`. The managed-agent store therefore
has a weaker custody guarantee for credentials that are still capable of relay
admission and event signing.

Actual exposure depends on the app data directory mode and the user's umask, so
this is not a claim that every install is immediately world-readable. The
problem is that the code does not enforce the property at the file that matters.

Recommended change: give the managed-agent store the same atomic owner-only
write and load-time permission validation used for the desktop human key. For
longer-lived deployments, consider moving both human and agent private keys
into an OS key store rather than relying only on plaintext files protected by
filesystem ACLs.

#### C-06. Mobile pairing cleanup leaves ephemeral secret material live after completion and abort

**Severity:** Medium

The NIP-AB specification requires ephemeral private keys, the session secret,
and decrypted plaintext to be zeroed after completion, abort, or timeout. See
`crates/buzz-core/src/pairing/NIP-AB.md:389` and
`crates/buzz-core/src/pairing/NIP-AB.md:555-562`. The Rust implementation does
that for its session and QR objects in `crates/buzz-core/src/pairing/session.rs:740-750`
and `crates/buzz-core/src/pairing/qr.rs:34-57`.

The mobile provider's `_cleanup()` only cancels timers and subscriptions,
clears status flags, and drops `_pendingPayload`. It leaves
`_ephemeralPrivkey`, `_ephemeralPubkey`, `_sessionSecret`, `_sourcePubkey`,
`_sessionId`, `_sasInput`, and `_conversationKey` referenced on the notifier.
See `mobile/lib/features/pairing/pairing_provider.dart:119-143`.

Dart strings and ordinary immutable objects are not ideal secret containers, so
true zeroization may require a different representation. Even then, the current
code can at least shorten lifetime by clearing references and avoiding plaintext
objects that survive past the session state machine.

Recommended change: clear every session secret field on all terminal paths and
move secret-bearing values toward mutable byte buffers or platform-backed
containers that can be overwritten before release. Pair this with tests that
assert terminal transitions drop all retained secret state.

#### C-07. Audit documentation claims HMAC-backed tamper evidence but implementation is an unkeyed hash chain

**Severity:** Medium

`SECURITY.md:67-72` describes the audit log as HMAC chained and suitable for
strong tamper evidence. The implementation computes a plain SHA-256 digest over
the entry fields plus the previous hash in `crates/buzz-audit/src/hash.rs:1-77`.
`crates/buzz-audit/src/service.rs:19-193` serializes writes and verifies the
stored chain, but there is no secret key and no external anchor.

An unkeyed hash chain detects accidental corruption and some incomplete edits.
It does not stop an attacker with write access to the audit table from
rewriting a suffix, recomputing every following hash, and leaving a
self-consistent chain. A keyed MAC would raise the bar for a database-only
attacker if the MAC key lived outside the database. An external signed anchor
or append-only transparency system would be needed for stronger guarantees
against a compromised relay host.

Recommended change: either narrow the documentation to the actual property, or
implement a keyed chain with the key stored outside Postgres and anchor chain
heads externally. The threat model should say whether the intended adversary is
accidental corruption, database-only compromise, or relay-host compromise.

### Low

#### C-08. Mobile NIP-44 accepts non-canonical padding and lacks direct vector coverage

**Severity:** Low

The mobile client carries a hand-written NIP-44 v2 implementation in
`mobile/lib/shared/crypto/nip44.dart:12-176`. Its `_unpad()` routine checks that
the declared length is non-zero and fits within the decrypted buffer, but it
does not verify that the total padded length matches the canonical NIP-44
padding calculation or that trailing padding bytes are zero. See
`mobile/lib/shared/crypto/nip44.dart:127-134`.

Because the ciphertext is MAC authenticated, this is not a practical plaintext
forgery or key-recovery issue by itself. It is a parser strictness divergence:
the mobile client can accept authenticated plaintext encodings that stricter
implementations would reject. That creates avoidable cross-language behavior
differences in the code that carries identity-transfer secrets.

The current mobile tests exercise pairing behavior, but I did not find direct
official NIP-44 cross-language vector coverage for this implementation. Pairing
tests live in `mobile/test/features/pairing/pairing_provider_test.dart`; the
only direct NIP-44 use found in tests was
`mobile/test/features/channels/agent_activity/observer_subscription_test.dart`.

Recommended change: enforce canonical padding in `_unpad()` and add official
NIP-44 v2 vectors plus Rust-to-Dart interoperability cases for encryption,
decryption, padding boundaries, and malformed authenticated payloads.

## Primitive Inventory

| Primitive | Where It Is Used | Assessment |
| --- | --- | --- |
| BIP-340 Schnorr over secp256k1 | Nostr event signatures, relay-signed events, Git NIP-GS envelopes, pairing ephemeral events | Appropriate primitive. The main risk is private-key custody and semantic verification around the signed object, not signature forgery. |
| SHA-256 | Nostr event IDs, NIP-98 payload hashes, media content hashes, approval/API token hashing, audit chain, Git object and envelope hashing | Appropriate hash. Its use in the audit chain is not a substitute for a keyed MAC or external anchor. |
| HMAC-SHA256 | NIP-44 authentication, NIP-AB derivations via HKDF, Git hook authentication, engram opaque tags, proxy shadow-key derivation | Appropriate when the key is well protected and domain separation is explicit. The Git hook and engram uses are among the better composed parts of the codebase. |
| HKDF-SHA256 | NIP-44 and NIP-AB key derivation | Appropriate. Pairing derivations are domain separated and reviewed below. |
| ChaCha20 in NIP-44 v2 | Encrypted Nostr application payloads, pairing, reminders, observers, read state, engrams | Appropriate as part of the NIP-44 v2 construction. The significant question is when plaintext is exposed and what metadata remains public. |
| UUID v4 bearer values | Workflow webhooks, workflow approvals, proxy invites, some API-facing tokens | Roughly 122 random bits after UUID version and variant bits, which is adequate against guessing. These values are bearer secrets and need short lifetime, hashing where possible, and careful transport. |
| TLS / WSS / HTTPS | Transport confidentiality for normal messages, audio, Git, API tokens, and webhook secrets | External trust boundary, not application-layer cryptography. Ordinary channel messages and huddle audio rely on relay and transport confidentiality unless separately wrapped in NIP-44. |

Encoding mechanisms such as bech32, hex, base64, and JSON canonicalization are
not cryptographic protections by themselves. Their security relevance here is
whether they preserve an unambiguous signed or MACed representation.

## Key And Secret Inventory

| Material | Generation And Storage | Used For | Review Notes |
| --- | --- | --- | --- |
| Desktop human Nostr private key | Created and stored by `desktop/src-tauri/src/app_state.rs:127-234` in an atomic `0600` file | User event signing, NIP-42, NIP-98, NIP-44, pairing source payload | Plaintext at rest behind OS file permissions. Better hardened than the managed-agent store. |
| Mobile human Nostr private key | Stored inside workspace JSON through `FlutterSecureStorage` in `mobile/lib/shared/workspace/workspace_storage.dart:1-95`, `mobile/lib/shared/workspace/workspace.dart:6-71`, and `mobile/lib/shared/auth/auth_provider.dart:16-134` | User event signing, NIP-42, self-encryption, imported pairing identity | Better at-rest posture than a plain file, but runtime code necessarily handles plaintext key material. |
| Managed-agent private key | Freshly generated in `desktop/src-tauri/src/commands/agents.rs:377-385`, stored in agent JSON record at `desktop/src-tauri/src/managed_agents/types.rs:85-99`, injected into child env by `desktop/src-tauri/src/managed_agents/runtime.rs:1549-1561` | Agent Nostr identity, relay auth, event signing | Durable local credential. Store permissions are not explicitly hardened; copied key plus auth tag remains powerful. |
| NIP-OA auth tag | Signed by owner in `desktop/src-tauri/src/commands/agents.rs:407-420`; passed to agents in `desktop/src-tauri/src/managed_agents/runtime.rs:1648-1656` | Delegated owner context for relay membership and agent attribution | Signature is verified, but relay admission does not enforce time conditions. Current desktop issuance uses empty conditions. |
| Relay Nostr private key | Loaded or derived during startup in `crates/buzz-relay/src/main.rs:83-105` and `crates/buzz-relay/src/main.rs:204-225` | Relay identity, NIP-11 identity, relay-signed state and lifecycle events | Production membership mode needs a stable key. Development fallback is deterministic scalar-1, which is suitable only for local development. |
| NIP-44 conversation keys | Derived per sender/recipient pair by Rust `nostr` code and by mobile `mobile/lib/shared/crypto/nip44.dart:12-176` | Engrams, observer frames, reminders, read state, pairing payloads | Content confidentiality only. Tags, timing, sender/recipient relationships, and other public metadata remain visible. |
| NIP-AB ephemeral private keys and session secret | Generated for each pairing session in `crates/buzz-core/src/pairing/session.rs:84-109` and QR handling in `crates/buzz-core/src/pairing/qr.rs:34-57`; mobile keeps equivalents in `mobile/lib/features/pairing/pairing_provider.dart:132-143` | ECDH, SAS derivation, one-time identity transfer | Rust zeroizes on drop. Mobile currently retains references after cleanup and exposes payload plaintext too early. |
| Git hook HMAC secret | Loaded or generated by relay config in `crates/buzz-relay/src/config.rs:320-350` | Authenticate relay-to-hook push policy context | Canonical length-prefixed HMAC construction is sound. Configured minimum is 32 hex characters, which is 16 bytes and still adequate, though wording should be precise. |
| Workflow webhook secret | UUID v4 bearer generated in `crates/buzz-relay/src/webhook_secret.rs:22-90` | Invoke workflow webhook endpoint | Stored as a bearer secret in workflow state, stripped from responses, constant-time compared. Query-string transport in `crates/buzz-relay/src/api/bridge.rs:831-973` can leak through logs and referrers more easily than header transport. |
| Workflow approval token | UUID v4 raw token generated in `crates/buzz-workflow/src/executor.rs:714-721`, SHA-256 hash stored via `crates/buzz-db/src/workflow.rs:27-33` and `crates/buzz-db/src/workflow.rs:605-755` | Approve one pending workflow step | Good pattern: raw value is not stored and DB update is written to avoid approval races. |
| API token | Hashed and expiry/revocation tracked in `crates/buzz-db/src/api_token.rs:1-290` | Media/API bearer authentication | Better than storing raw bearer values. Actual security depends on issuance, transport, and revocation behavior at callers. |
| Proxy server salt and derived shadow keys | Server salt feeds `HMAC-SHA256(salt, external_pubkey)` in `crates/buzz-proxy/src/shadow_keys.rs:1-117` | Deterministic local shadow identities for NIP-28 compatibility | Salt compromise lets an attacker derive every shadow key for known external pubkeys. Salt rotation changes every shadow identity. |
| Infrastructure secrets | Read from relay config for Postgres, Redis, S3, Typesense, and similar services in `crates/buzz-relay/src/config.rs` | Service authentication | These are ordinary service credentials rather than Nostr keys, but relay compromise exposes them and therefore bypasses many higher-level crypto guarantees. |

## Flow Review

### Nostr Event Signatures And Relay Identity

The event signing core is conventional and easy to reason about. Nostr event IDs
are recomputed and signatures are verified in
`crates/buzz-core/src/verification.rs:8-31`. The relay ingest path rejects
events that do not verify, and ordinary WebSocket event submission also checks
that an event's `pubkey` matches the authenticated connection except for
explicit protocol cases such as gift wraps and proxy behavior. This is the
right base property: if an event is accepted as authored by a Nostr pubkey, the
relay has verified a Schnorr signature for that pubkey.

The relay key itself is more than an implementation detail. It signs
relay-authored state and lifecycle events and becomes the identity clients see
through NIP-11. Membership mode requires a stable relay key in
`crates/buzz-relay/src/main.rs:83-105`. Production token mode also refuses to
start without a configured key, while development mode falls back to a
deterministic scalar-1 key in `crates/buzz-relay/src/main.rs:204-225`.
`crates/buzz-relay/src/nip11.rs:106-171` only advertises a stable relay identity
and NIP-43 capability when the configuration supports it.

The configuration comment in `crates/buzz-relay/src/config.rs:49-51` says an
absent relay key generates a fresh key, but the runtime behavior is now
different: development gets a deterministic key and production panics. That is
not a crypto vulnerability, but stale comments around identity material are a
good way to create operational mistakes.

### NIP-42 WebSocket Authentication

The main relay NIP-42 implementation is one of the stronger auth surfaces. It
generates 32 random challenge bytes, requires an exact challenge match, binds
the AUTH event to the relay URL, verifies signature and kind, and enforces a
freshness window of about 60 seconds. See `crates/buzz-auth/src/nip42.rs:35-85`.
That gives a client proof of key possession and prevents a captured AUTH event
from remaining useful for long.

The proxy NIP-42 implementation is looser. It uses a UUID v4 challenge, accepts
a 10-minute freshness window, and treats relay-tag mismatch as nonfatal in
`crates/buzz-proxy/src/server.rs:173-313`. A UUID v4 challenge still has enough
entropy for guessing resistance, but the proxy has a weaker domain-binding and
replay posture than the primary relay. That may be acceptable for its
compatibility role, but it should be an explicit choice rather than an
accidental divergence.

### NIP-98 HTTP Authentication

The first-party desktop, ACP, and CLI clients generally create well-bound NIP-98
requests: they sign URL, method, a payload hash, and a nonce. See
`desktop/src-tauri/src/relay.rs:94-136`,
`crates/buzz-acp/src/relay.rs:202-248`,
`crates/buzz-acp/src/relay.rs:311-336`, and
`crates/buzz-cli/src/client.rs:85-117`. That is the right shape for JSON API
requests.

The generic verifier is intentionally more permissive because Git Smart HTTP
cannot conveniently sign each streamed body. That exception has leaked into
the default verifier contract: payload binding is optional even when a caller
does have a body. C-04 is the resulting problem. The web helper in
`web/src/shared/lib/nip98.ts:1-33` also omits a payload hash, but the reviewed
use is the Git client in `web/src/features/repos/git-client.ts`, where it fits
the weaker Git path rather than the JSON bridge.

### NIP-OA Delegation And Agent Identity

NIP-OA is a signed capability system layered on top of Nostr identity. The
owner signs an auth tag naming an agent pubkey and conditions. The agent then
proves possession of its own key while presenting the owner's delegation. The
cryptographic binding itself is straightforward: without the owner's
signature, an arbitrary agent cannot claim owner context.

The difficult part is semantic verification. `verify_auth_tag()` in the SDK
answers "did the owner sign this tag for this agent?" It does not answer "is
this credential still valid for this admission at this time?" Several call
sites use it only as an owner-binding primitive, including ACP identity
resolution in `crates/buzz-acp/src/lib.rs:86-112`,
`crates/buzz-acp/src/lib.rs:159-285`, and
`crates/buzz-acp/src/lib.rs:1102-1143`, plus desktop conversion and relay helper
logic in `desktop/src-tauri/src/nostr_convert.rs:60-83` and
`desktop/src-tauri/src/relay.rs:317-380`.

That is fine when the caller only needs attribution. It is not fine for relay
admission, where NIP-AA gives time conditions authorization meaning. The lack
of one centralized semantic verifier is what allowed C-02 to exist. The design
would be easier to audit if the code had separate names for "verify delegation
signature" and "authorize delegated action under conditions".

### NIP-44 Application Encryption

Buzz uses NIP-44 in several places, and the Rust paths are generally careful.
Engrams derive an opaque `d` tag using HMAC with domain separation, encrypt
content with a NIP-44 conversation key, enforce a strict envelope, and rederive
the expected tag after decryption. See `crates/buzz-core/src/engram.rs:1-154`
and `crates/buzz-core/src/engram.rs:436-599`. The relay validates engram
envelopes before allowing replaceable heads to be overwritten in
`crates/buzz-relay/src/handlers/ingest.rs:822-957` and
`crates/buzz-relay/src/handlers/ingest.rs:1474-1477`.

Observer frames use NIP-44 v2 with size bounds and plaintext zeroization in
`crates/buzz-core/src/observer.rs:1-108`. The relay routes only the public
envelope and excludes sensitive kinds from search in
`crates/buzz-relay/src/handlers/event.rs:188-200`,
`crates/buzz-relay/src/handlers/event.rs:314-329`, and
`crates/buzz-relay/src/handlers/event.rs:826-885`.

NIP-ER reminders and NIP-RS read state are intentionally self-encrypted. The
reminder protocol keeps due-time metadata public so the relay can schedule
delivery, while hiding the reminder body. See `docs/nips/NIP-ER.md:9-13`,
`docs/nips/NIP-ER.md:38-40`, `docs/nips/NIP-ER.md:46-77`,
`docs/nips/NIP-ER.md:104-105`, and `docs/nips/NIP-ER.md:135-201`.
Read state uses self-encryption and random slot IDs as described in
`docs/nips/NIP-RS.md:9-17` and `docs/nips/NIP-RS.md:39-109`; mobile applies
that pattern in `mobile/lib/features/channels/read_state/read_state_manager.dart`.

Gift wraps are opaque NIP-17 events whose wrapper author is ephemeral. The relay
therefore cannot require wrapper pubkey to match the authenticated connection in
the normal way. It still p-gates them and excludes them from search. See
`crates/buzz-core/src/kind.rs:59-60`,
`crates/buzz-relay/src/handlers/ingest.rs:1146-1219`,
`crates/buzz-relay/src/handlers/event.rs:188-200`, and
`crates/buzz-relay/src/handlers/event.rs:287-301`.

The common caveat across all NIP-44 use is that content encryption is not
metadata encryption. The relay still sees event kind, timing, size, tags needed
for routing, and often the relationship between sender and recipient. That is
normal for Nostr-style encrypted events, but it matters when evaluating privacy
claims.

### NIP-AB Pairing

The Rust NIP-AB implementation is the strongest cryptographic subsystem in the
repository. It uses fresh ephemeral secp256k1 keypairs, a 32-byte session
secret, HKDF-SHA256 with explicit domain separation, constant-time comparison,
NIP-44 v2 payload encryption, strict state transitions, timeout handling,
recipient `p`-tag validation, duplicate suppression, and zeroization. See
`crates/buzz-core/src/pairing/crypto.rs:1-135`,
`crates/buzz-core/src/pairing/session.rs:84-109`,
`crates/buzz-core/src/pairing/session.rs:113-283`,
`crates/buzz-core/src/pairing/session.rs:288-428`, and
`crates/buzz-core/src/pairing/session.rs:432-750`.

The QR parser validates key and secret lengths, rejects all-zero secret
material, validates relay URLs and versioning, and zeroizes sensitive fields on
drop. See `crates/buzz-core/src/pairing/qr.rs:34-57`,
`crates/buzz-core/src/pairing/qr.rs:83-96`, and
`crates/buzz-core/src/pairing/qr.rs:110-225`. The sidecar pairing relay is
deliberately unauthenticated and history-free, but it validates event
signatures, freshness, deduplication, and bounds while only routing opaque
NIP-44 ciphertext. See `crates/buzz-pair-relay/src/lib.rs:1-27`,
`crates/buzz-pair-relay/src/lib.rs:60-91`, and
`crates/buzz-pair-relay/src/lib.rs:323-591`.

The protocol's hard limit is human SAS comparison. A QR observer can race the
real target, but the user should detect that because the SAS values differ.
That assumption and the 120-second QR exposure window are documented in
`crates/buzz-core/src/pairing/NIP-AB.md:538-605`. The mobile implementation
weakens the local half of that design through C-01 and C-06.

Desktop pairing sends a raw `nsec` inside the encrypted payload in
`desktop/src-tauri/src/commands/pairing.rs:35-60` and
`desktop/src-tauri/src/commands/pairing.rs:79-182`. The NIP permits that, though
it recommends NIP-49 `ncryptsec` for defense in depth in
`crates/buzz-core/src/pairing/NIP-AB.md:338-369`. This is not a finding because
the transport channel is intended to protect the payload, but encrypting the
transferred key at rest before it leaves the source would reduce the impact of
a later target-storage mistake.

### Git Commit Signing And Git Transport

`git-sign-nostr` is unusually careful code. It separates its trust limits in
`crates/git-sign-nostr/src/lib.rs:1-72`, uses `Zeroizing` for key material,
removes key environment variables after loading in
`crates/git-sign-nostr/src/lib.rs:404-464`, and opens key files with
`O_NOFOLLOW`, `O_NONBLOCK`, owner checks, and mode checks in
`crates/git-sign-nostr/src/lib.rs:783-898`. Its NIP-GS hash includes a domain
separator, timestamp, auth-tag binding, and payload in
`crates/git-sign-nostr/src/lib.rs:900-932`; its JSON envelope parser is strict
and canonical in `crates/git-sign-nostr/src/lib.rs:936-958` and
`crates/git-sign-nostr/src/lib.rs:1410-1519`.

The Git signer also separates cryptographic verification from advisory trust
decisions and actually evaluates NIP-OA conditions. See
`crates/git-sign-nostr/src/lib.rs:600-629`,
`crates/git-sign-nostr/src/lib.rs:1034-1080`, and
`crates/git-sign-nostr/src/lib.rs:1264-1356`. That is the right pattern for
delegated signatures.

The credential helper is less hardened around key-file loading. It checks file
metadata and mode but does not use the same anti-symlink and owner-race
protections as the signer. See `crates/git-credential-nostr/src/lib.rs:30-74`.
That is a key hygiene inconsistency, though the more important transport issue
is C-03.

The relay-to-hook push policy authentication is well composed. It uses a
canonical length-prefixed payload, HMAC-SHA256, constant-time verification, and
a 30-second TTL in `crates/buzz-relay/src/api/git/policy.rs:1-235` and
`crates/buzz-relay/src/api/git/policy.rs:386-409`. The shell hook mirrors that
format and fails closed in `crates/buzz-relay/src/api/git/hook.rs:1-176`. The
relay also signs ref-state events in
`crates/buzz-relay/src/api/git/manifest_event.rs:59-117`.

### Media Upload Authentication

The Blossom-style media path is stronger than generic NIP-98 for body integrity.
`crates/buzz-media/src/auth.rs:1-135` verifies signature, kind, verb, expiry,
freshness, server tags, and a mandatory `x` content hash. The upload handlers
compute SHA-256 and verify it after buffering or streaming in
`crates/buzz-media/src/upload.rs:25-115` and
`crates/buzz-media/src/upload.rs:211-404`. The relay API requires
`X-SHA-256`, matches it against the signed `x` tag, enforces token signer-owner
binding, and checks membership in `crates/buzz-relay/src/api/media.rs:27-122`
and `crates/buzz-relay/src/api/media.rs:567-665`.

That is the right model for large uploads: the signed authorization commits to
the content hash, and the receiver recomputes the hash over the bytes actually
stored.

### Bearer Tokens, Webhooks, And Approval Secrets

Not every secret in Buzz is a signing key. Workflow webhook secrets, approval
tokens, API tokens, and proxy invite tokens are bearer credentials. Their
security depends on entropy, transport, storage, and lifetime rather than
signature verification.

Webhook secrets are UUID v4 values, are stripped from normal workflow
responses, and are compared in constant time in
`crates/buzz-relay/src/webhook_secret.rs:22-90`. The endpoint accepts them
either through `X-Webhook-Secret` or a `?secret=` query parameter in
`crates/buzz-relay/src/api/bridge.rs:831-973`. Header transport is materially
better because query strings are more likely to be copied into access logs,
browser history, monitoring traces, and referrer-bearing URLs.

Approval tokens follow a better storage pattern: the executor creates a random
raw value, while the database stores only a SHA-256 hash and consumes it with a
race-safe update. See `crates/buzz-workflow/src/executor.rs:714-721`,
`crates/buzz-db/src/workflow.rs:27-33`, and
`crates/buzz-db/src/workflow.rs:605-755`. API tokens also have hashed storage,
expiry, and revocation fields in `crates/buzz-db/src/api_token.rs:1-290`.

Proxy invite tokens are UUID v4 bearer values stored raw in memory and consumed
by lookup in `crates/buzz-proxy/src/invite.rs:8-60`,
`crates/buzz-proxy/src/invite_store.rs:10-70`, and
`crates/buzz-proxy/src/server.rs:807-910`. That is adequate for short-lived
in-memory invites, but they should be treated as secrets in logs and metrics.

### Proxy Shadow Keys

The proxy deterministically derives a local shadow identity from an external
pubkey using `HMAC-SHA256(server_salt, external_pubkey_bytes)` in
`crates/buzz-proxy/src/shadow_keys.rs:1-117`. This is a reasonable deterministic
derivation if the salt is high entropy and remains secret. It also creates a
single high-value secret: anyone who gets the salt can derive every shadow
private key for every known external pubkey. Salt rotation changes every
derived identity, so rotation is operationally expensive.

That construction is not inherently wrong, but the salt should be handled like
a master key, not like a casual configuration value.

### Audit Chain

The audit chain is useful for detecting accidental breaks and some partial
tampering, but it is not cryptographically equivalent to a keyed append-only
log. C-07 covers the mismatch between documentation and implementation. The
important design question is who the audit system is intended to detect:
application bugs, database-only attackers, or a compromised relay operator.
Those are different threat models and require different cryptographic anchors.

### Huddle Audio

Huddle audio is not application-layer encrypted. The relay receives and forwards
audio frames whose body is treated as opaque Opus data in
`crates/buzz-relay/src/audio/mod.rs:1-10` and
`crates/buzz-relay/src/audio/wire.rs:1-19`,
`crates/buzz-relay/src/audio/wire.rs:56-85`. Authentication uses NIP-42, and
room lifecycle events are relay-signed in
`crates/buzz-relay/src/audio/handler.rs:1-12`,
`crates/buzz-relay/src/audio/handler.rs:93-145`, and
`crates/buzz-relay/src/audio/handler.rs:719-785`.

"Opaque to the relay code" is not the same as "encrypted from the relay". Audio
confidentiality relies on the relay host and transport security unless another
layer is added above the current wire format.

## Trust Boundaries And Non-Findings

The desktop renderer is inside the human account-key trust boundary. Tauri
commands expose event signing, `get_nsec`, import, and self-NIP-44 operations in
`desktop/src-tauri/src/commands/identity.rs:67-90`,
`desktop/src-tauri/src/commands/identity.rs:151-197`, and
`desktop/src-tauri/src/commands/identity.rs:199-244`. A renderer compromise is
therefore a key compromise. That may be an acceptable product boundary, but it
should not be confused with a hardware-backed or isolated signer design.

Managed agents are also intentionally inside the local machine trust boundary.
The runtime injects `BUZZ_PRIVATE_KEY`, `BUZZ_AUTH_TAG`, and
`NOSTR_PRIVATE_KEY` into child processes in
`desktop/src-tauri/src/managed_agents/runtime.rs:1549-1561`,
`desktop/src-tauri/src/managed_agents/runtime.rs:1648-1656`, and
`desktop/src-tauri/src/managed_agents/runtime.rs:1682-1687`. The environment
filtering in `desktop/src-tauri/src/managed_agents/env_vars.rs:58-145` is useful
defense in depth, but an agent that is deliberately allowed to run local tools
is not a secret-isolated principal.

Ordinary messages are signed, not end-to-end encrypted. The relay, its storage,
and its operators can see plaintext unless a specific feature wraps content in
NIP-44. Huddle audio has the same property. TLS protects transport hops; it
does not remove the relay from the confidentiality boundary.

Encrypted Nostr events still expose routing metadata. NIP-44 hides content, but
the relay can often observe timing, size, event kind, and tags. Any privacy
claim should be phrased as content confidentiality, not traffic-analysis
resistance.

Some relay-signed state is trusted because it came from the configured relay,
not because every client re-verifies every relay signature. The NIP-DV docs
state this explicitly for desktop query behavior in `docs/nips/NIP-DV.md:118-128`.
That is a reasonable trust model for a single configured workspace relay, but
it is different from an offline-verifiable transparency model.

## Recommended Fix Order

1. Fix mobile NIP-AB payload handling so target consent actually gates payload
   plaintext exposure, then clear all pairing secret state on every terminal
   path.
2. Centralize NIP-OA/NIP-AA semantic authorization and enforce signed time
   conditions during relay admission; add real managed-agent credential
   retirement.
3. Make NIP-98 payload binding mandatory for JSON bridge routes and keep the Git
   weakening explicit and local.
4. Harden managed-agent key storage to the same permission standard as the
   desktop human identity key.
5. Decide what audit tamper-evidence threat model is intended and align either
   the implementation or the documentation.
6. Add strict mobile NIP-44 vector tests and canonical padding checks.