Files

T

2026-07-20 20:17:22 -04:00

50 KiB

Raw Permalink Blame History

GPT-5.6 Comprehensive Security and Usability Audit

Audit date: 2026-07-20
Audited workspace: post_quantum_nostr at root commit 9a975fcbc56e455a68ae16d734feeed76ba304b6
Application version: 0.0.11
Auditor: GPT-5.6
Scope: first-party application code, cryptographic and Nostr/OTS protocol design, browser security, dependencies, tests, documentation claims, live public deployment, and the OpenTimestamps submodule boundary.

Executive verdict

Do not use this implementation to protect a real Nostr identity yet. It is a useful research prototype with working PQ key generation/signature primitives and a promising OTS proof parser, but its verifier currently accepts events with no PQ signatures, treats missing signatures on declared signature algorithms as successful KEM-style entries, does not bind the outer wrapper identity to the embedded announcement identity, and does not implement its defining earliest valid OTS anchor wins selection rule. These are protocol-critical failures, not polish issues.

Conceptual verdict: the project is conditionally sound as a pre-quantum key-commitment and identity-link protocol, but it is not, by itself, a complete post-quantum migration for Nostr. Its central idea—have the current identity authorize PQ keys while secp256k1 is still trustworthy, anchor that authorization in Bitcoin, and later prefer the earliest valid anchor—is defensible if the protocol is redesigned to enforce immutable discovery, strict verification, key possession/continuity, and PQ-authorized rotation. Fixing only the implementation bugs would not be enough. Fixing the architectural requirements in the “Conceptual soundness assessment” below could yield a valid and useful project, but the result should initially be described as a PQ key pre-commitment/link registry, not as making the existing Nostr identity fully quantum-resistant.

The project did well in several areas:

All 38 existing tests passed, including two live checks against Bitcoin API data.
A fresh browser bundle was byte-for-byte identical to the committed bundle.
npm audit --omit=dev reported no advisories for the currently installed root dependency graph.
The OTS target digest is bound to the expected event hash during full verification.
The live bundle exactly matched the audited local bundle.
A live calendar submission succeeded to all five configured calendars and parsed as a detached multi-calendar proof.

Those strengths do not compensate for fail-open acceptance in the key-link verifier. A user-facing statement such as “All signatures verified successfully” can currently be produced for a signed wrapper whose embedded announcement has zero PQ keys. The application also presents a latest replaceable event from relays, whereas the proposal says the canonical link is the event with the earliest verified Bitcoin anchor. That mismatch defeats the core post-quantum migration rule.

Severity summary

Severity	Count	IDs
Critical	2	G56-01, G56-02
High	6	G56-03 through G56-08
Medium	8	G56-09 through G56-16
Low / informational	4	G56-17 through G56-20

Findings at a glance

ID	Severity	Finding	Confidence
G56-01	Critical	Verifier accepts a migration with no PQ signatures and accepts missing signature fields as valid	Confirmed dynamically
G56-02	Critical	Earliest-valid-anchor rule is not implemented; relay discovery selects the latest replaceable event	Confirmed
G56-03	High	Outer wrapper identity is not bound to the embedded announcement identity	Confirmed dynamically
G56-04	High	OTS “verification” trusts public HTTPS APIs and does not validate Bitcoin headers or proof of work	Confirmed
G56-05	High	Signer output is reconstructed without validating returned identity, event ID, signature, or exact signed fields	Confirmed
G56-06	High	The system creates a new seed for any signed-in identity without proving seed continuity or a successor key relationship	Confirmed design limitation
G56-07	High	Verification is not robust against malformed untrusted relay/paste input and can throw	Confirmed dynamically
G56-08	High	Browser origin is the key-generation trust boundary, but deploy hardening and signer assets are unaudited/unpinned	Confirmed
G56-09	Medium	Twelve-word seed is the only generated option and its warning is removed in the audited workspace/live page	Confirmed
G56-10	Medium	Secret material is retained in ordinary JavaScript objects/DOM/clipboard and is not zeroized	Confirmed
G56-11	Medium	Publish workflow reports success and advances even when no relay accepts one or both events	Confirmed
G56-12	Medium	Resume/upgrade state can fetch an attacker-controlled latest wrapper and lacks robust event/workflow binding	Confirmed
G56-13	Medium	OTS parser lacks total input/operation budgets and uses unsafe 32-bit varuint arithmetic	Confirmed
G56-14	Medium	Dependency resolution is not reproducible from the repository; lockfile is ignored and inconsistent	Confirmed
G56-15	Medium	OpenTimestamps submodule is not clonable normally because `.gitmodules` is absent; historical dependency risk is unresolved	Confirmed
G56-16	Medium	Documentation and UI overclaim implementation status and security properties	Confirmed
G56-17	Low	Block-height statement is not validated and can be zero/untrusted	Confirmed
G56-18	Low	Relay URL policy permits insecure `ws://` and arbitrary endpoints	Confirmed
G56-19	Low	Missing event IDs may be accepted by the library verifier	Confirmed dynamically
G56-20	Informational	Large events may be rejected by relays; interoperability testing is absent	Confirmed size; relay behavior contextual

