PVTL — Technical Report

Shannon Bray

Written by
December 24, 2025

PVTL-X: Paper-Verified, Transparency-Log Voting System

A Research-Grade Specification for Evidence-Based In-Person Elections

Status: Draft for discussion
Intended Audience: Election technologists, security engineers, standards bodies, independent researchers, election officials
Keywords: software independence, risk-limiting audit, transparency log, Merkle tree, device attestation, evidentiary integrity

Executive Summary

PVTL-X specifies an in-person voting system architecture where voter-verified paper ballots remain the authoritative record, while cryptographic mechanisms provide tamper-evident integrity and public verifiability of election artifacts (e.g., ballot definitions, cast vote records, results reports, audit evidence). PVTL-X is not internet voting and does not store votes on a blockchain. Instead, it uses a Certificate Transparency (CT)-style append-only Merkle log (“Transparency Log”) to detect post-election alteration and to provide a consistent, auditable timeline of election operations.

PVTL-X further specifies interfaces and formats to support ballot-level comparison Risk-Limiting Audits (RLAs), enabling statistically sound verification of outcomes against paper ballots. The specification emphasizes offline-first operation, separation of duties, threshold control for sensitive keys, and explicit defenses against equivocation by log operators.

1. Introduction

1.1 Purpose

This report specifies PVTL-X, a max-assurance, research-grade architecture and protocol suite for evidence-based elections using paper ballots and cryptographic transparency mechanisms.

1.2 Scope

PVTL-X applies to:

  • In-person voting with paper ballots (hand-marked default; accessible ballot marking devices optional)

  • Optical scanning/tabulation and aggregation

  • Audit processes with RLAs

  • Public transparency of digital artifacts using an append-only log

PVTL-X does not specify:

  • Remote ballot casting or online voting

  • Voter registration systems

  • Identity verification mechanisms at check-in

  • Legislative policy, only technical capabilities and constraints

1.3 Design Goals

PVTL-X is designed to:

  • Provide software independence via paper ballots and audits

  • Provide tamper-evident integrity for digital artifacts through cryptographic commitments

  • Enable independent verification of artifact integrity and process consistency by third parties

  • Reduce post-election uncertainty by making the evidentiary record complete and consistent

2. Definitions, Abbreviations, and Conventions

2.1 Definitions

  • Authoritative Record: The record used to determine the official outcome. In PVTL-X, this is the paper ballot.

  • Artifact: Any digital object used in election definition, operation, reporting, or auditing (e.g., ballot definitions, CVRs, results reports, audit logs, chain-of-custody events).

  • Cast Vote Record (CVR): A machine-interpretable record representing the interpretation of a ballot.

  • Transparency Log (TL): Append-only Merkle log providing inclusion and consistency proofs for artifacts.

  • Signed Tree Head (STH): Signed summary of TL state: tree size, root hash, timestamp.

  • Witness: Independent entity that co-signs TL checkpoints to reduce equivocation risk.

  • RBID: Random Ballot Identifier assigned at scan-time to support ballot retrieval for audits without linking to a voter.

2.2 Abbreviations

  • BMD: Ballot Marking Device

  • EMS: Election Management System

  • RLA: Risk-Limiting Audit

  • TL: Transparency Log

  • STH: Signed Tree Head

  • JCS: JSON Canonicalization Scheme (RFC 8785)

2.3 Normative Language

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

3. System Model and Roles

3.1 Roles

  • Voter

  • Election Authority (EA): responsible for configuration, certification, and operations

  • Scanner/Tabulator Device (SD)

  • Optional BMD

  • EMS

  • Audit Authority (AA): conducts RLAs and publishes audit artifacts

  • TL Operator (TLO): operates transparency log service

  • Witness Set (WS): independent co-signers of checkpoints

  • Public Verifiers (PV): any party verifying published evidence

3.2 Trust Model Summary

  • PVTL-X assumes software can fail or be compromised.

  • PVTL-X assumes insiders exist and designs for separation of duties.

  • PVTL-X assumes public skepticism and aims for independently verifiable evidence.

  • PVTL-X assumes physical security is imperfect; therefore, it specifies detection mechanisms and auditable processes.

4. Threat Model and Security Requirements

4.1 Threat Classes

  • T1: BMD compromise altering printed selections

  • T2: Scanner misinterpretation or firmware manipulation

  • T3: EMS manipulation of aggregation or reporting

  • T4: Post-election alteration of digital artifacts

  • T5: Chain-of-custody compromise of paper ballots

  • T6: Privacy/coercion via receipts or linkability

  • T7: TL equivocation (split-view)

  • T8: Insider misuse of keys or privileged access

4.2 Security Requirements

PVTL-X MUST provide:

  • S1: Software-independent outcomes (paper + audits)

  • S2: Tamper-evident integrity for digital artifacts

  • S3: Public verifiability of TL consistency and artifact inclusion

  • S4: Privacy preservation (no voter-identifying linkage)

  • S5: Operational recoverability (ability to resolve discrepancies via paper evidence)

