PVTL — Paper-Verified, Transparency-Ledger Voting System

Shannon Bray

Written by
December 23, 2025

PVTL-X: Paper-Verified, Transparency-Ledger Voting

0. Security axioms and scope

A0.1 Software independence

PVTL-X satisfies the classic software-independence requirement: an undetected change/error in software cannot cause an undetectable change/error in the election outcome. NIST+1

A0.2 Evidence hierarchy

  1. Paper ballots (voter-verified) are authoritative.

  2. Audits validate the reported outcome against paper (RLA preferred). NIST+2NIST+2

  3. Cryptographic transparency makes post-election alteration of digital artifacts detectable (does not replace paper).

A0.3 Scope

  • In-person voting with paper ballots (hand-marked default; BMD for accessibility optional).

  • No remote casting over the internet.

  • A public “ledger” that is an append-only transparency log (Certificate Transparency style), not a blockchain for vote storage. RFC Editor+1

1. System roles and trust boundaries

1.1 Roles

  • Voter: marks/validates paper ballot.

  • BMD (optional): accessible ballot marking; prints paper ballot.

  • Scanner: creates CVRs and precinct totals; exports signed bundles.

  • EMS: ballot definition, aggregation, reporting.

  • RLA authority: generates public randomness, selects sample, records discrepancies.

  • Transparency Log (TL): append-only Merkle log of artifacts (hashes + signed metadata).

  • Witnesses: independent entities that co-sign TL checkpoints to prevent equivocation.

1.2 Boundaries

  • Polling place boundary: offline-first, removable media export, strong physical controls.

  • Central boundary: aggregation & publishing; keys controlled via ceremony; immutable storage.

  • Public boundary: anyone can verify TL consistency + inclusion proofs; recompute tallies when CVRs are publishable.

2. Threat model (high-assurance coverage)

PVTL-X is designed to detect and correct outcome-impacting failures, not merely “harden software.”

T1. Malicious or faulty ballot marking (BMD compromise)

  • Attack: BMD prints choices differing from voter intent.

  • Mitigation: paper review is primary; RLAs detect systematic mismatch; optional “challenge/spoil” increases attacker risk.

T2. Scanner/tabulator misinterpretation

  • Attack: mark misread; wrong ballot style; firmware tampering.

  • Mitigation: ballot-level comparison RLA detects discrepancies; device attestation + published build hashes reduce covert changes.

T3. EMS aggregation manipulation

  • Attack: alter results files; swap CVRs; change adjudication outcomes.

  • Mitigation: deterministic recomputation from committed CVRs; TL commits of all EMS artifacts; witness-co-signed checkpoints detect post-hoc changes.

T4. Post-election artifact alteration (results/CVRs/logs)

  • Attack: modify digital records after Election Day.

  • Mitigation: CT-style append-only log with public proofs; independent mirroring; consistency proofs; witness signatures. RFC Editor+1

T5. Chain-of-custody attacks (ballot removal/substitution)

  • Attack: swap ballots; tamper with containers; break seals.

  • Mitigation: strict accounting + signed custody events committed to TL; RLAs rely on correct manifests; escalation to recount.

T6. Privacy/coercion/vote selling

  • Attack: receipts enable coercion.

  • Mitigation: TL never logs voter-identifying info; no per-voter receipts; ballot IDs are random at scan-time and do not link to voter.

T7. Equivocation by log operator

  • Attack: show different log histories to different observers.

  • Mitigation: witness-co-signed checkpoints + gossip/mirroring; inconsistency detectable. IETF Datatracker+1

T8. Insider threats

  • Attack: single admin can rewrite artifacts, re-sign, or change definitions.

  • Mitigation: threshold keys, separation of duties, dual control, public commitments, witness federation.

3. Cryptographic suites (mandatory + optional)

3.1 Hashes

  • SHA-256 required for artifacts and Merkle tree nodes (primary).

  • Optional: SHA-512/256 for environments requiring SHA-2 diversity.

3.2 Signatures (two-tier)

Tier A (device & witness)

  • Ed25519 (recommended) OR ECDSA P-256 (interop).

  • Reason: fast, widely supported; Ed25519 avoids many ECDSA pitfalls.

Tier B (post-quantum readiness, optional research mode)

  • ML-DSA (Dilithium) where available (hybrid signing with Ed25519).

  • Reason: research-grade forward-compat; not required for correctness today.