Conceptual soundness assessment

Direct answer

Is the idea flawed from the start? No—but its valid scope is narrower than the current product language suggests.

The project starts from a real migration problem: after secp256k1 is broken, a fresh secp signature cannot distinguish the legitimate owner from an attacker. Creating and timestamping an authorization before that break is a legitimate way to establish historical precedence. A PQ key that signs the same canonical authorization provides durable proof that the corresponding PQ private key participated. Bitcoin/OpenTimestamps can provide an externally ordered existence proof without changing Nostr relays.

That gives a conceptually useful primitive:

Before quantum compromise, identity A authorized PQ key set K; the authorization existed no later than Bitcoin block H; future clients can use a deterministic conflict rule to resolve later forged claims.

However, that primitive does not automatically make identity A quantum-resistant. A complete migration also needs a standardized way to authenticate future events with K, rotate/revoke keys after secp256k1 is distrusted, encrypt to PQ keys, discover all historical claims despite relay replacement/deletion, and recover from lost or compromised PQ keys. Those pieces are currently outside the implementation.

What remains valid after remediation

If all audit recommendations and the architectural requirements in audit_mitigation.md are implemented, the project can validly provide:

Pre-quantum commitment: proof that a Nostr identity authorized a canonical PQ key set before a verified Bitcoin block.
PQ proof of possession: proof that each linked signature key participated in the canonical authorization, and an explicit KEM possession mechanism if ML-KEM ownership is claimed.
Deterministic conflict resolution: selection of the earliest valid immutable anchor rather than the newest relay event.
A migration root: a trustworthy starting key set for a separate PQ-event, PQ-encryption, and key-rotation protocol.
Backward-compatible publication: legacy relays can carry opaque events without understanding PQ cryptography, subject to size and retention limits.

What remediation cannot make true without additional protocols

Even a perfectly implemented key-link protocol does not itself provide:

PQ authentication for ordinary kind 0/1/3/etc. events;
PQ confidentiality for NIP-04 or NIP-44 messages;
automatic preservation of the social graph in clients that do not adopt identity-alias/successor semantics;
revocation or rotation after secp256k1 becomes untrustworthy;
availability if all relays and user archives lose the immutable announcement/proof;
protection from seed theft, malicious signers, compromised web origins, or broken PQ implementations;
consensus across Nostr clients about algorithm policy or canonical identity succession.

The project therefore needs companion specifications for PQ-signed events, key lifecycle, encryption, and client identity mapping before it can accurately claim a complete Nostr PQ migration.

Architectural conditions for a sound protocol

The concept is sound only if all of these invariants are made normative and implemented:

Canonical signed object: PQ signatures and the current secp identity must cover one domain-separated, versioned, deterministic structure containing the old identity, complete ordered key set, algorithm identifiers, protocol version, creation context, and rotation policy. Human-readable prose may be displayed but must not be the normative signed representation.
Strict proof policy: a verifier must distinguish structural validity, cryptographic validity, algorithm-policy sufficiency, OTS validity, and canonical-selection status. Missing signatures can never become successful KEM entries.
Identity equality: queried author, wrapper author, embedded author, and canonical old-identity field must match.
Immutable candidates: the initial authorization must not depend on a replaceable event that can hide prior history. An upgraded proof may reference the same immutable authorization digest, but cannot replace the candidate itself.
Complete discovery: clients must collect candidates across relays/archives and apply a deterministic earliest-valid-anchor rule, including tie-breaks and confirmation-depth policy.
Possession and recoverability: every signature key must prove possession. If the project promises seed recovery, the canonical statement must bind a seed-derived successor proof or the UI must explicitly avoid claiming common seed origin. KEM possession requires a defined challenge/decapsulation proof or must be described only as an authorized encryption key, not proven possession.
Post-break authority: after the transition cutoff, secp-only updates must not supersede the canonical PQ root. Rotation/revocation must require a threshold or policy over already-authorized PQ keys.
Future event semantics: a separate specification must define exactly how PQ keys authenticate future Nostr events and how those events bind to NIP-01 IDs, kinds, tags, replay domains, and old identities.
Availability: users and clients must export, mirror, and validate the immutable authorization plus OTS proof independently of any one relay or web service.
Trust-explicit Bitcoin verification: implementations must state whether they use a local node, a validated header chain, or trusted explorer APIs. Security labels must match that model.
Algorithm agility with policy: multiple algorithms may hedge cryptanalytic risk, but clients need mandatory minimum sets, deprecation rules, downgrade resistance, and deterministic handling of unknown schemes.
Secure key boundary: production derivation/signing should occur in a dedicated signer or hardware boundary, not an updateable general-purpose web origin holding a long-lived seed.

