nserser/lr-webpkiImplementazione di riferimento dell'autenticazione post-quantistica LR+ nel contesto WebPKI CA, con pipeline di corpus, ricostruzione, valutazione e manifesti di provenienza per una ricerca riproducibile.
Questo pacchetto contiene l'implementazione di riferimento finalizzata di LR+, wrapper di ricostruzione di produzione, test e output di valutazione generati per l'autenticazione post-quantistica a contesto chiuso sul contesto CA WebPKI.
Il pacchetto è scritto intenzionalmente come artefatto di sottomissione piuttosto che come snapshot di log di ricerca: nomi di target, nomi di file, nomi di moduli e report utilizzano una terminologia di implementazione stabile.
src/lrplus/ Moduli di riferimento LR+
scripts/ download del corpus, build, ricostruzione, valutazione e controlli
config/ configurazione di ricostruzione e download bloccata
results/ output di produzione generati utilizzati dal paper
audit/ report di provenienza e manifest degli hash di output
backups/ manifest per il backup del corpus di input effettuato prima della rebuild
data/ccadb_full/ manifest di download CCADB e hash dei file
working_corpus/ manifest di rebuild del corpus per il bundle compatto
tests/ test di coerenza di protocollo e artefatto
Il bundle compatto contiene manifest e risultati generati. Una rigenerazione completamente nuova richiede accesso a internet e accesso alla pipeline esistente del corpus WebPKI che fornisce e .
scripts/normalize_ccadb.pyscripts/build_graph.pyUtilizzare Python 3.9 o successivo. Una configurazione tipica è:
python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .
L'adattatore ML-DSA-44 utilizza pqcrypto==0.4.0. Se quel backend non è disponibile, il test ML-DSA reale viene saltato mentre il resto dei test di riferimento viene comunque eseguito. Per il gate di verifica di produzione, installare tutte le dipendenze da pyproject.toml.
Il wrapper CCADB delega la normalizzazione e la costruzione del grafo alla pipeline esistente del corpus WebPKI. Impostare uno dei seguenti prima di eseguire una build completa:
export WEBPKI_PIPELINE_ROOT=/path/to/existing_webpki_pipeline
oppure passare il percorso tramite Make:
make verify PIPELINE_ROOT=/path/to/existing_webpki_pipeline
La root della pipeline deve contenere:
scripts/normalize_ccadb.py
scripts/build_graph.py
Il comando singolo è:
make verify PIPELINE_ROOT=/path/to/existing_webpki_pipeline
Esegue le seguenti fasi in ordine.
make backup-corpus
Copia le sottodirectory correnti working_corpus/{raw,normalized,graph,outputs_scc_repaired}, quando presenti, in backups/input_corpus_<timestamp>/ e scrive manifest.json, file_inventory.csv e SHA256SUMS.
make download-ccadb
Utilizza config/ccadb_download.yaml e scrive:
data/ccadb_full/download_manifest.json
data/ccadb_full/SHA256SUMS
Il manifest registra il tag crtsh/ccadb_data selezionato, il commit, l'hash del record del certificato V5, l'intervallo di file PEM annuali e l'hash di input della root-trust.
make build-corpus PIPELINE_ROOT=/path/to/existing_webpki_pipeline
Il wrapper prepara i file CCADB scaricati sotto working_corpus/raw/ e quindi invoca il normalizzatore e il builder del grafo della pipeline esistente. Scrive:
working_corpus/rebuild_manifest.json
working_corpus/normalized/certificates.parquet
working_corpus/normalized/records.parquet
working_corpus/outputs_scc_repaired/graph.json
make test
La suite di test copre identificatori canonici, parsing warm-wire, binding del terminale corrente, canonicalizzazione dello stream tipizzato, negoziazione, delta di catch-up per intervalli, serializzazione dello stato autenticato, schema degli output di ricostruzione e integrazione ML-DSA quando il backend è installato.
make reconstruct
Legge config/reconstruction.yaml ed emette una riga per ogni contesto di percorso/vista selezionato:
results/path_view_trace.csv
results/typed_dependency_records.csv
results/view_root_sets.csv
results/reconstruction_gate.json
Ogni riga di percorso registra la vista, gli ID dei certificati concreti, la linea di discendenza selezionata, l'ID del percorso, i riferimenti alle dipendenze tipizzate, i tipi di dipendenza, i byte warm, i byte di baseline e i digest del binding del terminale.
make evaluate
Calcola:
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
Le formule di contabilità dei byte sono:
Suggerimento profilo warm LR+: 8 + 48*m
SPB: 2588 + 209*m
Profilo S: 3569 + 904*m
PQ completo per dipendenza: m*(2420 + 209)
Delta di catch-up per intervallo: 2584 + 264*k_totale
Delta consecutivi: r*(2584 + 264*k_per_epoca)
make check
Verifica gli output richiesti, i manifest delle sorgenti bloccate, le formule dei byte per riga, gli ID dei percorsi, i digest dei terminali, la copertura dei record di dipendenza, le viste configurate, la serializzazione dello stato per vista e la disponibilità del catalogo. Scrive:
results/check_results.json
Lo stato deve essere PASS.
make freeze
Scrive:
audit/implementation_manifest.json
Il manifest registra le informazioni sulla piattaforma, i metadati delle sorgenti bloccate, i metadati della build del corpus e gli hash SHA-256 di tutti i file di risultati generati.
Dopo che il corpus è già stato costruito, eseguire:
make verify-fast
Salta le fasi di backup, download e build del corpus e riesegue test, ricostruzione, valutazione, controlli e congelamento del manifest dal corpus locale corrente.
Gli output generati inclusi riportano:
contesti percorso/vista: 44.912
linee di discendenza CA fisiche distinte: 16.858
record di dipendenza tipizzati: 72.020
m50 / m95 / mmax globali: 6 / 16 / 18
Suggerimento profilo warm LR+: 296 / 776 / 872 byte
SPB: 3.842 / 5.932 / 6.350 byte
Profilo S: 8.993 / 18.033 / 19.841 byte
PQ completo per dipendenza: 15.774 / 42.064 / 47.322 byte
stato mantenuto: 16.150.580 byte
checkpoint firmato: 16.160.724 byte
I riepiloghi per vista sono in results/per_view_summary.csv.
L'implementazione utilizza nomi LR+ finalizzati per file sorgente, script, target, configurazione e report. Gli output crittografici non vengono modificati manualmente oltre ai metadati testuali stabili. Le impronte digitali esadecimali dei certificati, i riferimenti ai record e i digest possono naturalmente contenere sottostringhe arbitrarie; questi sono dati, non terminologia di processo.