H33-PQ Verified · Adversarial Vectors

We publish our failures, not just our successes.

Five canonical broken bundles. Five expected failure verdicts. If our verifier ever passes one of these, our verifier is broken — and the public can prove it. That separates H33 from compliance theater.

Vector Count
5
Expected Verdicts
5 / 5 FAILED
Last Verifier Run
all_matched: true
Verifier Version
h33-pq-verify 0.3.0

The Five Vectors

Each tampered bundle is derived from a real H33-PQ Verified Pillar 4 (Privacy) bundle by a single deliberate mutation.

Vector 01

Tampered body — single-character mutation of publishing_rule

EXPECTED · FAILED

A single character in publishing_rule is case-flipped. The schema's const field is byte-locked, so any modification — no matter how small — is detected without secret-key material.

why: publishing_rule does not match schema const
Vector 02

Invalid signature surface — result enum violation

EXPECTED · FAILED

verification_record.result set to "BROKEN" — a value outside the schema enum [PASS, FAIL, PENDING]. Signals a malformed verifier-output binding.

why: verification_record.result not in enum PASS/FAIL/PENDING: BROKEN
Vector 03

Altered evidence-binding hash — non-hex fingerprint

EXPECTED · FAILED

verifier_fingerprint replaced with non-hex characters. The fingerprint MUST match ^[0-9a-f]{96}$ (SHA3-384). Tampering with the binding hash is detected at parse time.

why: verifier_fingerprint not 96-char lowercase hex
Vector 04

Broken authority chain — required field removed

EXPECTED · FAILED

The required top-level field fhe_iq_attestation was removed. Verifier walks the schema's required[] list and refuses to "best guess" a missing structural element.

why: required field missing: fhe_iq_attestation
Vector 05

Schema mismatch — unknown schema_version

EXPECTED · FAILED

schema_version overwritten to a non-published value. The verifier refuses to validate against unknown schemas — no "best guess," no degraded validation, no silent pass.

why: unknown schema_version: h33-pq-verified/wrong-schema/v9.9

Run them yourself

No H33 contact required at any step.

$ curl -sSL https://h33.ai/verifier-cli/install.sh | bash $ h33-pq-verify adversarial \ --vectors-dir https://h33.ai/pq-verified/failure-vectors/

Expected output (excerpt):

{
  "all_matched": true,
  "vector_count": 5,
  "vectors": [
    { "vector": "01-tampered-body",          "expected": "FAILED", "actual": "FAILED", "matches": true },
    { "vector": "02-invalid-signature",      "expected": "FAILED", "actual": "FAILED", "matches": true },
    { "vector": "03-altered-evidence-hash",  "expected": "FAILED", "actual": "FAILED", "matches": true },
    { "vector": "04-broken-authority-chain", "expected": "FAILED", "actual": "FAILED", "matches": true },
    { "vector": "05-schema-mismatch",        "expected": "FAILED", "actual": "FAILED", "matches": true }
  ]
}

If all_matched: false, either the vectors are mis-published or the verifier has regressed. File at security@h33.ai.

Why this exists

Most vendors publish successes. H33 publishes failures too.

A standard whose verifier never says FAIL is not a standard — it's a logo. Adversarial vectors are first-class evidence that the verifier rejects bad inputs the way the standard says it does. If anyone publishes a bundle that fails any of these checks, every verifier in the world will catch it. That's the entire point.