fix: latex rendering

README.md

@@ -11,28 +11,37 @@
   whitepaper that this copy replaced.
 
 ## Our Definition
+
 NESSA is a privacy-first, local-first protocol layer designed for identity, access, and credential management. It enables a user or device to compress numerous sensitive security events, such as enrollments, key rotations, and policy checks, into a single verifiable object. A verifier can inspect this object to confirm policy compliance without accessing the underlying event data or leaking metadata. This capability is powered by **qFold**, a folding transform that aggregates event commitments and generates a succinct proof of correctness. NESSA maintains a consistent application experience across two cryptographic backends. **qFold-EC** is an elliptic-curve track available for immediate deployment, while **qFold-PQ** provides a post-quantum migration path. This dual-engine design ensures that the user experience, APIs, and privacy semantics remain stable even as the underlying cryptography evolves.
 
 ## Prove Only What Is Necessary
+
 The protocol operates on a principle of selective disclosure by default. Verifiers learn only the final policy result, for example, that multi-factor authentication is satisfied and a device is valid. They do not learn the count, timestamps, or order of the events unless a policy explicitly requires it. This is the central benefit of folding many cryptographic facts into a single object.
 
 ## Offensive Privacy and Metadata Minimization
+
 NESSA is designed to deliberately eliminate correlation surfaces. A single folded object replaces numerous linkable artifacts like tokens or logs. The system does not require a central log of raw events, and proofs are scoped to the verifier and are minimally informative. External attestations are treated as opaque inputs to the fold, preventing them from being used as cross-system tracking beacons.
 
 ## Local-First and Self-Sovereign Control
+
 The raw transcript of events remains under the user's or device's control. The only durable artifact a verifier requires is the latest folded object and its corresponding proof. This model aligns with a self-sovereign stance where users hold their own authentication materials, and verifiers check them without collecting sensitive history.
 
 ## Key Lifecycle with Forward Security
+
 The protocol supports a robust key lifecycle, including progressions from master to session-specific keys and regular updates. Each folding operation refreshes the cryptographic randomness and invalidates old proof openings. Key rotations and account recovery operations are simply new events folded into the state, providing forward secrecy without revealing the frequency of these changes.
 
 ## Integrated Access Control Primitives
+
 Critical access control functions like delegation, revocation, and usage limits are treated as first-class events. Delegations are recorded as events, while revocations are managed through accumulators folded into the state object. Usage limits for credentials can be enforced with privately tracked nullifiers, allowing a verifier to see only the final validity status, not the usage history.
 
 ## Context-Bound Proofs without Context Leakage
+
 To prevent replay attacks, proofs can be cryptographically bound to a specific context, such as device posture or a time-window label. The binding is secure and verifiable, yet the context values themselves remain hidden from the verifier.
 
 ## Unified Surface for Dual Cryptographic Engines
+
 NESSA provides a consistent API and semantic surface that is independent of the underlying cryptographic engine. **qFold-EC** uses Pedersen-style commitments and inner-product arguments on elliptic curves. **qFold-PQ** uses Module-LWE commitments and folded lattice sigma-protocols for post-quantum resilience. This ensures that migration is a managed process, not a complete product rewrite.
 
 ## Simplified Verification
+
 A verifier's task is reduced to a single function call, `VerifyFolded(policy, folded_object, proof)`. This call returns a straightforward valid or invalid result, potentially with reason codes. It removes the need for verifiers to pre-fetch logs or reconstruct historical state, making NESSA practical for diverse environments from backend servers to constrained on-chain verifiers.

whitepaper-230326-audit.md

