Independent security review brief

Scope, invariants, attack cases, evidence, and deliverables for an independent Ownfold cryptographic and application-security assessment.

This brief defines the minimum independent review required before Ownfold can be described as a production-grade beta. It is an audit input, not evidence that an audit occurred. The release owner must replace every placeholder with a commit-pinned artifact and retain the final report.

Review target

Record the exact source commit, candidate package versions, Node and pnpm versions, supported browser matrix, database versions, reviewer organization, review dates, and final report URL. The review must use a clean checkout of that commit. Findings against a moving branch are not release evidence.

In scope

Security invariants to challenge

The reviewer should attempt to disprove each invariant:

1. Root keys are generated client-side and raw root or record keys are unavailable through public APIs, transports, server packages, logs, and persisted server records.
2. Record ciphertext, wrapped data keys, nonces, format versions, vault identifiers, key versions, namespaces, record identifiers, ownership context, and encodings are authenticated together.
3. Nonces are generated with approved cryptographic randomness and cannot be reused through an exposed caller-controlled API.
4. Recovery passwords and codes never enter transport or server storage. Recovery Kits never contain a plaintext root key and wrong-secret failures do not form a useful authentication oracle.
5. Device enrollment and pairing prevent public-key substitution, cross-vault replay, expired-offer use, duplicate completion, and unauthorized ownership changes.
6. Revocation and optimistic revisions reject stale security mutations without claiming to erase material already captured by a compromised device.
7. Root-key rotation resumes idempotently, preserves record content ciphertext, authenticates old and new key versions, and cannot expose a half-committed vault as complete.
8. Unsupported, corrupted, truncated, duplicated-field, and oversized persisted inputs fail closed with typed errors that contain no secret material.
9. Worker crashes, timeouts, malformed messages, and cloning failures are terminal and never cause silent main-thread cryptographic fallback.
10. Framework and database adapters authenticate ownership, preserve ciphertext-only boundaries, and cannot import a user-data decryption capability from server code.
11. Published packages contain only reviewed files and make no project-owned runtime request.

Required attack cases

At minimum, review nonce handling, AEAD associated-data construction, key zeroization limits, Argon2id parameters, password normalization, recovery-file parsing, record and device replay, cross-user and cross-vault substitution, pairing races, revocation races, interrupted rotation, rollback to old metadata, malicious adapter responses, IndexedDB tampering, cross-tab races, worker protocol spoofing, XSS consequences, dependency compromise, build output, and npm provenance.

The report must distinguish exploitable findings from browser-E2EE limitations already stated in the threat model. A documented limitation is not automatically acceptable: the reviewer should assess whether product copy and APIs communicate it accurately.

Reproducible evidence

Run pnpm release:check with the repository’s explicitly disposable PostgreSQL test database. Also inspect immutable compatibility fixtures, API Extractor reports, packed tarballs, the production demo bundles, browser network observations, and the clean external-consumer test. Audit commands must not target a shared or production database and must not use destructive reset flags.

Fuzzing or additional test harnesses created during the review should be attached to the report or submitted as reproducible patches. Never include recovery secrets, root keys, production data, or private vulnerability details in public test output.

Deliverables and release rule

The independent reviewer must provide an executive summary, methodology, reviewed commit, threat model assessment, finding list with severity and exploit conditions, remediation verification, and residual-risk statement. Critical and high findings block release. Moderate findings block release unless fixed or explicitly accepted by the release owner with scope, compensating controls, and an expiry date. Low and informational findings must be tracked.

Publish a disclosure-safe summary for users. Keep exploit details private until remediation and coordinated disclosure are complete. Record the final report and remediation commits in the release evidence record.