How Cryptographic Authorship Proof Works, Explained for Non-Programmers

Cryptographic authorship proof works in three layers. As you write, the editor records small events — typing sessions, revisions, pastes — and reduces each one to a hash: a short digital fingerprint that changes completely if even one character of the input changes. Each event is then signed with an ed25519 key, which acts like a tamper-evident seal: anyone can inspect it, but only the holder of the private key could have made it, and any change to the sealed data breaks it visibly. Finally, the sealed events go into an append-only log — a notarized diary where new pages can be added but old pages can never be rewritten, because every entry locks in the fingerprint of the entry before it.

The payoff comes at verification time. When a professor scans the QR code on an authorship certificate, their browser re-runs the math: it recomputes the fingerprints, checks every seal, and walks the chain from the first keystroke to the final export. The verdict comes from arithmetic, not from anyone’s word — and it needs no account, because checking a signature requires only public information: the record itself and a published public key. The rest of this post explains each piece in plain language, then follows one student’s essay from blank page to scanned QR code.

A hash is a fingerprint, not a copy

A hash function takes any input — a sentence, an essay, a 400-page dissertation — and produces a short, fixed-length string of letters and numbers. The same input always produces the same output, on any computer, forever. A different input, even by a single character, produces an output that shares nothing recognizable with the original.

Here are real SHA-256 values, truncated for readability:

Swap a period for an exclamation mark and the entire fingerprint changes. Lowercase one letter and it changes again, completely. This is why a hash works as evidence: if a document produced a certain fingerprint on Tuesday, and it still produces that fingerprint on Friday, nothing in it was touched — not one comma.

Two more properties matter. A hash is one-way: you cannot reconstruct the text from its fingerprint, just as you cannot rebuild a person from a thumbprint. And it is practically impossible to craft a different document that produces the same fingerprint. A hash therefore commits you to exactly one piece of content without revealing that content — which is useful when a verification record shouldn’t expose your private drafts to the world.

An ed25519 signature is a tamper-evident seal

A hash proves a document hasn’t changed — but anyone can compute a hash of anything. It says nothing about who recorded it or when. That’s what signatures add.

ed25519 is a digital-signature scheme built on a pair of keys. The private key stays secret and is used to sign. The public key is published openly and is used to verify. Signing takes some data — in our case, the hash of a writing event — plus the private key, and produces a signature: a small block of numbers with two properties that matter here. Anyone holding the public key can confirm the signature was made by the matching private key, and any change to the signed data, even a single bit, makes verification fail loudly.

The old-world analogy is a wax seal on a letter. The seal told the recipient who sent the letter and whether the envelope had been opened in transit. A digital signature is that seal without its weaknesses: it can’t be forged with a copied stamp, and it can’t be peeled off and reapplied to a different letter, because it is mathematically bound to the exact contents it sealed.

If ed25519 sounds exotic, it isn’t. It is one of the most widely deployed signature schemes in existence — it protects SSH connections, signs software updates, and secures messaging protocols. In cryptography, boring and battle-tested is exactly what you want.

An append-only log is a notarized diary

Individual signed events are useful; a chain of them is what makes the record trustworthy. In an append-only log, every new entry includes the fingerprint of the previous entry. Picture a bound diary with numbered pages, where each page begins by quoting the fingerprint of the page before it. You can always add a new page at the end. What you cannot do is tear out page 14, rewrite it, and slide it back in — because page 15 already contains the fingerprint of the original page 14, and the forgery won’t match.

This is the design honesty of the whole system: tampering isn’t made impossible, it’s made evident. Any deletion, insertion, or edit — by the writer, by the platform, by anyone — breaks the chain at a specific link, and verification points right at it.

In Diglot’s editor, when a writer opts into process proof, every writing event becomes an entry in this chain: a typing session, a revision pass, an accepted suggestion, a paste from outside the document. A paste is recorded as a paste — honestly, with a timestamp — not quietly blended into “writing.” There is no editing history after the fact. The one thing the writer controls is whether to turn the recording on at all; once on, the diary only ever grows.

Why verification needs no account

Here is the part that surprises people most — I built this signing pipeline, and it still pleases me: checking the record requires nothing secret. Verification uses three things — the event log, the signatures, and the public key — and all three are public by design. The private key never leaves the signing infrastructure, and the verifier never needs it.

So the professor doesn’t create an account, doesn’t install anything, and doesn’t take the platform’s word for anything. The QR code opens a verification page; the page fetches the record and re-runs the checks. A skeptical department could even re-implement verification independently, because there is no secret ingredient — only published math.

Compare that with how AI detection works: a black-box model reads your finished text and outputs a statistical guess about how “AI-like” it feels. You cannot inspect the reasoning, and you cannot appeal to arithmetic. A Stanford study (Liang et al., published in Patterns, 2023) found AI detectors falsely flagged 61% of TOEFL essays by non-native English speakers. Ukrainian is my first language, and I still draft tricky paragraphs in Ukrainian before rebuilding them in English — exactly the kind of process that leaves statistically “unusual” final text. That is why I care about proof that looks at the process instead of guessing from the product, and why so many students describe the fear of false flags — what we call flagxiety — as worse than any grammar anxiety.

A quick recap before the walkthrough:

What happens when a student writes with process proof on

Imagine a student — call her Lena — writing a psychology essay.

1. Monday, 19:04. Lena opens a new document and switches on process proof. From this moment her writing events are recorded; nothing before it was.
2. Monday evening. She writes for about forty minutes — bursts of typing, deletions, a rewritten thesis sentence. The editor batches this into events, hashes each one, signs each hash, and appends them to her document’s chain with timestamps.
3. Wednesday. She pastes a 60-word block quote from a journal article. The chain records it as an external paste at 21:17. That is not an accusation — quotes are normal. It is simply the truth of what happened, preserved.
4. Thursday. Heavy revision: the introduction shrinks by half, two paragraphs trade places. Each session chains onto the previous entries.
5. Friday. She exports the essay and receives a certificate with a QR code and a link — a verifiable summary of the entire recorded process.
6. The professor scans the QR code. The verification page loads the chain, checks every signature against the published public key, recomputes every fingerprint link, and shows the summary: total writing time across four days, the session timeline, the proportion of typed versus pasted text, the revision pattern. If any entry had been altered — by Lena, by Diglot, by anyone — the page would show exactly where the chain broke.

The professor’s part takes about a minute. No login, no upload to a detector, no probability score to argue about.

What cryptographic authorship proof proves — and what it honestly doesn’t

This kind of proof is precise about its claims, and precision means limits.

It proves that this sequence of writing events happened in this editor, in this order, at these times, and that the record has not been touched since. It does not read minds. A determined cheater could, in principle, retype text from another screen. But that changes the economics entirely: instead of pasting a finished essay in one visible event, they would have to fake days of human-shaped drafting, deleting, and revising in real time. Cheating becomes slower than writing.

More importantly, it inverts the default. A detector treats every submission as suspect and asks a statistical model to sort out the accused — a model that misfires most on non-native writers, as the accuracy debates around Turnitin keep showing. A signed process log lets the writer volunteer evidence before any accusation exists. Innocent by default, with receipts.

If you write in a second language and have ever felt that quiet dread of being asked to prove your own words, this is precisely the problem Diglot was built around. The editor is a bilingual writing space for ESL writers first, and the Authorship Certificate is the receipts layer on top: opt in, write the way you actually write, and hand anyone who asks a link where the math answers for you.