5. Cryptographic Primitives and Suites

5.1 Hash Function

  • PVTL-X MUST support SHA-256 for all artifact digests and Merkle node hashes.

5.2 Digital Signatures

PVTL-X MUST support at least one of:

  • Ed25519 (recommended), or

  • ECDSA P-256 (interoperability profile)

PVTL-X MAY support hybrid signing with a post-quantum algorithm for research purposes.

5.3 Canonicalization

  • All JSON objects that are hashed or signed MUST be canonicalized using RFC 8785 (JCS).

  • Any binary artifact MUST be hashed over raw bytes and referenced by digest.

5.4 Key Derivation and Randomness

  • Deterministic sampling streams MUST be derived using HKDF-SHA-256.

  • Devices MUST use a CSPRNG for generating nonces and RBIDs.

6. Artifact Model and Object Formats

6.1 Artifact Classes

PVTL-X defines the following artifact classes (minimum):

  1. Ballot Definition Package (BDP)

  2. Device Attestation Statement (DAS)

  3. Cast Vote Records (CVR set)

  4. Ballot Records (BR set) mapping RBID→CVR hash + retrieval metadata

  5. Results Reports (precinct and aggregated)

  6. Audit Artifacts (seed commits, samples, discrepancy logs)

  7. Chain-of-Custody Events (signed)

  8. Software Supply Chain Artifacts (build hashes, SBOM digests)

6.2 Content Addressing

  • Every artifact MUST have a digest H = SHA256(artifact_bytes_or_JCS(artifact_json)).

  • All manifests MUST list artifact digests, sizes, and semantic types.

7. Device Security and Attestation

7.1 Boot Integrity

  • Devices SHOULD implement measured boot with a hardware root of trust (e.g., TPM).

  • Devices MUST produce a Device Attestation Statement (DAS) binding:

    • measured boot state (PCR digest or equivalent)

    • application bundle digest

    • election context (election_id, device_id, role)

    • timestamp

7.2 Device Identity and Keys

  • Each device MUST have a unique device key pair generated or provisioned in a controlled ceremony.

  • Device public keys MUST be committed to the TL prior to use.

7.3 Offline-First Constraints

  • In election mode, devices SHOULD operate without general internet connectivity.

  • All exports MUST be performed via controlled removable media and signed.

8. Ballot Handling and RBID Protocol

8.1 Paper Ballots

  • The paper ballot MUST be voter-verified and retained under chain-of-custody controls.

  • If machine-readable encodings exist, they MUST NOT be the sole authoritative representation.

8.2 RBID Assignment

  • RBIDs MUST be generated at scan time using a CSPRNG.

  • RBIDs MUST NOT encode voter identity or check-in order.

  • RBIDs MUST support ballot retrieval for auditing through container/batch metadata.

8.3 Ballot Record (BR)

  • For each scanned ballot, the scanner MUST generate a BR that includes:

    • RBID, ballot_style_id, container_id, batch_id

    • CVR digest

    • optional image digests

    • scanner_id and timestamp

  • BRs MUST be signed by the scanner device key.

9. Tabulation and Deterministic Recomputability

9.1 Deterministic Tally Function

  • The EMS MUST compute results as a deterministic function Outcome = f(CVR_set, BDP) such that outcomes can be recomputed given the same inputs.

  • The EMS MUST publish digests for:

    • BDP used

    • CVR set used

    • results report produced

9.2 Aggregation Artifacts

  • EMS aggregation outputs MUST be treated as artifacts committed to the TL.

  • Any adjudication steps SHOULD be logged and committed as artifacts.

10. Transparency Log (TL) Protocol

10.1 Overview

The TL is an append-only Merkle log supporting:

  • artifact inclusion proofs

  • append-only consistency proofs

  • signed checkpoints

10.2 TL Leaf Structure

Each TL leaf MUST commit to:

  • election_id

  • entry_type

  • artifact_digest (SHA-256)

  • artifact_size

  • originator_role and originator_id

  • timestamp

10.3 Merkle Hashing Rules

PVTL-X adopts CT-style domain separation:

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

  • NodeHash = SHA256(0x01 || LeftChild || RightChild)

10.4 Signed Tree Head (STH)

The TL MUST periodically publish an STH with:

  • tree_size

  • root_hash

  • timestamp

  • log_id

The STH MUST be signed by the TL operator key.

10.5 Witness Anti-Equivocation

  • A TL checkpoint MUST include witness co-signatures meeting a stated threshold policy.

  • Clients MUST reject checkpoints that do not meet the witness threshold.

10.6 Proof Interfaces

The TL MUST provide:

  • inclusion proof for a given leaf hash at a given tree size

  • consistency proof between two tree sizes

  • current checkpoint retrieval

