Open challenge

Here is a sealed packet. Try to forge one.

A ProofRail packet, the verifier that checks it, and the private key kept back. If you can produce a packet that verifies with a payload you chose, you have broken it — and I want to know how.

Run it

Node 18 or newer. No dependencies, no network calls.

curl -fLO https://www.talleyit.com/challenge/challenge-packet.json
curl -fLO https://www.talleyit.com/challenge/verify.mjs
curl -fLO https://www.talleyit.com/challenge/proofrail-crypto-proof.js

node verify.mjs challenge-packet.json

Expected output: VERIFIED.

challenge-packet.json — the sealed packet and public key verify.mjs — the verifier entry point proofrail-crypto-proof.js — seal and verify, node:crypto only

The challenge

Produce a file this verifier reports as VERIFIED, carrying a payload you chose, without the private key. Same shape as the published packet:

{ "payload": { ... }, "proof": { ... }, "public_key_base64_spki": "<unchanged>" }

If node verify.mjs your-file.json prints VERIFIED, you win. Send it to matt@mythicdot.ai and you get the credit.

What is being claimed — precisely

A payload and its Ed25519 signature agree under RFC 8785 canonicalisation, and the signature was produced by the holder of the private key matching the published public key.

Nothing more. It is not claimed that a payment occurred, that funds moved, that a counterparty is solvent, or that anything was delivered. A valid ProofRail packet is evidence of integrity, not of settlement — a distinction written into the product's own claims register, and it holds here.

What already fails

Run before publishing. If you find another, that is the interesting result.

Attack	Result
Tampered payload	`PAYLOAD_DIGEST_MISMATCH`, `CANONICAL_LENGTH_MISMATCH`
Attacker re-signs with their own key	`SIGNATURE_INVALID`
Zeroed signature	rejected
Stripped signature field	rejected
Empty-string signature	rejected
Swapped `payload_sha256`	rejected
`key_id` substitution	rejected
Algorithm downgrade to `none`	rejected
Empty proof object	rejected
Empty payload against a real proof	rejected
Wrong public key	rejected
JSON key reordering	still verifies — canonicalisation working as intended

The realistic surface is RFC 8785 edge cases: unicode escapes, number formats, duplicate keys, deep nesting. If canonicalisation is wrong anywhere, two different payloads share signable bytes and the whole thing falls over. That is where I would look.

Keys

The keypair here was generated for this challenge alone. It is not used by any Talley IT production system, and the private key is not stored on any machine reachable from this site.

Talley IT LLC · Virginia Beach, VA · CAGE 23EL9 · UEI HK9GTULP5GJ2 · matt@mythicdot.ai