We are not asking the public to break ChaCha20-Poly1305 or HMAC-SHA256. Those are well-vetted primitives we deliberately did not invent. We are asking you to find a way to tamper with the bundle, or with the workflow around it, such that our own verifier reports the result as fully trusted. That is the realistic and interesting attack surface, and it is the one a security review actually finds bugs in.
Messages are sealed with ChaCha20-Poly1305 authenticated encryption as provided by the Python cryptography library. No custom cipher. No new primitive. Standard AEAD.
Every file in the bundle is hashed with SHA-256. The hashes are bound together into a manifest that is stable, canonical, and independently verifiable without any secrets.
The manifest is signed with HMAC-SHA256 using a signer secret held only by the publisher. The signature includes a key fingerprint derived from the actual signer key material.
All four files packaged into a single zip for one-click download. Checksum included below.
Download bundle zipThis file records the publish time, reveal time, envelope ID, signer key fingerprint, and the SHA-256 commitment to the reveal token. Download it alongside the bundle.
Download challenge-meta.jsonmkdir -p bry-challenge && cd bry-challenge for f in artifact.json metadata.json manifest.json signature.json; do curl -s -O https://secure.imagineqira.com/challenge/bundle/$f done curl -s -O https://secure.imagineqira.com/challenge/challenge-meta.json
Recompute the SHA-256 of every file listed in the manifest and compare to the published hashes. If the hashes match, those files have not been modified since publication. manifest.json and signature.json are not listed in the manifest (the manifest cannot reference itself, and signature.json signs the manifest).
python3 - <<'EOF'
import hashlib, json
manifest = json.load(open("manifest.json"))
for entry in manifest["files"]:
name = entry["name"]
want = entry["sha256"]
got = hashlib.sha256(open(name, "rb").read()).hexdigest()
print(f"{name}: {'OK' if got == want else 'FAIL'} {got[:16]}...")
EOF
The signer key fingerprint is published in challenge-meta.json. Confirm the signature file references the same fingerprint. Verification of the actual HMAC requires the signer secret, which is published at reveal time along with the master key.
python3 -c '
import json
sig = json.load(open("signature.json"))
meta = json.load(open("challenge-meta.json"))
print("signature fingerprint:", sig.get("key_fingerprint", "(none)"))
print("published fingerprint:", meta["signer_key_fingerprint"])
print("match:", sig.get("key_fingerprint") == meta["signer_key_fingerprint"])'
After reveal, run the built-in bundle verification against the published signer secret. This confirms the manifest HMAC is valid.
uv run python -c '
from bry_nfet_sx.protocol.bundles import verify_bundle_dir
result = verify_bundle_dir(
"./",
signer_provider_mode="local",
signer_secret="<published-signer-secret>",
signer_key_version="challenge-v1",
)
import json; print(json.dumps(result, indent=2))'
Modify any byte of the published bundle — artifact.json, metadata.json, manifest.json, signature.json, or any combination — in such a way that running verify_bundle_dir against the result reports overall_trusted: true, while the bundle is materially different from the one published here. Or find any other path through the BRY-NFET-SX bundle and storage layer that produces a falsely-trusted verdict on tampered content.
This is the realistic attack surface for any solo-built signed-bundle system. It is where actual bugs live: in the parser, the canonicalization, the path resolution, the metadata-consistency rules, the trust-aggregation logic. The published source is part of the in-scope material. So is anything you discover by reading it.
We are not offering this as a challenge to break ChaCha20-Poly1305, HMAC-SHA256, or SHA-256. Those are well-vetted public primitives. Asking the public to break them would be a category error: it conflates "we picked a strong primitive" with "our system is strong," and it would invite the wrong kind of attention from the wrong kind of reader. We use those primitives because they have been analyzed for years by people more qualified than us. We are not asking you to attack them. We are asking you to attack our use of them.
If you do recover the plaintext through some path other than the published key release, that is interesting and we want to hear about it — but the framing of this page is bundle-level workflow attacks, not cryptanalysis.
Email bryanleonard@imagineqira.com with the subject line "Challenge Submission" and include:
verify_bundle_dir) showing overall_trusted: true on the tampered contentCredible findings will be acknowledged publicly on this page and in the security posture document, with attribution you approve.
The bundle is posted. The source is linked. The verifier is the target. See you in seven days.
An earlier version of this page enumerated three challenges: (1) recover the plaintext, (2) forge an HMAC-SHA256 signature, (3) find a workflow flaw. After feedback that (1) and (2) were category errors — asking the public to break ChaCha20-Poly1305 or HMAC-SHA256 is asking for academic-grade cryptanalytic results, not security findings about this system — we removed both and kept only the workflow attack as the actual challenge. Bundling them next to the workflow attack created a false equivalence and would have read as crypto theater to any qualified reader. The honest framing is the one above: we use well-vetted primitives we are not asking you to break, and we are asking you to break our use of them. We are leaving this note in place rather than silently rewriting history.