Bottom line

With those conditions and the finding-specific fixes, this can become a valid PQ migration foundation. Without them, repairing individual code defects would leave a system that generates valid PQ signatures but lacks a trustworthy rule for what those signatures mean over time. The current project is therefore salvageable and conceptually promising, but architecturally incomplete.

Scope, baseline, and trust boundaries

First-party runtime surface

Cryptographic module: pq-crypto.mjs
Generated browser bundle: pq-crypto.bundle.js
Migration page and state machine: index.html
Verification page and relay query flow: verify.html
Tests: pq-crypto.test.mjs
Build script: build-pq-bundle.js
Protocol proposal: nip_proposal.md
User-facing claims: README.md

External trust boundaries

Web origin / deployment operator controls the JavaScript that receives or generates a BIP39 mnemonic and PQ private keys.
nostr-login-lite / NIP-07/NIP-46 signer supplies the current identity and signs events.
Nostr relays receive, retain, filter, and return untrusted events.
OTS calendars receive event digests and return pending timestamp fragments.
Same-origin /ots-upgrade helper receives OTS proof bytes and returns upgraded bytes; its implementation is absent from the repository.
Blockstream and mempool.space APIs supply the purported Bitcoin block hash, Merkle root, and timestamp.
npm dependencies and committed generated bundle implement all cryptographic primitives in the browser.
OpenTimestamps submodule supplies example proofs used by tests, but is not runtime-integrated.

Audit limitations

No browser automation framework or complete signer fixture is present, so the real NIP-07/NIP-46 modal flow was reviewed statically rather than driven end to end.
The /ots-upgrade server source and nginx/deployment configuration are not in the repository. Only black-box HTTP behavior could be checked.
No real Nostr identity was used and no migration event was published during the audit.
The workspace was already dirty: user changes existed in index.html, verify.html, and nip_proposal.md, plus unrelated deleted audit files. The report evaluates the working tree, not a pristine commit.
Root advisory results describe the installed graph at audit time, not every graph permitted by semver ranges.

Detailed findings

G56-01 — Verifier accepts no PQ signatures and missing signatures as successful

Severity: Critical
Confidence: Confirmed dynamically

The central verifier initializes results with only secp256k1, e, and SHA-256 checks, then loops over whatever algorithm tags happen to exist. It never requires any algorithm tag, never requires the four expected signature algorithms, and never validates uniqueness or policy. See verifyNIPQRContent() and its unconditional aggregate at results.every().

Worse, any algorithm tag lacking a fourth field is marked valid as a KEM, regardless of its algorithm identifier:

if (algorithm === 'ml-kem-768' || !sigBase64) {
    results.push({ algorithm, valid: true, note: 'KEM (no signature to verify)' });
    continue;
}

This logic is at verifyNIPQRContent().

Dynamic probes established:

A validly secp-signed embedded kind 1 event with tags: [] returned valid: true.
ml-dsa-44, ml-dsa-65, slh-dsa-128s, and falcon-512 tags containing only a public-key field each returned valid: true with note KEM (no signature to verify).
An arbitrary unknown algorithm with no signature also returned valid.

The UI then presents All signatures verified successfully! when this incomplete result is true at verify.html.

Impact: The verifier can bless an event that provides no post-quantum authentication at all. Such an event does not establish the advertised migration and cannot support post-quantum continuity.

Remediation: Define and enforce a verification policy. At minimum:

Require exactly one tag for each mandatory supported algorithm.
Require exact field counts and decoded byte lengths.
Permit no-signature handling only for the exact ml-kem-768 identifier.
Reject duplicate known algorithms.
Treat unknown algorithms as ignored—not valid evidence—and report them separately.
Return distinct structural validity, cryptographic validity, policy sufficiency, and OTS validity fields.
Add adversarial tests for empty tags, missing signatures, duplicate algorithms, unknown algorithms, and malformed encodings.

Verification criterion: No event can receive a migration-valid result unless the configured required PQ signature set verifies successfully.

G56-02 — The defining earliest-valid-anchor rule is not implemented

Severity: Critical
Confidence: Confirmed

The proposal makes earliest verified Bitcoin anchor selection the mechanism that defeats a later quantum forgery at nip_proposal.md. The implementation instead queries kind 11112 with limit: 1 and describes it as “latest” at verify.html. Across relays, it chooses the largest created_at value at verify.html. The resume path also requests one event at index.html and selects newest created_at across relays at index.html.

Kind 11112 is replaceable, as documented in pq-crypto.mjs. A later forged or accidental replacement can therefore hide the historical event from ordinary relay queries. Even before a quantum break, a compromised current key can publish a newer wrapper. After a break, the attacker can do so trivially. The application does not gather all candidate announcements/proofs, verify them, compare Bitcoin heights, or preserve a stable immutable discovery record.

Impact: The implemented discovery behavior can select the exact later event that the OTS precedence design says must lose. This breaks the central migration security argument.

Remediation: Redesign discovery and storage before production use:

Use a non-replaceable canonical announcement or an append-only indexed form for immutable candidates.
Fetch all candidates from multiple relays, not limit: 1.
Fully validate each candidate and select the earliest valid Bitcoin anchor according to a precise tie-break rule.
Define how upgraded OTS proofs refer to an immutable announcement without replacing or obscuring history.
Cache/export the canonical proof so relay retention does not determine identity continuity.
Implement PQ-authorized rotation separately.

Verification criterion: Given multiple candidates—including a later forged secp-valid candidate—the client deterministically chooses the candidate with the earliest valid Bitcoin anchor.

G56-03 — Outer wrapper identity is not bound to embedded identity

Severity: High
Confidence: Confirmed dynamically

verifyNIPQRContent() validates the embedded kind 1 event and tags but receives no outer event object and therefore cannot require outer.pubkey === embedded.pubkey. verifyEvent() separately validates the outer signature and calls the content verifier without performing this identity equality check.

A dynamic probe built a valid embedded event signed by key A, wrapped it in a valid kind 11112 event signed by key B, and observed:

outer signature valid: true
embedded verification valid: true

Impact: A wrapper authored by one identity can carry another identity’s announcement and appear as a collection of passing checks. Relay query by author B can therefore display A’s embedded link under B’s result page. OTS upgrading/republishing may further re-sign mismatched content.

Remediation: Require equality among:

requested relay-query author,
outer wrapper pubkey,
embedded kind 1 pubkey,
identity named in the human-readable content (or preferably a canonical structured identity field).

Also require correct outer kind and exact tag cardinality.

G56-04 — Bitcoin verification trusts public API JSON and does not validate block headers or proof of work

Severity: High
Confidence: Confirmed

fetchBitcoinBlockHeader() fetches a block hash by height and then a block JSON object from one of two public APIs. It extracts only a Merkle root and timestamp at pq-crypto.mjs. verifyOtsProof() compares the OTS commitment to that API-provided Merkle root.

Despite comments calling this “independently verifiable against the Bitcoin PoW chain” at pq-crypto.mjs, the implementation does not fetch raw 80-byte headers, hash a header, check its hash against target, verify chain linkage, validate accumulated work, or pin checkpoints. Both providers are contacted over HTTPS and are simply trusted to report honest data.

Impact: Compromise, interception at a trusted origin, coordinated false responses, or API semantic changes can cause a false “Bitcoin verified” result. Two fallback URLs are resilience, not trust minimization, because acceptance requires only one response.

Remediation: Accurately label the current mode as “verified against a trusted block explorer.” For stronger verification, use a local Bitcoin node or a real light client with headers, chainwork, checkpoints, and consensus validation. At minimum compare multiple independent providers and fail on disagreement, but do not call that trustless cryptographic Bitcoin verification.

G56-05 — Signer output is trusted and reconstructed without validation

Severity: High
Confidence: Confirmed

After window.nostr.signEvent, the migration flow copies id, pubkey, and sig from the signer but takes created_at, kind, content, and tags from the local template at index.html. It does not check:

