ⰜⰓⰉⰒⰕⰑ ⰜⰘⰀⰎⰎⰅⰐⰃⰅⰔ

ⰜⰓⰉⰒⰕⰑ ⰜⰘⰀⰎⰎⰅⰐⰃⰅⰔ — ⰔⰘⰑⰂⰐ ⰋⰐ ⰗⰖⰎⰎ ⰄⰅⰕⰀⰋⰎ, ⰂⰋⰕⰘ ⰋⰕⰔ ⰒⰓⰑⰑⰗ: Ⰰ ⰄⰅⰕⰅⰓⰏⰋⰐⰋⰔⰕⰋⰜ ⰜⰑⰐⰕⰅⰐⰕ-ⰀⰄⰄⰓⰅⰔⰔ ⰓⰅⰜⰑⰏⰒⰖⰕⰀⰁⰎⰅ ⰗⰓⰑⰏ ⰕⰘⰅ ⰜⰑⰏⰒⰑⰐⰅⰐⰕ'Ⱄ ⰐⰀⰏⰅ.

Double Torus · local realtime crypto analysis

Crypto challenges — red-teaming our own content-address, live

Three waves, run in your browser — no server, no tokens, deterministic. Each EXPLOITS a real weakness in the FNV content-address and shows the SHA-256/Ed25519 fix (already built in src/0) resisting it. Not a claim: the collision is found by search, the bit-budget computed, the forgery minted.

Wave 1 · exploit

Watch a collision happen

Forge a collision: two distinct inputs sharing a content-address word.

searching…0 seeds hashedscaled to 16-bit

Verified (full 32-bit word):i3jz ≡ k8r5 → 3315175185 (20 ≈ log₂ tries)

solution SHA-256 does NOT collide the pair: 18136dfadd44… ≠ d063ea7065b2…

hash32 (FNV-1a core + a MurmurHash3 finalizer) is fast and well-distributed but not collision-resistant.

Wave 2 · audit

"128 bits" is really 122

Quantify the collision resistance behind the "128-bit / maximum tampering cost" claim.

• toUuid (this site)122-bit · collision ~2⁶¹
• toUuidSha256128-bit · collision ~2⁶⁴
• sha256 (full)256-bit · collision ~2¹²⁸

toUuid masks 6 bits (UUID version + variant) → 122 effective bits → birthday ~2^61; and hash32 has no cryptanalytic resistance, so the true cost is at or below that. — the 6 masked bits are the UUID version nibble + 2 variant bits; bit-WIDTH is not security strength.

Wave 3 · forge

Mint a valid root for tampered content

Prove a root is YOURS — that an authority, not just anyone, produced it.

authorized82e840af-8a04-82d1-94c8-9d12bcb28c82valid uuid

tamperede7d9e281-7a4c-8c00-ba03-07ac6f980c8dvalid uuid

Content-addressing gives integrity, not authenticity: the function is public + deterministic, so an adversary recomputes a valid root for tampered content (both roots below are equally valid).

solutionEd25519 signing (ed25519Sign/Verify, built in src/0): a root SIGNED by a private key cannot be forged without it. HONEST RESIDUAL: needs persistent key custody (deployment, not code).

• The collision is FOUND, not asserted: a deterministic birthday search returns two distinct seeds whose 32-bit content-address word is identical (the 32-bit birthday bound is ~2^16). A non-cryptographic hash (FNV-1a) gives no collision resistance — the FNV spec itself says "not suitable for cryptographic use".
• Bit-width is not security strength. The "128-bit" toUuid masks 6 bits (the UUID version nibble + 2 variant bits), so its effective width is 122 bits and its birthday-collision bound is ~2^61 — feasible for a resourced adversary (SHA-1, 160-bit, was broken at ~2^63 by SHAttered), where SHA-256 (2^128) is not.
• Integrity is not authenticity. A content-address proves content maps to a root (any honest party recomputes it); it does NOT prove WHO produced it — anyone can mint a valid root for tampered content. Authenticity needs a signature (Ed25519), where forging requires the private key. (Git's author: its hash "has nothing to do with security".)
• Every solution is already built and verified in src/0 — sha256Sync / toUuidSha256 (the drop-in), sha256MerkleRoot / verifySha256Proof, ed25519Sign / Verify, the transparency-log structure. The found collision does NOT collide under SHA-256: the same cheap attack fails against the vetted hash. The residual is a deliberate cutover + key custody, not missing cryptography.

• Do NOT read the found 32-bit collision as a full toUuid break: it collides ONE of the four words, proving the building block is weak; a full 128-bit collision is ~2^61 (computed, not brute-forced here), not demonstrated by this pair.
• "Maximum tampering cost / T_max = ∞" as a SECURITY claim is refused: against an adversary the FNV forge cost is ≤2^61 and likely far less, not infinite. The honest claim is tamper-EVIDENT plus the reproduction cost, not cryptographic unforgeability.
• The cutover is NOT performed here. Migrating toUuid → toUuidSha256 globally is a deliberate breaking change that invalidates every committed baseline; these challenges prove the fix RESISTS the exploit, they do not flip the default.

red-teamed ✓ The crypto challenges, red-teamed in waves: each EXPLOITS a real weakness in the site's content-address and GENERATES the solution already built in src/0, proving the fix resists. Wave 1 FINDS a collision in the FNV building block (SHA-256 does not collide the same pair); wave 2 computes that the "128-bit" address is really 122 bits (birthday ~2^61, not 2^128); wave 3 mints a valid root for tampered content, exposing that integrity is not authenticity (the fix is Ed25519 signing). Not assertions — runnable exploits with the vetted fix beside each.

✓ proven · content-address f395bee2-8e68-8581-8d83-2a8f24868697 — declared, placed, mounted, and recomputable from the component's name.