Addendum H
Granite Under Sandstone — Addendum Series
The provenance signal lives in the physics. The attribution architecture lives in the positions. The positions live in a derivation from a seed. The seed is a 256-bit number that a human must generate, store, protect, and never lose.
Everything below the seed is elegant. Everything above the seed is key management. Key management is the graveyard of elegant systems. The hardest problem in cryptography has never been the algorithm. It has been the human holding the key.
Whitfield Diffie did not become famous for inventing public-key cryptography. He became famous for understanding that the hard problem was never the math. It was the key distribution. We face the same problem in a different domain. The math works. The question is whether the humans can hold the secret.
The seed is the root of the derivation tree. Every fingerprint the creator has ever produced or will ever produce derives from this one value. If the seed is obtained by an adversary, the adversary can:
Derive the position set for any image the creator has published, enabling targeted suppression at known positions.
Forge new images with the creator’s position patterns, producing files that the matching service attributes to the creator.
Register fingerprints under a different pseudonym that match the creator’s images, creating competing claims.
Compute fingerprints for images the creator has not yet published, pre-registering claims with earlier timestamps.
Severity: Catastrophic. One secret. Total compromise of all past and future attribution. This is the worst property a secret can have, and it is an intrinsic consequence of deterministic derivation from a single root.
Password managers get breached. Laptops get stolen. Phones are lost. Cloud backups are compromised. Mnemonics are photographed. Sticky notes are found. Every key management failure in the history of cryptography applies to the seed. The seed is exactly as secure as the least secure device or storage medium it has ever touched.
Severity: High. The seed’s security ceiling is determined by the creator’s operational security practices, which vary from excellent (hardware security module) to catastrophic (texted to a friend).
If the creator suspects compromise and rotates to a new seed, all images embedded with the old seed have fingerprints that no longer connect to the new seed. The creator’s corpus splits into two unlinked sets. Linking the old and new identities requires a public declaration: “old pseudonym and new pseudonym belong to the same entity.” That declaration is: additional infrastructure; a permanent record connecting the two identities; and if the old seed was compromised, a bridge between the compromised identity and the new one.
Severity: Medium. Rotation works but it is not free, not seamless, and not private.
There is no certificate authority. There is no revocation list. If the seed leaks, the creator can delete their registrations from matching services, but the fingerprints in the wild still match the leaked seed’s derivations. Anyone holding the leaked seed can register those fingerprints under a new pseudonym. The creator cannot “invalidate” the seed because the seed is not issued by anyone. It is a number. Numbers cannot be revoked.
Severity: High. The absence of revocation is a design choice (no central authority), not an oversight. It is the cost of decentralization. Centralized revocation requires a central authority. The scheme explicitly avoids central authorities. The tradeoff is acknowledged.
In Diffie-Hellman key exchange, ephemeral session keys provide forward secrecy: compromise of the long-term key does not compromise past sessions because each session used a unique ephemeral key that was discarded after use. In this scheme, the seed IS the long-term key, and the fingerprints are deterministically derived from it without ephemeral components. Every fingerprint ever derived is retroactively compromised when the seed is compromised.
There is no mechanism by which a past fingerprint can be made independent of the seed after the fact. The derivation is deterministic and one-way, but it is one-way in the wrong direction for forward secrecy: knowing the seed reveals all fingerprints, but knowing all fingerprints does not reveal the seed.
Severity: High. Forward secrecy is a property the scheme fundamentally cannot provide without introducing ephemeral state, which contradicts the “one seed, deterministic derivation” design.
A 256-bit random seed is computationally infeasible to brute-force. A seed derived from a pet’s name, a birthday, a phone number, or “password123” is trivially brutable. The adversary who knows a fingerprint and an image context needs only brute-force the seed space to derive the seed. With 256 bits of entropy, this is impossible. With 20 bits of entropy (“fluffy2024”), it takes seconds.
The scheme’s security guarantee is conditional on proper seed generation. The library must generate the seed using a cryptographically secure random number generator (CSPRNG) and must not accept user-supplied strings as seeds without explicit key derivation (e.g., PBKDF2, Argon2) that stretches low-entropy input into high-entropy output. Even with stretching, a weak passphrase is a weak passphrase. The library should warn. The library cannot prevent.
Severity: Critical if seed generation is left to the user. Mitigated if the library generates the seed automatically and presents it as a mnemonic or hex string for backup.
The derivation function takes two inputs: the secret seed and the image context. The image is public. If the image context is derived from the image (perceptual hash, dimensions, color space), the adversary can compute it. The adversary now has two of three values: the context (computed from the public image) and the fingerprint (detected from the public image). They need the seed.
HMAC-SHA512 is a pseudorandom function (PRF). Given the output and one input, recovering the other input is computationally equivalent to brute-forcing the key space. With a 256-bit seed, this is infeasible. The dragon is not in the math. The dragon is in potential implementation errors: using a non-PRF derivation, using a truncated seed, or using a predictable seed that reduces the effective key space.
Severity: Low if implemented correctly. Catastrophic if implemented incorrectly. The implementation is the dragon, not the design.
| Dragon | Severity | Mitigable? | By Whom? |
|---|---|---|---|
| 1. Total compromise | Catastrophic | Partially. Hierarchical seeds can limit blast radius. | Library design. |
| 2. Device security | High | Yes. HSM, encrypted storage, hardware tokens. | Creator’s operational security. |
| 3. Rotation cost | Medium | Partially. Pre-planned rotation with linked pseudonyms. | Matching service policy. |
| 4. No revocation | High | No. Fundamental cost of decentralization. | Nobody. By design. |
| 5. No forward secrecy | High | No. Contradicts deterministic derivation. | Nobody. Fundamental tradeoff. |
| 6. Weak seed generation | Critical | Yes. Library enforces CSPRNG generation. | Library implementation. |
| 7. Observable context | Low (if correct) | Yes. Use HMAC-SHA512, full-length seed. | Library implementation. |
Table H1. The seven dragons. Two are mitigable by library design, two by the creator’s operational security, one by matching service policy, and two are fundamental tradeoffs inherent to the decentralized architecture.
Instead of one seed for all images, the creator derives a tree of sub-seeds from a master seed, analogous to BIP-32 hierarchical deterministic wallets:
master_seed
├─ project_seed_A = HMAC(master, "project_A")
├─ project_seed_B = HMAC(master, "project_B")
└─ project_seed_C = HMAC(master, "project_C")
Compromise of project_seed_A exposes only images in project A. The master seed and other project seeds remain secure. The blast radius is limited to one branch of the tree. The cost: the creator must manage multiple project assignments, and the matching service must handle multiple pseudonyms per creator.
This does not solve Dragon 1 for the master seed. Compromise of the master seed compromises all branches. It reduces the probability of total compromise by ensuring that day-to-day operations use branch seeds, not the master. The master seed can be stored offline (cold storage, paper backup) and used only to derive new branches.
The library generates the seed. Not the user. The seed is 256 bits from a CSPRNG. The library presents it as a 24-word BIP-39 mnemonic or a 64-character hex string. The user writes it down. The library does not accept user-chosen passphrases as seeds without explicit key derivation through Argon2 with high work factor.
The first-run experience is: “Your provenance seed has been generated. Write down these 24 words. Store them securely. This is the only secret in the system. If you lose it, attribution cannot be recovered.” Clear. Honest. No jargon. No options that let the user weaken their own security by accident.
The image context used in seed derivation must be:
Stable under compression: The same image compressed to Q75 must produce the same context as at Q95. Otherwise the creator cannot rederive the fingerprint from the compressed version. A perceptual hash (pHash, average hash, DCT hash) satisfies this.
Distinct across content: Two visually different images must produce different contexts. Otherwise an adversary can craft a collision — a different image that produces the same position map from a stolen seed. Perceptual hashes are designed to differ across visually distinct content.
Not invertible: The context should not reveal the seed when combined with the fingerprint. HMAC-SHA512 guarantees this as a PRF property.
The recommended context derivation is:
context = perceptual_hash(image) || dimensions || color_space
This produces a context that is stable under lossy transforms, distinct across content, and computable by the creator at any future time from any surviving version of the image.
If a creator suspects seed compromise, the recommended response is:
1. Generate a new seed. Immediately. Store securely.
2. Register the new pseudonym with matching services. Begin embedding new images with the new seed.
3. Publish a signed transition statement. A public declaration linking old pseudonym to new pseudonym, timestamped and signed with any available authentication (GPG key, social media account, notarized statement). This is not cryptographic proof. It is a human attestation. Courts accept human attestations.
4. Contact matching services to flag the old pseudonym. Request that the old pseudonym be marked as “compromised, transition to [new pseudonym].” The service’s policy determines whether and how to honor this request.
5. Accept the loss. Images embedded with the compromised seed are now in a contested state. The original creator has the transition statement and the registration timestamps. The adversary has the seed. The dispute is not cryptographically resolvable. It is legally resolvable through the weight of evidence: registration history, transition statement, original files, receipts.
This is not a clean recovery. There is no clean recovery from seed compromise in a decentralized system without revocation authority. The protocol is damage limitation, not damage elimination.
Two of the seven dragons cannot be mitigated. They are structural consequences of the design’s core commitments:
No revocation is the cost of no central authority. A system that can revoke credentials has a revocation authority. A revocation authority is a central point of control. The scheme rejects central points of control. Therefore the scheme cannot revoke. This is not an oversight. It is a price paid for a property we value more.
No forward secrecy is the cost of deterministic derivation. A system that provides forward secrecy must use ephemeral state that is discarded after each operation. A system that provides deterministic rederivation from a single seed must not discard anything. The scheme requires deterministic rederivation so that the creator can prove ownership of any past image from the seed alone. Therefore the scheme cannot provide forward secrecy. This is not an oversight. It is a price paid for a property we value more.
Both tradeoffs are instances of a general principle: decentralized systems pay for their decentralization with properties that centralized systems get for free. The scheme accepts these costs because the benefits of decentralization (no lock-in, no authority, no infrastructure dependency) are worth more than the properties sacrificed.
Whether this tradeoff is correct depends on the threat model. For a creator whose primary adversary is corpus-scale ingestion by platforms that ignore provenance, the absence of revocation is irrelevant (the adversary isn’t checking revocation lists anyway). For a creator whose primary adversary is a targeted attacker who steals credentials, the absence of revocation is dangerous. The scheme is better suited to the first threat model than the second. The paper should state this explicitly.
The system has one secret per user. That is the minimum possible secret surface. The derivation is a standard PRF construction (HMAC-SHA512) with a full-length key. The key is never transmitted. The fingerprints are one-way derivations from the key. The design is sound.
The danger is not in the cryptography. The danger is in the operational security of the key holder and in the absence of recovery mechanisms when operational security fails. These are the same dangers that every cryptographic system faces. They are not solved by better algorithms. They are solved by better practices, better tools, and honest documentation of what happens when practices fail.
The scheme documents its dragons. It does not pretend they do not exist. It does not claim robustness it does not have. It states the tradeoffs, explains the costs, and lets the user decide whether the costs are acceptable for their threat model.
The hardest problem in cryptography has never been the algorithm. It has been the human holding the key. We cannot solve the human. We can make the key as simple as possible, the generation as secure as possible, the documentation as honest as possible, and the blast radius as small as possible. The rest is the human’s responsibility. It always was.
No seed management system has been implemented.
The dragons are described because we see them, not because we have slain them.
Some dragons cannot be slain. Only acknowledged.
Jeremy Pickett — March 2026