blake3

PEER_AUTH_PLAN.md

@@ -31,7 +31,7 @@ not three partially compatible protocol generations.
 | Area | Decision | User-visible result |
 |---|---|---|
 | Filesystem safety | Validate the complete destination manifest before any mutation and confine it to one catalog game root. | A hostile peer cannot overwrite another game, `local/`, saves, or transaction state. |
-| Content authority | Ship SHA-256 file and chunk hashes from the same bundled catalog authority as `game.db`. | Every eligible nearby peer is usable automatically; wrong bytes are rejected and retried elsewhere. |
+| Content authority | Ship BLAKE3 file and chunk hashes from the same bundled catalog authority as `game.db`. | Every eligible nearby peer is usable automatically; wrong bytes are rejected and retried elsewhere. |
 | Peer identity | Use one installation-local TLS key and derive `PeerId` from that TLS public key. | Identity works silently and survives ordinary restarts when possible; users do not manage it. |
 | Transport | Pin every outbound QUIC connection to the expected `PeerId`. | An address spoof or MITM cannot impersonate the peer selected as a source. |
 | Control messages | Use ordinary bounded protocol messages inside TLS. Treat unauthenticated inbound change notifications only as hints that trigger a pinned pull. | No signed-envelope layer, nonce ledger, or message-signing overhead. |
@@ -45,7 +45,7 @@ The resulting data flow is intentionally small:
 mDNS candidate -> responder-pinned TLS -> peer-owned snapshot or file bytes
 
 bundled content manifest -> validated local download plan
-                         -> SHA-256 check for every received chunk
+                         -> BLAKE3 check for every received chunk
                          -> version.ini commit only after complete success
 
 local Call to Play change -> cheap invalidation hint to known peers
@@ -164,16 +164,16 @@ CatalogContentManifest {
     game_version
     chunk_size
     files: [
-        { canonical_path, kind, size, file_sha256, chunk_sha256[] }
+        { canonical_path, kind, size, file_blake3, chunk_blake3[] }
     ]
     streamed_install_files: [
-        { canonical_path, kind, size, file_sha256 }
+        { canonical_path, kind, size, file_blake3 }
     ]
     content_id
 }
 ```
 
-Entries are sorted by canonical path. `content_id` is SHA-256 over a
+Entries are sorted by canonical path. `content_id` is BLAKE3 over a
 versioned, length-delimited encoding of all preceding manifest fields and
 hashes, excluding the `content_id` field itself; it is not the current
 noncryptographic `u64 manifest_hash`. Golden tests freeze that encoding. The
@@ -221,7 +221,7 @@ files” progress, not a security decision.
 
 Streamed install needs a catalog-owned extracted-file manifest because the
 sender controls both today's RAR CRC32 metadata and extracted bytes. The
-receiver accepts exactly the expected path set, sizes, and SHA-256 values in
+receiver accepts exactly the expected path set, sizes, and BLAKE3 values in
 isolated staging, then applies the documented local account/language rewrite
 and promotes the transaction. CRC32 may remain as an early corruption check,
 but it is not the security boundary. A game without a verified extracted
@@ -244,7 +244,7 @@ not exposed as a user credential.
   responder-verification path. Otherwise use one supported P-256 TLS key. Do not
   add a second signing identity or a custom certificate-extension binding.
 - Define `PeerId` as lowercase unpadded base32 of
-  `SHA-256(canonical DER SubjectPublicKeyInfo)` from the actual TLS key. The
+  `BLAKE3(canonical DER SubjectPublicKeyInfo)` from the actual TLS key. The
   same key is therefore both the identity and the TLS proof-of-possession key.
 - Validate on load that the private key, certificate SPKI, and derived ID
   agree. Never log private material.
@@ -497,7 +497,7 @@ reported as Windows proof.
 Add the reproducible content-manifest generator and fixture manifests. Freeze
 the versioned manifest/content-ID encoding with golden tests. Extend local
 catalog state, build download plans only from that state, implement streaming
-SHA-256 checks and source quarantine, and implement verified extracted
+BLAKE3 checks and source quarantine, and implement verified extracted
 manifests for Stream Install.
 
 Do not claim completion from test fixtures alone: production catalog packages