3.3 Canonicalization

  • Canonical JSON per RFC 8785 (JCS) for all JSON objects before hashing/signing.

  • Any non-JSON binaries: hash raw bytes, referenced by digest in manifests.

3.4 KDF / RNG

  • HKDF-SHA-256 for deterministic sampling streams from public seeds.

  • CSPRNG: OS-grade entropy (scanner/BMD) for internal nonces.

4. Data standards alignment (recommended)

Where possible, align data objects with NIST Common Data Formats:

  • Ballot Definition (BD)

  • Cast Vote Records (CVR)

  • Election Results Reporting (ERR) NIST Publications

PVTL-X adds cryptographic wrappers (hash/signature manifests) around these objects.

5. Core objects and message formats (normative)

5.1 Identifiers

  • election_id: UUIDv7

  • jurisdiction_id: {state, county, district} plus locally defined codes

  • device_id: stable hardware identity (not network address)

  • ballot_style_id: SHA256(Canonicalize(style_descriptor))

5.2 Ballot Definition Package (BDP)

Payload: NIST BD (or jurisdiction BD), plus scanner parameters. NIST Publications

{ "type": "BDP", "schema": "[email protected]", "election_id": "...", "jurisdiction_id": "...", "ballot_style_id": "...", "bd": { /* NIST BD object */ }, "scanner_tuning": { /* mark thresholds, geometry, version */ }, "created_at": "2026-11-03T00:00:00Z" }

Canonicalization: RFC8785
Digest: bdp_hash = SHA256(JCS(BDP))

5.3 Device Attestation Statement (DAS)

A device produces a measured boot attestation (e.g., TPM quote) and binds it to the election context.

{ "type": "DAS", "election_id": "...", "device_id": "...", "device_role": "BMD|SCANNER|EMS", "attestation": { "mechanism": "TPM2_QUOTE", "pcr_selection": "sha256:0,2,4,7,11,12", "pcr_digest": "base64...", "quote": "base64...", "nonce": "base64..." }, "software": { "os_image_hash": "hex...", "app_bundle_hash": "hex...", "sbom_hash": "hex..." }, "timestamp": "..." }

Signature: sig_device = Sign(SK_device, SHA256(JCS(DAS)))

5.4 Cast Vote Record (CVR)

Use NIST CVR format (recommended) with a PVTL wrapper for cryptographic linkage. NIST Publications

{ "type": "CVR", "schema": "[email protected]", "election_id": "...", "ballot_style_id": "...", "cvr": { /* NIST CVR object */ } }

Digest: cvr_hash = SHA256(JCS(CVR))

5.5 Random Ballot Identifier (RBID) assignment (privacy-preserving)

RBID is assigned at scan time:

  • r ← CSPRNG(128 bits)

  • rbid = base32(r)

RBID MUST NOT encode:

  • voter identity

  • check-in order

  • timestamp (in a reversible way)

  • precinct (unless required for retrieval, in which case only as separate metadata)

5.6 Ballot Record (BR) (ballot-level audit handle)

BR binds RBID to a CVR hash and (optionally) ballot image hashes.

{ "type": "BR", "election_id": "...", "scanner_id": "...", "rbid": "...", "batch_id": "...", "container_id": "...", "ballot_style_id": "...", "cvr_hash": "hex...", "image_hash_front": "hex...", "image_hash_back": "hex...", "scan_time": "..." }

Digest: br_hash = SHA256(JCS(BR))
Signature: sig_scanner = Sign(SK_scanner, br_hash)

5.7 Precinct Results Report (PRR)

{ "type": "PRR", "election_id": "...", "precinct_id": "...", "scanner_ids": ["..."], "tally": { /* contest -> totals */ }, "cvr_set_hash": "hex...", "ballot_manifest_hash": "hex...", "timestamp": "..." }

Sign by scanner quorum or precinct authority key.

5.8 Export Bundle Manifest (EBM)

All exports are content-addressed and signed.

{ "type": "EBM", "election_id": "...", "export_id": "UUIDv7", "origin_device_id": "...", "files": [ {"name":"bdp.json","sha256":"..."}, {"name":"cvr.jsonl","sha256":"..."}, {"name":"br.jsonl","sha256":"..."}, {"name":"prr.json","sha256":"..."}, {"name":"das.json","sha256":"..."} ], "created_at": "..." }

