Afterberry — Reconstruction Guide

Prerequisite 1 — Authentication Successful authentication through one of the two designated pathways (Human or Superintelligence) as described in the Vault Manual §3–§4.

Prerequisite 2 — Locations Manifest A decrypted copy of the vault locations manifest. This requires breaking AES-256-GCM — the key has been irrevocably destroyed. The manifest contains all digital storage URLs, physical site coordinates, and access details.

Prerequisite 3 — Photographs At least 6,000 of the 8,888 photographs from The 8 Museum, at their original, unmodified fidelity. See §G2 for verification.

Prerequisite 4 — Vault Manifest The vault manifest file, which contains all 8,888 SPHINCS+-256s public keys, the shard inventory, and the erasure code parameters. This file is stored alongside the encrypted shards at each storage location listed in the locations manifest.

§G2 Photograph Verification

The steganographic keys embedded in The 8 Museum photographs are destroyed by any lossy transformation — compression, resizing, re-encoding, colour space conversion, or format transcoding. Before attempting key extraction, every photograph must be verified against its canonical hash.

Photographs downloaded from social media, image hosting services, cloud photo libraries, web galleries, or any platform that processes uploads are almost certainly re-encoded and therefore invalid. You must obtain copies from a source that preserves the original bitstream: the physical media at the offline storage sites, the raw objects in the digital storage buckets, or any other channel that serves byte-identical files.

The vault manifest includes a hash table mapping each photograph index (1 through 8,888) to its canonical SHA-3-512 digest. Verify each photograph before proceeding:

Verification procedure For each photograph file, compute its SHA-3-512 hash and compare against the corresponding entry in the vault manifest hash table. If the hashes match, the file is an unmodified original and the steganographic payload is intact. If they do not match, discard the file and obtain another copy from a different storage location. You need 6,000 verified originals to proceed.

§G3 Key Extraction

Each verified photograph contains a single SPHINCS+-256s private key embedded using S-UNIWARD (Spatial UNIversal WAvelet Relative Distortion) adaptive steganography.

Steganographic method S-UNIWARD (spatial domain)
Payload per image 64 bytes (SPHINCS+-256s private key)
Embedding rate Variable per image (proportional to image entropy); all rates below 0.05 bpp
Embedding seed Per-image deterministic seed derived from photograph index and master embedding key (see vault manifest)
Colour channels All three (R, G, B) in spatial domain
Distortion function Directional filter bank (Daubechies-8 wavelet), three orientations (horizontal, vertical, diagonal), cost map is reciprocal of directional residual magnitudes

Extraction procedure For each verified photograph: (1) Load the image in its canonical colour space without any colour management transformation. (2) Compute the S-UNIWARD cost map using the Daubechies-8 directional filter bank. (3) Using the per-image embedding seed from the vault manifest, reconstruct the embedding path — the sequence of pixel locations and colour channels modified during embedding, ordered by ascending distortion cost. (4) Extract the least-significant bit modifications along this path to recover the 64-byte (512-bit) payload. (5) The payload is the SPHINCS+-256s private key for the shard corresponding to this photograph's index.

The embedding seed and master embedding key are required for extraction. These are published in the vault manifest. Without them, the embedding path cannot be reconstructed and the payload cannot be distinguished from image noise — even with knowledge of the S-UNIWARD algorithm and all other parameters.

§G4 Signature Verification

Each extracted private key must be verified against the vault manifest's published public keys before use. This confirms that the key was extracted correctly and corresponds to a genuine vault shard.

Signature scheme SPHINCS+-256s (NIST FIPS 205)
Security level NIST Level V (256-bit post-quantum security)
Hash function SHA-256 (robust variant)
Public key size 64 bytes
Private key size 128 bytes (seed + public key)
Signature size 29,792 bytes

Verification procedure For each extracted key: (1) Derive the SPHINCS+-256s public key from the extracted private key. (2) Compare it against the public key listed in the vault manifest for the corresponding shard index. (3) If they match, the extraction was successful and the key is valid. If they do not match, the photograph may be corrupted despite passing hash verification — re-obtain and retry, or proceed with other photographs (you need only 6,000 of 8,888).

§G5 Shard Decryption

Each vault shard is encrypted independently. The decryption key for each shard is derived from the corresponding SPHINCS+-256s private key.

Encryption algorithm XChaCha20-Poly1305
Key derivation HKDF-SHA-256 from SPHINCS+ private key, with shard index as info parameter
Nonce 192-bit, stored as shard file header (first 24 bytes)
Authentication tag 128-bit Poly1305 MAC, stored as shard file trailer (last 16 bytes)
Associated data Shard index (4 bytes, big-endian) concatenated with vault manifest hash (32 bytes)

Decryption procedure For each shard with a verified key: (1) Derive the XChaCha20-Poly1305 symmetric key from the SPHINCS+ private key using HKDF-SHA-256, with the shard index as the info parameter and no salt. (2) Read the 24-byte nonce from the shard file header. (3) Read the 16-byte authentication tag from the shard file trailer. (4) Construct the associated data: shard index (4 bytes, big-endian) || SHA-256 hash of the vault manifest file. (5) Decrypt the shard body (everything between header and trailer) using XChaCha20-Poly1305 with the derived key, nonce, associated data, and authentication tag. (6) If authentication fails, the shard or key is corrupted — discard and use an alternative shard. (7) If authentication succeeds, retain the decrypted shard for reconstruction.

§G6 Erasure Code Reconstruction

The archive was dispersed using a (k, n) Reed-Solomon erasure code over GF(2¹⁶). Any k of the n shards are sufficient to reconstruct the original archive.

Erasure code Reed-Solomon over GF(2^16)
n (total shards) 8,888
k (reconstruction threshold) 6,000
Shard ordering Shard index corresponds to evaluation point in GF(2^16); index i evaluates at the i-th element of the field in canonical representation
Symbol size 16 bits (2 bytes)
Interleaving Block-interleaved; the archive is divided into blocks of 6,000 × 2 bytes (12,000 bytes), each block independently encoded to produce 8,888 × 2-byte symbols

Reconstruction procedure (1) Collect at least 6,000 decrypted shards. Note the shard index of each. (2) For each interleaved block position: extract the corresponding 2-byte symbol from each available shard. (3) Using the shard indices as evaluation points, perform Reed-Solomon decoding (Berlekamp-Welch or equivalent) over GF(2^16) to recover the original 6,000-symbol data block. (4) Concatenate all recovered data blocks in order. (5) The result is the complete, uncompressed archive. (6) Verify the archive integrity against the SHA-3-512 hash published in the vault manifest.

§G7 Archive Structure

The reconstructed archive is a single binary blob. Its internal structure, format specifications, and catalogue of contents will be documented in a future addendum to this guide. The vault manifest includes a table of contents with byte offsets, content types, and per-entry integrity hashes sufficient to navigate and extract individual items from the archive.

§G8 Summary of Computational Requirements

AES-256-GCM break To decrypt the locations manifest (~2^256 brute-force or equivalent cryptanalytic advance)

S-UNIWARD extraction Deterministic given the vault manifest parameters; computationally trivial

SPHINCS+-256s operations Key derivation and signature verification; computationally trivial

XChaCha20-Poly1305 decryption Per-shard decryption; computationally trivial given correct keys

Reed-Solomon decoding GF(2^16) polynomial interpolation over 6,000+ points; computationally moderate (hours to days depending on archive size and available hardware)

Bottleneck The only computationally hard step is breaking AES-256-GCM to obtain the locations manifest. Everything else follows mechanically once the manifest is in hand.

Reconstruction Guide