10.7 Public Mirroring

  • The TL SHOULD support public mirroring.

  • Witnesses SHOULD gossip checkpoints to detect split-view behavior.

11. Risk-Limiting Audit (RLA) Integration

11.1 Seed Commit-Reveal

  • The Audit Authority MUST commit a seed hash to the TL before revealing the seed.

  • The revealed seed MUST verify against the committed hash.

11.2 Deterministic Sampling

  • The sample selection procedure MUST be deterministic given:

    • the revealed seed

    • election_id

    • the published ballot manifest

  • The sampling output MUST be committed to the TL.

11.3 Discrepancy Recording

  • For each audited ballot, the Audit Authority MUST record:

    • RBID

    • discrepancy classification

    • human interpretation (structured)

    • CVR digest reference

    • timestamp and auditor signatures (or authority signature)

11.4 Escalation

  • The audit MUST specify a risk limit and escalation criteria.

  • Escalation events and final audit determination MUST be artifacts committed to the TL.

12. Chain-of-Custody Event Protocol

12.1 Signed Custody Events

  • Custody events MUST be recorded as signed artifacts including:

    • container_id, seal_id

    • event type (applied, transferred, received, stored, broken)

    • from/to locations

    • timestamp

    • witness signatures (two-person integrity recommended)

12.2 TL Commitments

  • Custody event digests MUST be committed to the TL promptly (policy-defined maximum delay).

13. Privacy Requirements

PVTL-X MUST ensure:

  • No TL entry includes voter identity or voter-specific receipt data.

  • RBID assignment does not enable linkage to voters via deterministic encoding.

  • Public artifacts do not enable reconstruction of a voter’s ballot from check-in sequence or location metadata.

PVTL-X SHOULD document jurisdiction-specific privacy constraints around:

  • ballot image retention

  • CVR publication

  • public disclosure rules

14. Operational Requirements (High-Assurance Profile)

14.1 Key Ceremony

  • TL operator keys, witness keys, and device keys MUST be generated/provisioned under documented ceremony.

  • Public keys and policies MUST be committed to the TL before election use.

  • Threshold control SHOULD be used for high-impact signing operations.

14.2 Separation of Duties

PVTL-X deployments SHOULD enforce that:

  • ballot definition creation

  • scanning operations

  • EMS aggregation

  • auditing
    are performed by distinct roles/teams.

14.3 Immutable Storage

  • Election artifacts SHOULD be stored in immutable or WORM-capable storage.

  • Storage manifests MUST be committed to the TL.

15. Conformance Checklist (Minimal)

A conforming PVTL-X system MUST demonstrate:

15.1 Cryptography

  • SHA-256 digests for all artifacts

  • RFC8785 canonicalization for JSON artifacts

  • Valid signatures for device exports and TL checkpoints

  • Inclusion and consistency proof verification

15.2 Transparency Log

  • Append-only behavior with consistency proofs

  • Witness-threshold checkpoint validation

  • Public retrieval of checkpoints and proofs

15.3 Voting Evidence

  • Voter-verified paper ballot as authoritative record

  • BR generation and signing for ballot-level audit retrieval

15.4 Audit Evidence

  • Seed commit-reveal on TL

  • Deterministic sampling

  • Discrepancy logs committed to TL

  • Escalation evidence committed to TL

15.5 Privacy

  • No voter-identifying data in TL

  • RBID non-linkability requirements met

Appendix A. Recommended Data Schema Templates (Illustrative)

A.1 TL Leaf Payload (illustrative JSON)

  • type, election_id, entry_type, artifact_sha256, artifact_size, originator, timestamp

A.2 Export Bundle Manifest

  • list of file names, digests, sizes, and declared types; signed by origin device

A.3 Audit Discrepancy Record

  • RBID, classification, human interpretation, CVR digest reference, signatures

(If you want, I can provide these as a formal schema bundle: JSON Schema definitions + example instances + test vectors.)

Appendix B. Verification Procedures (Illustrative)

A public verifier can:

  1. Fetch latest checkpoint; verify TL operator signature and witness threshold.

  2. Fetch inclusion proofs for published artifact digests (BDP, CVR set hash, results).

  3. Fetch consistency proofs between checkpoints to confirm append-only growth.

  4. Confirm audit seed commit matches reveal; recompute sample list deterministically.

  5. Confirm discrepancy log inclusion and final audit determination inclusion.

Appendix C. Limitations and Non-Claims

PVTL-X does not claim to:

  • prevent all fraud (it increases detectability and correctability)

  • replace physical chain-of-custody controls

  • guarantee voter review (human factors remain a risk)

  • mandate public release of CVRs or images (jurisdiction-dependent)

 

 

Research and artifact pack (schemas, examples, test vectors, verifier pseudocode, and the max-assurance deployment profile) as a zip