Key 2 — SLH-DSA (FIPS 205), post-quantum. Heads from tree size 14 on carry a second signature from this key; older heads legitimately have none — an append-only log keeps its history. Check it where your tooling allows (OpenSSL ≥ 3.5). The kind of code that verifies such signatures is itself -a proof subject of this log (leaf 18).
+a proof subject of this log (entry 18).{slh_pem}
SHA-256 fingerprint {slh_fp}
· raw: {base or ''}/log-slhdsa-public-key
@@ -239,7 +239,8 @@ You still trust: the content of every claim. You defeat: silent rewriting.
You need: Python 3 and the openssl command (preinstalled on most Linux and macOS systems).
git clone https://github.com/saymrwulf/lean-transparency-log && cd lean-transparency-log && python3 verify.py --allThis fetches the log’s public mirror — a git repository holding every entry -and every signed head ever issued — and re-computes every hash and signature in it. A green +and every signed head ever issued (a head is the signed root fingerprint of the tree at a +given size) — and re-computes every hash and signature in it. A green result means the history you now hold is internally consistent and signed. Keep the folder: if the operator ever shows a different history to anyone else, your copy proves it. A log that shows different histories to different people (a “split view”) survives only until @@ -294,7 +295,9 @@ compiler, and your hardware.
The log is a Merkle tree: every entry (“leaf”) is hashed, hashes pair up level by level, and a single 32-byte root fingerprints the entire history; the operator signs -that root. Changing any past entry would change the root — that is the tamper evidence. This +that root. Changing any past entry would change the root — that is the tamper evidence. Each leaf +records one proof run: a batch of certificates — one machine-checked theorem +each, together with its exact assumption list. This picture is computed from the live log at page render — the leaf hashes, nodes, root, and signature are the real ones:
{tree_svg} @@ -346,9 +349,8 @@ consumers.)| component | artifact 2 | artifact 3 | status |
|---|
| library | claim (attestation) | proof of inclusion (receipt) | certificates proven |
|---|
One certificate = one machine-checked theorem together with its exact assumption set (its axiom cone).
attestation.j
You hold the ruler
The list of assumptions a certificate is allowed to rest on
is not something this site hands you at verification time — it is a
-requirements card that lives in your tooling, on
+requirements card — a short plain-text file listing, by name, the
+assumptions you accept — that lives in your tooling, on
your disk, and that you can read in five minutes or rewrite from first
principles: Lean's three foundational axioms, plus — for the signature tiers only (the top proof layers, where full signature verification is proven) —
named placeholders for SHA-512 (the hash function Ed25519 uses internally —