signer-returned pubkey equals the authenticated currentPubkey,
returned ID equals computeEventId() for the final reconstructed event,
returned signature verifies,
signer did not alter fields,
the wrapper signer matches the announcement signer.

The same trust is repeated for the wrapper at index.html and upgraded events at index.html. The verify page republishes signer output directly at verify.html, but also does not validate it before publishing.

Impact: A buggy, malicious, or incompatible signer can cause invalid or wrong-identity events to be displayed and published as successful. Reconstructing a hybrid object can pair a signer’s signature with different fields.

Remediation: Treat signer output as untrusted. Validate complete returned events, exact field equality against approved templates, pubkey equality, event ID, and Schnorr signature before any display, persistence, or publish.

G56-06 — New seed continuity is asserted, not proven

Severity: High
Confidence: Confirmed design limitation

The app generates or accepts an arbitrary seed after signing into an existing identity. It derives a seed-based secp key at deriveSecp256k1FromSeed() but does not use that key to sign, and does not verify that an entered seed derives the currently signed-in Nostr identity. The documentation acknowledges no successor signature at README.md.

For a raw-nsec identity, an old-identity signature plus pre-quantum OTS can establish that the old identity authorized listed PQ keys. It cannot prove those keys are recoverable from the mnemonic shown to the user or that all listed keys share one seed. For a mnemonic-based existing identity, failing to compare the derived secp public key wastes a strong continuity check.

Impact: A compromised browser can show one mnemonic while publishing attacker-chosen PQ keys; the old signer approves only a very large event whose key material is hard for a human to inspect. The user may believe the written mnemonic is a recoverable root when it is not cryptographically bound as such.

Remediation: Separate two modes:

Existing mnemonic identity: derive the NIP-06 secp key and require it to equal the signer pubkey before proceeding.
Raw-nsec migration: define a canonical structured migration statement and add a proof-of-possession/successor signature from a seed-derived key, plus recovery self-test before publishing.

A hardware signer or dedicated PQ signer should ideally derive/sign without exposing the mnemonic to a web origin.

G56-07 — Untrusted verifier input can throw instead of failing closed

Severity: High
Confidence: Confirmed dynamically

The verification page accepts pasted JSON and relay events. verifyNIPQRContent() assumes arrays and valid base64. Examples confirmed during testing:

malformed base64 threw InvalidCharacterError,
non-array wrapper tags threw TypeError: kind11112Tags.find is not a function,
missing signatures caused verifyNostrEvent() to throw,
null or wrong-shaped events threw.

Relay-driven verification at verify.html invokes the verifier without the paste handler’s try/catch; malformed relay content can reject the click callback and leave inconsistent UI. PQ decoders can also receive attacker-selected large or malformed data without preflight size checks.

Impact: Remote relays can cause denial of service, misleading partial results, or expensive parsing/cryptographic work.

Remediation: Add strict schemas and byte-size limits before cryptography. Every exported verification function should return structured failure for untrusted input, never throw for ordinary malformed data. Add fuzz/property tests and maximum event/proof sizes.

G56-08 — Browser origin security is insufficient for handling a root seed

Severity: High
Confidence: Confirmed

The page states the seed is processed entirely in the browser at index.html. That means the web origin—not merely the reviewed source—is trusted with the seed. The live response lacked HSTS, X-Frame-Options/CSP frame-ancestors, Referrer-Policy, Permissions-Policy, and other defense-in-depth headers. The meta CSP allows 'unsafe-inline' scripts at index.html and verify.html, materially weakening XSS protection.

Two large same-origin signer scripts are loaded outside this repository at index.html and verify.html. They have no SRI and could not be source-audited here. Live sizes were 328,444 and 230,498 bytes. Any server compromise or update to these assets can exfiltrate the mnemonic and all PQ keys. The source for /ots-upgrade and server configuration is also absent.

Impact: A single origin compromise defeats the entire root-of-trust design. HTTPS alone does not make web-based seed entry equivalent to a hardware or native signer.

Remediation: Do not recommend entering a valuable existing mnemonic into this web app. Move derivation and PQ signing into a dedicated signer/hardware boundary. Also extract inline scripts, enforce nonce/hash CSP without 'unsafe-inline', add frame-ancestors 'none', HSTS, Referrer-Policy, Permissions-Policy, pinned/vendored signer assets, reviewed deployment configuration, and release integrity documentation.