Authenticating and Timestamping FWG Outputs

Authenticating and Timestamping FWG Outputs

External integrity, signatures, and trusted-time evidence are optional layers around FWG outputs. For ordinary sound design, keeping the WAV, JSON sidecar, project files, backups, and normal storage/version history is usually enough.

This is optional crypto-geek territory

⚠️ FWG does not require cryptographic signing or trusted timestamping for ordinary sound-design work.

For most users, normal file history is already the practical answer to the provenance question. Cloud storage commonly records upload/synchronisation times, version history, account ownership, sharing history, and other provider metadata. DAW projects, backups, source-control history, messages, publication, transfers, and other ordinary records can provide additional corroboration. In everyday use, that evidence is usually easier to preserve, easier to understand, and more useful than maintaining a personal cryptographic signing workflow.

The remaining sections cover stronger cryptographic integrity, external timestamping, archival evidence, and machine-verifiable attestations. They are deliberately outside FWG's normal workflow.

Cloud/provider metadata should still be understood as ordinary third-party provenance rather than a cryptographic property of the FWG file itself. Provider retention policies, account access, exports, copies, and metadata behaviour vary.

FWG already provides the material to authenticate

🔧 An FWG export can already contain an export UUID, application version, a per-result created_utc value, the concrete patch/Morph/render state, and a random seed or other generation context where applicable. The exact WAV and JSON bytes can then be hashed externally.

A compact detached authentication manifest could therefore identify a single ordinary WAV/JSON pair with fields conceptually equivalent to:

export_uuid
random_seed: <exact seed text or null>
created_utc
sha256_wav
sha256_json

This is an example of what an external authentication record might commit to. It is not a new FWG JSON schema, required sidecar, import format, or promised FWG file format.

schema_version is not needed for this detached authentication purpose when the exact JSON bytes are hashed. Schema version remains useful inside FWG JSON for import and migration. The application version recorded in the authenticated JSON identifies the FWG release used for reconstruction; where byte-exact executable identity matters, an archived build or trusted release hash can identify the exact program bytes separately.

Likewise, information already contained inside the hashed JSON does not have to be duplicated in a detached manifest unless duplication makes human review or indexing easier.

Integrity, signatures, and trusted time are different claims

🔧 These mechanisms answer different questions:

• SHA-256 digest: do these bytes still match the bytes that were hashed?
• Digital signature: did the holder of a particular private key sign this commitment?
• Trusted timestamp: did an external timestamping mechanism receive or anchor this commitment no later than a particular time?
• Ordinary provenance: what do project files, cloud history, backups, transfers, publication, correspondence, or chain of custody say about possession and use?

A hash alone does not prove who created a file or when it was created. A local created_utc value records the browser's claimed wall-clock time but does not certify that clock. A trusted timestamp can corroborate existence by a time, but it does not automatically identify the creator.

Optional external approaches

🔧 A user or third party can authenticate FWG material without any change to FWG itself.

Possible approaches include:

• signing a detached manifest with a user-controlled signing key;
• submitting a digest or manifest commitment to an RFC 3161-style timestamp authority;
• anchoring a digest with OpenTimestamps or another public timestamp/transparency system;
• using an identity-bound signing or transparency service;
• preserving the hashes and files in an institutional archive or evidence-management system; or
• combining cryptographic records with ordinary cloud, project, publication, and transfer history.

FWG does not endorse or depend on any one service. Long-term suitability, key management, identity rules, retention, availability, and verification procedures belong to the external system chosen by the user.

Including an owner or identity claim

An external manifest may include an asserted owner, creator, project, organisation, account identifier, or other identity text before the manifest is hashed, signed, or timestamped. Doing so cryptographically binds that exact identity claim to the rest of the commitment.

For example, a timestamp can establish that a deliberately fictional statement containing owner = Alice Example existed by the timestamped time. It does not, by itself, prove that the real Alice Example authored or authorised the statement. That stronger identity claim normally needs a signature from a key associated with Alice, an identity-bound signing service, account/provider evidence, or other corroboration.

This distinction is useful because proof of existence, proof of integrity, and proof of identity are separate problems.

Signing or timestamping a whole FWG ZIP

A ZIP full of FWG outputs can be authenticated in at least two useful ways.

Authenticate the exact archive

