nserser/lr-webpkiReference implementation of LR+ post-quantum authentication over WebPKI CA context, with corpus pipeline, reconstruction, evaluation, and provenance manifests for reproducible research.
This package contains the finalized LR+ reference implementation, production reconstruction wrappers, tests, and generated evaluation outputs for context-closed post-quantum authentication over WebPKI CA context.
The package is intentionally written as a submission artifact rather than a research-log snapshot: target names, filenames, module names, and reports use stable implementation terminology.
src/lrplus/ LR+ reference modules
scripts/ corpus download, build, reconstruction, evaluation, and checks
config/ pinned reconstruction and download configuration
results/ generated production outputs used by the paper
audit/ provenance report and output-hash manifest
backups/ manifest for the input-corpus backup made before rebuild
data/ccadb_full/ CCADB download manifest and file hashes
working_corpus/ corpus rebuild manifest for the compact bundle
tests/ protocol and artifact consistency tests
The compact bundle contains manifests and generated results. A fully fresh
regeneration requires internet access and access to the existing WebPKI corpus
pipeline that provides scripts/normalize_ccadb.py and .
scripts/build_graph.pyUse Python 3.9 or newer. A typical setup is:
python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .
The ML-DSA-44 adapter uses pqcrypto==0.4.0. If that backend is unavailable,
the real ML-DSA test is skipped while the rest of the reference tests still run.
For the production verification gate, install all dependencies from
pyproject.toml.
The CCADB wrapper delegates normalization and graph construction to the existing WebPKI corpus pipeline. Set one of the following before running a full build:
export WEBPKI_PIPELINE_ROOT=/path/to/existing_webpki_pipeline
or pass the path through Make:
make verify PIPELINE_ROOT=/path/to/existing_webpki_pipeline
The pipeline root must contain:
scripts/normalize_ccadb.py
scripts/build_graph.py
The single command is:
make verify PIPELINE_ROOT=/path/to/existing_webpki_pipeline
It performs the following stages in order.
make backup-corpus
This copies the current working_corpus/{raw,normalized,graph,outputs_scc_repaired}
subdirectories, when present, into backups/input_corpus_<timestamp>/ and writes
manifest.json, file_inventory.csv, and SHA256SUMS.
make download-ccadb
This uses config/ccadb_download.yaml and writes:
data/ccadb_full/download_manifest.json
data/ccadb_full/SHA256SUMS
The manifest records the selected crtsh/ccadb_data tag, commit, V5 certificate
record hash, yearly PEM file range, and root-trust input hash.
make build-corpus PIPELINE_ROOT=/path/to/existing_webpki_pipeline
The wrapper prepares the downloaded CCADB files under working_corpus/raw/ and
then invokes the existing pipeline's normalizer and graph builder. It writes:
working_corpus/rebuild_manifest.json
working_corpus/normalized/certificates.parquet
working_corpus/normalized/records.parquet
working_corpus/outputs_scc_repaired/graph.json
make test
The test suite covers canonical identifiers, warm-wire parsing, current-terminal binding, typed stream canonicalization, negotiation, range catch-up deltas, authenticated state serialization, reconstruction-output schema, and ML-DSA integration when the backend is installed.
make reconstruct
This reads config/reconstruction.yaml and emits one row per selected
path/view context:
results/path_view_trace.csv
results/typed_dependency_records.csv
results/view_root_sets.csv
results/reconstruction_gate.json
Each path row records the view, concrete certificate IDs, selected lineage, path ID, typed dependency references, dependency types, warm bytes, baseline bytes, and terminal-binding digests.
make evaluate
This computes:
results/global_summary.json
results/per_view_summary.csv
results/per_view_dependency_records.csv
results/catalog_summary.csv
results/lifecycle_per_view.csv
results/byte_accounting.json
The byte-accounting formulas are:
LR+ warm profile-hint: 8 + 48*m
SPB: 2588 + 209*m
Profile S: 3569 + 904*m
Full per-dependency PQ: m*(2420 + 209)
Range catch-up delta: 2584 + 264*k_total
Consecutive deltas: r*(2584 + 264*k_per_epoch)
make check
This verifies required outputs, pinned-source manifests, per-row byte formulas, path IDs, terminal digests, dependency-record coverage, configured views, per-view state serialization, and catalog availability. It writes:
results/check_results.json
The status must be PASS.
make freeze
This writes:
audit/implementation_manifest.json
The manifest records platform information, pinned source metadata, corpus-build metadata, and SHA-256 hashes of all generated result files.
After the corpus has already been built, run:
make verify-fast
This skips the backup, download, and corpus-build stages and reruns tests, reconstruction, evaluation, checks, and manifest freezing from the current local corpus.
The bundled generated outputs report:
path/view contexts: 44,912
distinct physical CA lineages: 16,858
typed dependency records: 72,020
global m50 / m95 / mmax: 6 / 16 / 18
LR+ warm profile-hint: 296 / 776 / 872 bytes
SPB: 3,842 / 5,932 / 6,350 bytes
Profile S: 8,993 / 18,033 / 19,841 bytes
full per-dependency PQ: 15,774 / 42,064 / 47,322 bytes
retained state: 16,150,580 bytes
signed checkpoint: 16,160,724 bytes
Per-view summaries are in results/per_view_summary.csv.
The implementation uses finalized LR+ names for source files, scripts, targets, configuration, and reports. Cryptographic outputs are not manually edited beyond stable textual metadata. Hexadecimal certificate fingerprints, record references, and digests may naturally contain arbitrary substrings; these are data, not process terminology.