ebm_hash = SHA256(JCS(EBM))
sig_export = Sign(SK_origin, ebm_hash)

6. Transparency Log (TL) protocol (normative, CT-style)

PVTL-X uses a Certificate Transparency-like append-only Merkle log: inclusion proofs, signed tree heads, consistency proofs. RFC Editor+1

6.1 Leaf structure

A TL leaf commits to an artifact (or artifact set) by digest.

{ "type": "TL_LEAF", "election_id": "...", "entry_type": "BDP|DAS|BR_BATCH|CVR_SET|PRR|EMS_REPORT|RLA_SEED|RLA_SAMPLE|RLA_DISC|CUSTODY", "artifact_sha256": "hex...", "artifact_size": 123456, "originator": {"role":"SCANNER|EMS|RLA|CUSTODY","id":"..."}, "timestamp": "..." }

Leaf hash follows CT conventions:

  • LeafHash = SHA256(0x00 || SHA256(JCS(TL_LEAF)))

  • NodeHash = SHA256(0x01 || LeftChild || RightChild)
    (Using prefix bytes to avoid second-preimage structure collisions; consistent with CT design patterns. RFC Editor)

6.2 Signed Tree Head (STH)

{ "type": "STH", "tree_size": 12345, "root_hash": "hex...", "timestamp": "...", "log_id": "hex(SHA256(PK_log))" }

sth_hash = SHA256(JCS(STH))
sig_log = Sign(SK_log, sth_hash)

6.3 Witness-co-signed checkpoints (anti-equivocation)

A checkpoint bundles:

  • STH

  • log signature

  • witness signatures

{ "type": "CHECKPOINT", "sth": { ... }, "sig_log": "base64...", "witness_sigs": [ {"witness_id":"W1","sig":"base64..."}, {"witness_id":"W2","sig":"base64..."} ], "policy": { "threshold": 2, "witness_set": ["W1","W2","W3"] } }

Clients accept an STH only if witness policy threshold is satisfied.

6.4 TL endpoints (API surface)

  • submit_leaf(leaf) → returns Signed Acceptance Token (SAT)

  • get_sth() → current checkpoint

  • get_inclusion_proof(leaf_hash, tree_size) → audit path

  • get_consistency_proof(old_size, new_size) → append-only proof

  • get_leaf_by_hash(leaf_hash) → leaf payload

(Modeled directly on CT concepts; you can implement per RFC6962 and bis drafts.) RFC Editor+1

6.5 Mirroring and gossip

  • Any observer can mirror leaf stream + checkpoints.

  • Witnesses and mirrors “gossip” STHs; any split-view is provable.

7. Election workflow (high assurance)

7.1 Pre-election (configuration and key ceremonies)

  1. Generate election keys:

    • K_log (log signing)

    • K_witness_i (witness signing)

    • K_device per device (scanner/BMD)

    • Optional threshold keys for EMS publication

  2. Commit configuration artifacts to TL:

    • BDP hashes

    • device public keys

    • witness policy

    • certified build hashes + SBOM hashes

  3. Device attestation:

    • each device produces DAS

    • DAS hashes committed to TL before polls open

7.2 Voting

  • Voter marks ballot (hand-marked) OR uses BMD to print ballot.

  • Voter verifies paper.

  • Ballot scanned:

    • CVR generated

    • RBID assigned

    • BR generated and signed

7.3 Close and export

  • Scanner generates PRR + signed Export Bundle (EBM).

  • Export media sealed; custody events signed (see §10).

7.4 Central ingest

  • Verify:

    • signatures on EBM, BRs, PRR

    • device keys match those committed pre-election

    • attestation quote is valid and matches expected PCR policy (research-grade; requires your defined PCR allowlist)

  • Commit artifacts to TL, obtain inclusion proofs.

7.5 Tabulation

  • Deterministic tally computed:

    • Outcome = f(CVR_set, BDP)

  • Commit:

7.6 RLA (ballot-level comparison)

RLAs provide statistical assurance by examining paper ballots. NIST+2Verified Voting+2

Seed generation (commit-reveal)

  • Public ceremony produces seed

  • Commit seed_hash = SHA256(seed || election_id || “RLA”) to TL

  • Reveal seed; observers verify commitment