Hash or sign the exact ZIP bytes:

sha256_zip = SHA-256(exact ZIP file bytes)

This authenticates that exact archive. Recompressing or repacking the same constituent files can produce a different ZIP hash because compression details, ordering, extra fields, or ZIP timestamps may differ.

Authenticate the package contents

Alternatively, a detached package manifest can list the relative path and SHA-256 digest of every file in the package, optionally together with the package/run UUID and other identifying metadata. That authenticates the content set independently of the exact ZIP container and can survive repackaging when the contained files themselves remain byte-identical.

A user can record both the constituent-file manifest and the exact ZIP hash when both properties matter.

Clean first, authenticate second

⚠️ If a JSON sidecar will be privacy-cleaned or otherwise intentionally transformed, make that final sharing/archive copy before calculating the digest, signature, or timestamp commitment.

Removing runtime_environment, source filenames, or other metadata changes the JSON bytes and therefore changes sha256_json. That is correct behaviour: authentication should describe the exact artifact actually being retained or distributed.

See Sharing and Cleaning JSON Sidecars.

Why FWG does not sign its own outputs

🔧 A self-contained browser application cannot safely contain one secret "FWG signing key." Any private key distributed inside the HTML would also be distributed to every user and could be extracted and used to sign arbitrary material. Such a signature would not authenticate an official FWG generation event.

Generating permanent user signing keys inside FWG would create a different class of application responsibility: private-key storage, protection, export, backup, recovery, revocation, identity binding, portability, loss, and possibly password handling. Those are substantial security and support obligations unrelated to wavetable synthesis.

Trusted time has an additional structural problem: the browser cannot independently certify its own local clock. A meaningful trusted timestamp requires some external trust anchor, timestamp authority, transparency log, public ledger, archival service, or equivalent corroborating system.

Keeping authentication external also preserves important FWG properties:

• FWG remains usable as one self-contained local file:// application;
• sound generation and reproduction do not depend on a network service;
• no signing provider becomes part of the deterministic render contract;
• users can choose the trust model appropriate to their own archive, organisation, jurisdiction, or threat model; and
• future authentication tools can evolve without changing FWG patch or render compatibility.

FWG therefore records reproducible evidence and leaves trust in that evidence to systems designed for authentication.

FWG randomisation is not an authentication system

⚠️ FWG-SHA256-v1 uses SHA-256 as a public deterministic mixing primitive for named random draws. It has no secret key and is intentionally reproducible by anyone who knows the inputs. The fact that SHA-256 is used internally does not make a seed, sidecar, draw trace, UUID, or rendered file signed or tamper-evident.

The same distinction applies to a local timestamp or time-derived filename token. Binding a claimed time into some deterministic identifier can make later alteration of that field change the identifier, but it cannot authenticate the clock that supplied the time.

See Randomisation and Seeds and Proof of Zero Prior-Work Knowledge and Forensic Evidence.

Deterministic or time-derived UUIDs are a separate design question

An export UUID currently serves a simple purpose: identifying one particular export event. Re-rendering the same material can legitimately create another export identity.

It is technically possible for an external tool to derive a UUID-like identifier from a deterministic commitment involving values such as a seed, timestamp, and run number. That may be useful for a specialised archive or third-party workflow, but it changes the meaning of the identifier and raises additional canonicalisation questions: which timestamp, which seed when several exist, how null is encoded, how run numbers behave after cancellation/retry, and exactly which bytes are committed.

FWG therefore does not currently make its export UUID a deterministic authentication token. A third party that needs such an identifier can define and version its own construction without changing FWG's export-identity contract.

What external authentication still cannot prove automatically

Even a properly signed and externally timestamped record should not be overstated. Depending on the mechanism, it may establish integrity, key possession, an identity-bound signature, or existence by a certain time. It does not automatically prove:

• that the signed material was the first or only version ever created;
• that a particular human personally operated FWG;
• that an uncompromised official FWG build historically generated the files;
• that no downstream edits or external selection occurred;
• ownership or legal rights in the resulting sound; or
• the legal significance of the evidence in a particular dispute.

Those questions still depend on the exact claim being made and, where relevant, ordinary provenance and chain of custody.

For the narrower FWG reproducibility and source-blind-generation claims, see Proof of Zero Prior-Work Knowledge and Forensic Evidence.