How it works
The signing pipeline is small and deliberately boring: hash every file, sign the manifest, publish both the manifest and the verification key.
Step 1

Content is hashed

Every HTML, CSS, JS, WASM, text, JSON and zip file in the signed list is SHA-256 hashed at deployment time. The filenames and their hex digests are recorded in a canonical JSON manifest with sorted keys and deterministic formatting.

Step 2

Manifest is ed25519-signed

The manifest is signed with an ed25519 private key kept off the web server. The signature covers the domain separator BRY-NFET-SX|SITE-INTEGRITY|V2 concatenated with the canonical manifest bytes. The ed25519 public key is published at /site-signer.ed25519.pub.

Step 3

Anyone can verify

Because ed25519 is an asymmetric signature scheme, anyone who fetches the public key and the manifest can verify the signature locally — no secret required. A ready-to-run verifier is published in the qev-platform repo at scripts/verify_site_integrity.py and uses only the Python cryptography library.

Integrity record
The signed integrity record for this site, fetched from /site-integrity.json when this page loads. It is not a hard-coded copy, so the file count and the signed_at timestamp you see below are the deployed ones. Any count or timestamp quoted in the examples further down this page is illustrative only.

The block below is a server-rendered snapshot taken at signing time, so it stays readable with JavaScript disabled. With scripting enabled it is replaced by a live fetch of /site-integrity.json. If the two disagree the live file is authoritative — and either way, verify the signature yourself rather than trusting this page.

{
  "schema": "BRY-NFET-SX-SITE-INTEGRITY-V2",
  "site": "secure.imagineqira.com",
  "signed_at": "2026-08-07T03:43:12.445444+00:00",
  "file_count": 86,
  "public_key": "881de4e7616992f92013b84ba1bbd08280a007b491bde28a46d8a15612d1d326",
  "signature_scheme": "ed25519",
  "note": "Server-rendered summary. Full record at /site-integrity.json"
}
Download integrity record (JSON)
Verify it yourself
Two checks: (1) the ed25519 signature over the manifest, and (2) the SHA-256 of each file. Neither check requires anything beyond the public key and the manifest.

Option A — Run the bundled verifier

The qev-platform repo ships a standalone verifier that does both checks using only the Python cryptography library.

git clone https://github.com/TheArtOfSound/qev-platform
cd qev-platform
uv run python scripts/verify_site_integrity.py --url https://secure.imagineqira.com

Illustrative output on success. The file count is whatever the manifest lists when you run it, so do not treat the number below as a fixed expectation — read it from the record above:

Step 1: ed25519 signature...
  OK
Step 2: SHA-256 file hashes...
  OK (<N> files, matching file_count in the manifest)

VERIFIED. The manifest is signed by the holder of the ed25519 private
key corresponding to the published public key, and every file's SHA-256
matches.

Option B — Verify the signature manually

Fetch the public key and the manifest, then verify the ed25519 signature with any standard library. Python example:

import hashlib, json, urllib.request
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

BASE = "https://secure.imagineqira.com"
DOMAIN = b"BRY-NFET-SX|SITE-INTEGRITY|V2"

# 1. Fetch the public key and the signed manifest.
pub_hex = urllib.request.urlopen(BASE + "/site-signer.ed25519.pub").read().strip().decode()
pub = Ed25519PublicKey.from_public_bytes(bytes.fromhex(pub_hex))
record = json.loads(urllib.request.urlopen(BASE + "/site-integrity.json").read())

# 2. Strip the signature block and reconstruct the signed bytes exactly
#    as the signer did: the domain separator bytes above, with nothing
#    appended to them, immediately followed by COMPACT canonical JSON --
#    sorted keys, separators (',', ':') so there is no whitespace, and
#    ensure_ascii=False. Any other formatting (indent=2, default
#    separators, an extra delimiter after the domain) yields different
#    bytes and pub.verify() below will raise InvalidSignature.
manifest = {k: v for k, v in record.items() if k != "signature"}
canonical = json.dumps(
    manifest, sort_keys=True, separators=(",", ":"), ensure_ascii=False
).encode("utf-8")
signed_bytes = DOMAIN + canonical

# 3. Verify. Raises InvalidSignature on mismatch.
pub.verify(bytes.fromhex(record["signature"]["signature_hex"]), signed_bytes)
print("signature OK")

# 4. Hash every file and compare.
for name, expected in record["files"].items():
    body = urllib.request.urlopen(f"{BASE}/{name}").read()
    actual = hashlib.sha256(body).hexdigest()
    assert actual == expected, f"{name}: {actual} != {expected}"
    print(f"  {name}: OK")

Known discrepancy — trust the construction above, not the prose in the record: the record's signature.canonical_json_note field writes the domain separator with a trailing ||. That is wrong: the signature verifies over the separator with nothing appended to it. That note lives inside the signature block, which is stripped out before signing, so it is not covered by the signature and carries no cryptographic weight either way.

Option C — Just check a single file's hash

If you trust the signed manifest itself (because you already checked the ed25519 signature, or because you're only worried about over-the-wire tampering with a single file), you can just compare a SHA-256 digest with shasum:

curl -s https://secure.imagineqira.com/ | shasum -a 256
# compare against files["index.html"] in the integrity record above
What this does and does not prove
The integrity claim has a specific, bounded meaning. Read it before drawing conclusions.

What it proves

  • The manifest was signed by whoever holds the ed25519 private key whose public half is at /site-signer.ed25519.pub. Anyone can verify this locally.
  • Every byte of every listed file matches its SHA-256 digest in the signed manifest. Tampering with even one byte of any listed file breaks the comparison.
  • The list of signed files is itself bound into the signature, so silently adding or removing files from the manifest breaks verification.
  • The manifest includes a signing timestamp, so you can tell when the operator last signed this version.

What it does NOT prove

  • That the published ed25519 public key belongs to the person you think it does. If you haven't verified the key out-of-band (TLS certificate pinning, prior knowledge, a trusted channel), a sophisticated attacker controlling this page could publish their own key alongside their own forged manifest.
  • That the source code under the hashed HTML/JS is free of bugs. Hash integrity is not code correctness.
  • That files NOT in the signed list are untampered. Files outside the manifest (e.g. third-party search engine verification tokens) are explicitly out of scope.
  • That the operator is trustworthy — only that a specific party with continuous control of one ed25519 key signed a specific manifest at a specific moment.

Where to look next

What is hardened, what is not, and what has never been independently assessed are all stated on the security pages.