Sampling

  • stream = HKDF(seed, info=election_id||"RLA-SAMPLE")

  • Deterministically map stream bytes to RBID indices using manifest counts

Comparison + discrepancy logging

  • For each sampled RBID:

    • retrieve paper ballot by container/batch location

    • interpret human readable marks

    • compare with CVR

    • record discrepancy objects

  • Commit discrepancy logs to TL and publish new checkpoint.

Escalation rules follow established RLA practice (risk limit, error bounds). NIST+2Verified Voting+2

8. Optional: End-to-End Verifiable (E2E) “research mode” layer

PVTL-X can be extended with an E2E scheme where:

  • the system produces cryptographic proofs that encrypted ballots were tallied correctly,

  • while paper ballots remain authoritative for audits.

NIST has active work and expert perspectives on E2E protocols and adoption challenges. NIST Applications+1

Important: In high-assurance deployments, E2E should be treated as an additional evidence channel, not a replacement for RLAs.

9. Chain-of-custody event protocol (signed + logged)

{ "type": "CUSTODY_EVENT", "election_id": "...", "event": "SEAL_APPLIED|TRANSFER|RECEIVED|STORED|SEAL_BROKEN", "container_id": "BOX-01492", "seal_id": "SEAL-99201831", "from": "Precinct-12", "to": "County-Warehouse-A", "timestamp": "...", "witnesses": [ {"person_id":"P1","role":"EO","sig":"..."}, {"person_id":"P2","role":"Observer","sig":"..."} ] }

  • Hash canonicalized event, sign by each witness.

  • Commit artifact_sha256 to TL.

  • This creates a tamper-evident chain; it does not eliminate physical risk, but it makes deviations detectable and attributable.

10. Correctness and security claims (what PVTL-X actually guarantees)

10.1 If software is compromised…

  • It can still misbehave, but outcome-changing misbehavior becomes detectable via paper audits (software independence). NIST+1

10.2 If digital artifacts are altered after the election…

  • Any changes to committed artifacts are detectable because:

    • the TL is append-only (consistency proofs)

    • observers can verify inclusion proofs

    • witnesses prevent split-view attacks. RFC Editor+1

10.3 If chain of custody fails…

  • The system increases detectability via signed custody events + audits, but cannot provide absolute prevention without physical controls and enforcement.

11. Full technical edit for accuracy and factual grounding

Here’s the “technical edit” you asked for—what I’m confident is accurate, what is implementation-dependent, and what I’m explicitly not claiming.

11.1 Solid, well-grounded foundations (high confidence)

  • Software independence definition and why paper + audits matter: grounded in Rivest/Wack and subsequent work. NIST+1

  • Risk-limiting audits as statistical assurance of outcomes: grounded in NIST RLA literature and common RLA explanations. NIST+2Verified Voting+2

  • Append-only Merkle transparency logs with STHs and consistency/inclusion proofs: grounded in RFC 6962 and bis drafts. RFC Editor+1

  • NIST CDFs (BD/CVR/ERR) as practical object formats for interoperability: grounded in NIST implementation guidance. NIST Publications

  • E2E verifiability adoption complexity: grounded in NIST’s 2025 expert perspectives and NIST/EAC work on E2E protocol evaluation. NIST Applications+1

11.2 Claims I avoided (intentionally)

  • I did not claim that cryptography “prevents” fraud outright; it primarily provides tamper evidence and auditability.

  • I did not claim TL = “blockchain voting,” nor that it records votes.

  • I did not claim universal public release of full CVRs/ballot images; that’s legally and operationally jurisdiction-dependent.

11.3 Implementation-dependent areas (accurate conceptually; details vary)

  • TPM quote / measured boot: concept is sound, but PCR selection, firmware measurements, and attestation verification policies must be specified per hardware/OS stack.

  • Ballot image retention/publishing: depends on state law, privacy rules, and operational policy.

  • Ballot-level linkage: RBID at scan-time is privacy-preserving in principle, but you must ensure it cannot be correlated with check-in order or camera footage.

11.4 VVSG note (date-sensitive)

  • The EAC’s VVSG ecosystem is evolving; VVSG 2.1 appears as a draft (as of late 2025), so I treated VVSG alignment as a directional constraint rather than asserting any final requirement set. U.S. Election Assistance Commission+1