Key Sovereignty & PDF Watermarking
Full technical documentation and code disclosure proving that The Penta-Ledger never receives, stores, or transmits your private key.
The Zero-Knowledge Private Key Guarantee
When you submit a research manuscript for an epistemic plausibility audit, your cryptographic identity is generated entirely inside your local browser sandbox. Only your 32-byte Ed25519 Public Key is anchored to the public ledger. Your Private Key never touches our servers, is never sent over any network wire, and is never logged in any database.
1. The 4-Step Client-Side Architecture
How native in-browser Ed25519 Web Crypto and vector PDF stamping work in harmony.
Native Web Crypto API
Your browser executes crypto.subtle.generateKey() using the W3C standard Web Crypto implementation. It generates an asymmetric Ed25519 (Curve25519) keypair in under 0.1 milliseconds with 128-bit symmetric equivalent security.
Non-Occluding Margin Strips
Using vector PDF manipulation (pdf-lib), your document is stamped on the outer margins (top and bottom) with your UTC timestamp, pre-watermark SHA-256 hash, OpenTimestamps notice, and the full 64-character Ed25519 public key hex without obscuring any manuscript text or equations.
Local Private Key Storage
The private key is exported exclusively into your browser's private localStorage and packaged into your downloaded penta_receipt.json. It is excluded from the network payload entirely.
Ledger Registration
The server receives only the stamped PDF and the 32-byte Ed25519 Public Key. The public key is permanently anchored on the public D1 database record to allow future verification challenges.
2. Source Code Disclosure
The exact client-side JavaScript executing in your browser during manuscript submission.
// 1. Generate Ed25519 Keypair in Local Memory (< 0.1ms)
const keyPair = await window.crypto.subtle.generateKey(
{ name: 'Ed25519' },
true, // Extractable by the author for receipt export
['sign', 'verify']
);
// 2. Export 32-byte Raw Public Key (64-char Hex)
const rawPub = await window.crypto.subtle.exportKey('raw', keyPair.publicKey);
const pubHex = bufferToHex(rawPub); // Exactly 64 characters
// 3. Export Private Key (PKCS#8) - KEPT ONLY ON CLIENT
const pkcs8Priv = await window.crypto.subtle.exportKey('pkcs8', keyPair.privateKey);
const privHex = bufferToHex(pkcs8Priv);
// 4. Submit ONLY the Public Key to the server
const formData = new FormData();
formData.set('file', stampedPdfFile);
formData.append('author_pubkey', pubHex); // <-- ONLY PUBLIC KEY IS SENT
// Notice: privHex (private key) is NEVER appended to formData!3. How to Verify This Yourself in Developer Tools
Any researcher can audit our network requests in 30 seconds using standard browser developer tools:
- Open the Developer Tools in your browser (Press F12 or Ctrl+Shift+I).
- Navigate to the Network tab and set the filter to Fetch/XHR.
- Submit a test paper on the Submit Paper page.
- Select the
POST /api/submitrequest and inspect the Payload / FormData section. - Inspect the payload: You will observe that
author_pubkeycontains the 64-character Ed25519 public key hex, and there is no private key field anywhere in the request body, query parameters, or HTTP headers.
4. How Authors Use Their Private Key
How asymmetric cryptography empowers you to prove ownership without passwords or user accounts.
Because you hold the private key corresponding to the public key stamped on the manuscript, you can visit your paper's verification page at https://penta-ledger.org/verify/<hash> at any time.
When you request an author action (such as unlisting the paper or updating metadata), your browser generates a cryptographic challenge signature (penta-auth:<ACTION>:<HASH>:<TIMESTAMP>) signed by your private key. The server verifies this signature against your registered public key and executes your request immediately.
5. Why do we generate two SHA256 hashes — why don't I get just one?
Understanding the mathematical difference between your Pre-Watermark and Post-Watermark cryptographic digests.
We generate a SHA256 hash of your uploaded manuscript before we apply a watermark (the pre-watermark hash) and then we apply the watermark with the timestamp and public key from the document's public/private keypair, and then we generate a SHA256 hash of the watermarked PDF.
There is no mathematical law preventing the two hashes from matching in SHA256, it's just extremely unlikely — for us to do it on-demand, it would either require brute-force testing all possible keys against the document to find a matching pair (we would probably all be dead before the search completes) or for someone to discover a flaw in SHA256 that allows us to make a 'Hash Quine' (in which case please upload your paper — see here for how they did it with MD5: Corkami Hash Quines on GitHub) or for a black-swan event to occur in number-theory that trivialises modern encryption (in which case please upload your paper and give us the heads-up so we can prepare for the covid-like impact, but on the plus side the Riemann Hypothesis would finally be solved).