@@ -9,7 +9,7 @@ Key audit-backed facts incorporated into the updated white paper:
 - **Protocol verification status (internal audit):** `verification_report.json` reports **80 total checks, 80 passed, 0 failed** (file `docs/generated/protocol/verification/verification_report.json`, sha256 `e873fab3ad50d1801e37ba310d87af780552bcc09d6648eee72197d3c471aa58`).
 - **Computed test vectors (internal audit):** `test_vectors_output.json` includes `TV-LIN-8` with `proof_size_bytes = 832` and `TV-R1CS-8` with `proof_size_bytes = 1120` (file `docs/generated/protocol/test_vectors/test_vectors_output.json`, sha256 `400dfb6f6176e95f4d078ba2f2ad4b1615fc403dbb298866eb92d1148aecdb63`).
 - **ASC ad demo outcomes (internal audit):** `asc_ad_business_summary.json` reports **100 total checks**, **94 accepted**, **6 rejected** with **0 unexpected rejections** and denial reasons dominated by `age_band_below_minimum` and `consent_mask_missing` (file `docs/generated/asc_ad_demo/audit/asc_ad_business_summary.json`, sha256 `a11954c03d016ab480aa7ab999a1aacbfb2a260e6e52b76a0cfb4f759feb6f1b`).
-- **ASC benchmark scaling (internal audit):** `asc_ad_benchmark_rows.json` shows `verify_ms` rising from **~4.808 ms at N=1** to **~381.371 ms at N=4096**, while benchmark `proof_size_bytes` stays constant at **1632** in that profile (files `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_rows.json`, sha256 `b7d462fb594e065c3176c8d2d41832c904dd8767aefaac7f0fa93d3881566df9` and `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_validity.json`, sha256 `8bec0abe663a1101a0b65202df0436d8c28df6f009bf26e37e4dba13c6a595bc`).
+- **ASC benchmark scaling (internal audit):** `asc_ad_benchmark_rows.json` shows `verify_ms` rising from **approximately 4.808 ms at $N = 1$** to **approximately 381.371 ms at $N = 4096$**, while benchmark `proof_size_bytes` stays constant at **1632** in that profile (files `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_rows.json`, sha256 `b7d462fb594e065c3176c8d2d41832c904dd8767aefaac7f0fa93d3881566df9` and `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_validity.json`, sha256 `8bec0abe663a1101a0b65202df0436d8c28df6f009bf26e37e4dba13c6a595bc`).
 - **Privacy logging posture (internal audit):** `asc_ad_privacy_audit.json` indicates proofs are redacted and fields like `prover_identity`, `raw_profile`, and `user_secret_digest` are excluded from audit outputs (file `docs/generated/asc_ad_demo/audit/asc_ad_privacy_audit.json`, sha256 `0e5dd4b9bc5566f6c9ab9e6ed933ac1481ce34efbf5216828c93143cf2a46dca`).
 
 External standards and developments were researched and mapped into the updated white paper, prioritizing primary and official sources: RFC 8949 (CBOR deterministic encoding), RFC 9380 (hashing to curves), RFC 9496 (ristretto255), RFC 8235 (Schnorr NIZK), FIPS 180-4 (SHA-512), Nova, HyperNova, Bulletproofs, GDPR Article 25 plus EDPB guidance, DSA Article 28, IAB GPP, and the W3C Private Advertising Technology Working Group charter.
@@ -47,7 +47,7 @@ The table below lists the highest-impact gaps and inconsistencies between (a) th
 | Baseline white paper claim or assumption | Audit finding (authoritative metadata) | Action taken in update |
 | --- | --- | --- |
 | Tags schema examples suggest some application identifiers are integers (e.g., `encoding_id`, `policy_id` shown as small ints in example tags). | In ASC demo proof bundles, `encoding_id` is the text string `"nessa_asc_ad_v1"` and `policy_id` is a text string policy name (e.g., `"nessa_asc_ad_luxury_targeting_checksum_v1:ctx:<digest>"`) inside the tags map for accepted cases (file `docs/generated/asc_ad_demo/audit/asc_ad_focused_proofs.json`, sha256 `466e6bf5aaac69964f897fb6f126e4cd57f9914ef3b80b8eaf7438f9c443e88b`). | Updated the tags section to be **profile-typed**: integer keys remain, but values may be int/bstr/tstr; ASC profile defines `encoding_id` and `policy_id` as text strings. |
-| Performance/proof-size statements are not anchored to measured results. | ASC benchmark shows **proof_size_bytes constant at 1632** across N in that profile and `verify_ms` increasing to ~381 ms at N=4096 (files `asc_ad_benchmark_rows.json` sha256 `b7d462...` and `asc_ad_benchmark_validity.json` sha256 `8bec0a...`). | Added an explicit benchmark section with a verify_ms-vs-N chart and table; removed any “near-constant verify time” tone for this profile. |
+| Performance/proof-size statements are not anchored to measured results. | ASC benchmark shows **`proof_size_bytes` constant at `1632`** across $N$ in that profile and `verify_ms` increasing to approximately 381 ms at $N = 4096$ (files `asc_ad_benchmark_rows.json` sha256 `b7d462...` and `asc_ad_benchmark_validity.json` sha256 `8bec0a...`). | Added an explicit benchmark section with a `verify_ms` vs $N$ chart and table; removed any “near-constant verify time” tone for this profile. |
 | Privacy posture and logging requirements are not described as an operational control. | Privacy audit indicates proofs are redacted and fields like `prover_identity`, `raw_profile`, `user_secret_digest` are redacted (file `asc_ad_privacy_audit.json`, sha256 `0e5dd4...`). | Added a dedicated privacy-safe logging posture and clarified the guarantee boundary between proof verification and observability controls. |
 | The document is protocol-centric and does not present a complete ad verification system architecture. | ASC demo provides business summary outcomes and a defined encoding id and attribute schema for ad verification use case (file `asc_ad_test_metadata.json` sha256 `b3f933...`; `asc_ad_business_summary.json` sha256 `a11954...`). | Reframed as a system white paper with an ASC ad verification “application profile,” plus an architecture diagram and control surface description (consent, nullifiers, audit). |
 | Proof object format assumptions are not reconciled with the demo’s richer record structure. | Demo proof objects include explicit `pi_link` and `pi_cons_linear` fields (with stored challenge fields in the demo records) and omit proof objects entirely for denied cases (some denied entries have `row_count=0` and no folded object). | Clarified normative vs demo format: verifier MUST recompute challenges; including them in records is optional convenience and must be checked for consistency. Also documented deny-path behavior. |
@@ -127,7 +127,7 @@ flowchart LR
   end
 ```
 
-### Mermaid performance scaling chart: verify_ms vs N
+### Mermaid performance scaling chart: `verify_ms` vs $N$
 
 (From internal audit benchmark rows, ASC demo profile; file `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_rows.json`, sha256 `b7d462fb594e065c3176c8d2d41832c904dd8767aefaac7f0fa93d3881566df9`.)
 
@@ -175,7 +175,7 @@ This is the concise, “changes-that-matter” mapping. The updated white paper
 | same | `$.attribute_fields` | list of 8 fields | Added explicit ad eligibility encoding schema narrative (fixed order, consistent semantics). |
 | `docs/generated/asc_ad_demo/audit/asc_ad_business_summary.json` (sha256 `a11954c03d016ab480aa7ab999a1aacbfb2a260e6e52b76a0cfb4f759feb6f1b`) | `$.acceptance_rate` | `0.94` | Added outcomes section with acceptance/rejection and denial taxonomy. |
 | `docs/generated/asc_ad_demo/audit/asc_ad_privacy_audit.json` (sha256 `0e5dd4b9bc5566f6c9ab9e6ed933ac1481ce34efbf5216828c93143cf2a46dca`) | `$.redacted_fields` | includes `prover_identity`, `raw_profile`, `user_secret_digest` | Added privacy-safe audit logging requirements and prohibited-field list. |
-| `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_rows.json` (sha256 `b7d462fb594e065c3176c8d2d41832c904dd8767aefaac7f0fa93d3881566df9`) | `$[N==4096].verify_ms` | `381.370828` | Added verify_ms vs N scaling chart and capacity-planning guidance. |
+| `docs/generated/asc_ad_demo/audit/asc_ad_benchmark_rows.json` (sha256 `b7d462fb594e065c3176c8d2d41832c904dd8767aefaac7f0fa93d3881566df9`) | `$[N==4096].verify_ms` | `381.370828` | Added `verify_ms` vs $N$ scaling chart and capacity-planning guidance. |
 | `docs/generated/usecase_flows/metadata/flow_summaries.json` (sha256 `d99d1746a4777ce7d79e2c576203c70773da51b053c2dfd6b4649a06801d0d88`) | `$[flow_key=="login"].template_status` | “Mechanics demo only …” | Added explicit guarantee boundary and roadmap for semantics completion. |
 
 ### Deliverable: recommended sources list