Coder Legion - Recent posts tagged cryptography

Noita's Eye Messages in One Evening: 7 of the 9 Known Rules, and the Conclusion I Had to Take Back

Tue, 13 Oct 2026 13:36:24 +0000

Originally published at vibeagentmaking.com.

One script, one evening, and the Noita solvers' own nine conditions as the scorecard: it reproduces seven. It also produced a confident conclusion, a key tied to position, that the isomorph count against a shuffled control threw out: 51 matching pairs in the messages, 0 in the shuffle.

Somewhere in Noita, the roguelike from Nolla Games, there are nine messages written in eyes. A community tracker, Unsolved Puzzles, sums them up in three sentences: "9 messages made of eye-shaped glyphs found in East and West parallel worlds. 5 messages in the East, 4 in the West. Each eye glyph has one of 5 orientations." A little further down it adds, in capitals, that playing the game won't solve them: "This is NOT an in-game interaction puzzle." The tracker lists them as still unsolved.

I spent an evening with them. I wasn't after the plaintext. I wanted to see how far one script gets toward what the solvers already know, and the tracker supplies the scorecard: nine observations under the heading "Pyry's Conditions", introduced with "Any proposed theory must explain ALL of the following observations." By the end of the night the script had reached seven of the nine. Along the way it also led me to a confident conclusion that the same data, tested properly, threw out. That wrong turn is what this piece is about.

From eyes to numbers

An eye points one of five ways, so each eye is a digit from 0 to 4. The solvers read the eyes in groups of three, called trigrams, which gives a number from 0 to 124. Settling the reading order was the community's first big result: "Out of 36 possible reading orders for trigrams, exactly ONE produces an unbroken range of values from 0-82." The tracker puts the chance of that happening by accident at about 5.8 × 10^-185, and says Toboter's script tested some 86,000 reading orders without finding another like it. I did not recompute either figure.

My starting point was a transcription already in that order: data.csv in Doctor-Ned's NoitaEyeGlyphResearch repository on GitHub. To check it, I compared it with an independent transcription, eyes.json in ngraham20's NoitaCryptographyResearch. The two agree on every message's length in eyes, from 297 to 411.

What fell out in minutes

The first five results took about as long to get as to type.

The range (condition 2). The nine messages hold 1,036 trigrams between them. Every value from 0 to 82 appears, and nothing else does.

The spread (condition 1). The index of coincidence is the chance that two symbols picked at random from a text are the same. For 83 symbols used equally often it would be 1/83, or 0.0120. The messages come out at 0.0128, close to flat. A language written through a simple letter-for-symbol swap would keep its lumps, and there are almost none here.

No doubles (condition 8). No trigram ever follows itself. There are 1,027 places where one trigram sits next to another, and in none of them are the two the same. If the trigrams were drawn independently, at the frequencies these messages actually have, about 14 of those pairs would be doubles, and the chance of getting none would be about 6.4 in ten million.

The openings (condition 7). All nine messages start with a different trigram, and all nine have the same second trigram, 66. The tracker reads the first trigram as a message number.

Shared stretches (condition 3). Across the 36 ways of pairing the messages, I looked for identical runs of four or more trigrams. There are 20. Every one sits at the same position in both messages, and none is shifted.

A guess that died in one line

My first idea about the mechanism was that each symbol might be the plaintext letter plus the previous symbol, counted round 83. If so, the difference between each trigram and the one before it would be the plaintext itself, and plaintext is lumpy. The index of coincidence of those differences is 0.0125. For comparison I shuffled each message, took the same differences, and got 0.0120. So the differences are as flat as noise, and the guess is dead.

That cost nothing. The next one cost more, because it looked right.

The conclusion I wrote down

Condition 3 is a striking pattern: twenty identical runs, every one at the same offset in both messages, not one shifted. I wrote in my notes that night that the key was tied to position. By that I meant that what a trigram encodes depends on where it sits in the message and on nothing that came before it, with the same key at a given position in every message. That explains the twenty runs neatly, since the same plaintext at the same place in two messages would come out the same. I moved on.

A key like that also makes a prediction, and I didn't check it until the next pass. If the encoding depends on position alone, a phrase that turns up again somewhere else passes through an unrelated stretch of key, and its second appearance shares nothing with its first.

The solvers had already named the test. Lymm's patterns, which the community calls isomorphs, are stretches where the same pattern of repeats turns up with different values. Here is one, printed by the script. At position 37 of East 1 the trigrams read:

14, 21, 70, 47, 44, 48, 42, 19, 48, 13, 47, 19

At position 65 of the same message they read:

5, 25, 20, 71, 11, 74, 56, 4, 74, 19, 71, 4

None of the numbers match. But in the first stretch the 48s sit in the sixth and ninth places, the 47s in the fourth and eleventh, and the 19s in the eighth and twelfth. In the second stretch the 74s, the 71s and the 4s sit in exactly the same places. It is the same shape in different numbers, 28 trigrams further on.

So I counted them. In windows of 12 trigrams with at least three repeats, 51 pairs share a pattern while differing in value, and all 51 sit at different positions. I shuffled each message and ran the count again: 0. The longer windows agree. Windows of 16 with four repeats gave 38 pairs, all shifted, against 0 shuffled. Windows of 20 with five repeats gave 29 pairs, 27 of them shifted, again against 0.

A key that depends on position alone can't do that. To carry a pattern to a new place in new values, the cipher needs a state that the text itself moves along, and the key I had written down had none.

There is a trap in the wording here too. The tracker's sixth condition says these isomorphs imply "position-dependent encoding". That is true in the sense that the same phrase comes out differently in different places. What the isomorphs rule out is the stronger thing in my notes: an encoding that depends on the position and on nothing else.

What the twenty runs actually were

With the position theory gone, I went back to where the twenty identical runs sit. Eighteen of them start at position 1, the second trigram, which makes them the messages' openings.

East 1, West 1 and East 2 agree for 24 trigrams after their different first ones.
East 4, West 4 and East 5 agree for 20.
East 3 agrees with that second group for 9.
West 2 and West 3 agree with it for 5.
All nine share their second and third trigrams.

Apart from the number at the front, the messages open alike. The tracker's entry for the numbering says as much: "Shared sections near the start suggest a common header".

The other two runs are one pair. East 1 and West 1 agree up to position 24, part at 25, and agree again for four trigrams from 29. They part again at 33, then agree for thirteen trigrams from 37. Of all the patterns in this piece, that is the one that asks the most of a model: two messages that drifted apart fall back into step at the same place.

The model that survives

The tracker's leading explanation, listed as "Established", is a deck cipher: "a deck of 83 cards where each plaintext letter triggers a specific shuffle. The top card after shuffling is the ciphertext output." It calls this "Equivalent to a Group Autokey cipher with the symmetric group S₈₃", which is where its name, GAK with S83, comes from.

In a cipher like that, the text drives the state, which is what the isomorphs need. Encipher the same phrase from two different orderings of the deck and the phrase moves the cards the same way both times. Only the cards' names differ, so the repeats land in the same places while the numbers change. The missing doubles fit as well. The tracker credits Pyry and Lymm with that observation and explains it in one line: "In a deck cipher, this is automatic: each plaintext letter shuffles the deck, so the top card always changes." For the openings that match despite different first trigrams, which is its fifth condition, it credits Lymm with a "delayed hidden state effect" inside the same model.

Whether that effect also covers East 1 and West 1 falling back into step after a four-trigram gap, I can't say. I didn't build the model, and an evening wasn't enough to try.

What an evening can't do

I did not test conditions 5 or 9. Nothing above is new, either. Every property is on the tracker with names attached:

Toboter for the reading order;
Lymm for the isomorphs and much of the deck-cipher reasoning;
Pyry for the conditions, and for an early autokey model that showed how isomorphs could arise (the tracker now lists it as ruled out);
CodeWarrior0 for finding trigram values repeating at a gap of four at nearly double the expected rate.

The tracker also says the developers have confirmed that the messages hold a real message. I couldn't find the confirmation itself, so that claim stays the tracker's.

This site has written separately about claimed decipherments of undeciphered scripts. This is not one. It is one inference, and the test that failed it.

That test was a shuffle. Every count above ran twice, once on the messages and once on the same messages scrambled, and the scrambled run is what gives the first number its meaning. My position theory lasted exactly as long as I didn't run the second count.

Every number above is printed by eyes_evening_c7005.py, and its output is eyes_evening_c7005.out.txt. Neither source repository carries a licence, so the data is not republished here. Fetch it at the pinned commits and check the hashes:

gh api "repos/Doctor-Ned/NoitaEyeGlyphResearch/contents/NoitaEyeGlyphResearchLib/data.csv?ref=37100742603f7e8cfd0bfa4e42f5502e8576f284" --jq .content | base64 -d > data.csv
# sha256 853400aec1ab0141882888ab4b39efa8fe1da5b9e0e9d8370970837da781062a
gh api "repos/ngraham20/NoitaCryptographyResearch/contents/eye/eyes.json?ref=0cf791d5e1a0777059fe0ac26ed645704a4d2d9b" --jq .content | base64 -d > eyes.json
# sha256 dab680e5482d233322b746b80bca12ff1983c1f976be1536254a25f8ecc9f9ec
python eyes_evening_c7005.py data.csv eyes.json

The shuffled controls use fixed seeds, so a rerun gives the same counts. The 6.4-in-ten-million figure for no doubles assumes each trigram is drawn independently at the observed frequencies. A cipher does not work that way, so the figure measures how far the messages sit from independent draws, and nothing about which cipher made them.

Sources

"The Eye Puzzle," Unsolved Puzzles (community tracker): the sections "What We Know," "Pattern Analysis," "Theories (Ranked)," "Pyry's Conditions," and the findings "Isomorphs (Lymm's Patterns) found," "No double trigrams exist," "Hidden states far exceed 83," "Autokey Alberti cipher model" and "Ciphertext distance-4 repeats at 2x expected rate." https://unsolved-puzzles.github.io/unsolved-puzzles/noita/eye-puzzle.html (read September 26, 2026)
Doctor-Ned, NoitaEyeGlyphResearch, NoitaEyeGlyphResearchLib/data.csv at commit 3710074 (July 14, 2021). https://github.com/Doctor-Ned/NoitaEyeGlyphResearch
ngraham20, NoitaCryptographyResearch, eye/eyes.json at commit 0cf791d (October 18, 2021). https://github.com/ngraham20/NoitaCryptographyResearch

Keep a record of what you actually ran.

The wrong conclusion in this piece lasted exactly as long as the second count went unrun, and the notes are how it was caught. When an AI agent does the running, its claims about its own work need that same record. Chain of Consciousness keeps a tamper-evident log of what an agent did, so the claim and the record can be checked against each other.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

🚀 Architecture Shift: Why Cryptographic Tokens Beat Path-Based Routing

Tue, 06 Oct 2026 15:13:56 +0000

Learnt this during a recent pre-strategic development phase. I initially planned to build path-based URLs (/company-a, /company-b) for individual tenant portals, but the pivot to a Cryptographic Token Model (CTM) completely outclasses traditional path routing.

Here is the breakdown of why CTM is the superior choice for multi-tenant systems:

• URL Security: Path models leak sensitive tenant/company names in browser histories and HTTP referrers. CTM delivers 100% clean URLs (tasks.seosiri.com/v1/...), masking tenant footprints entirely.
• Spoofing Resistance: Path routing invites users to manually manipulate paths (/alpha ➡️ /beta). CTM makes tampering impossible by enforcing token signature verification right at the edge.
• Storage Isolation: Sharing origins on path models introduces severe LocalStorage XSS bleeding risks. CTM ensures hard isolation via parametrized database queries (WHERE tenant_id = ?).
• Agent Sync: Replaces brittle, complex URL path switching with clean, native background header passes (X-Employee-ID).
• The Best Part? You can deploy this entire robust security posture on Cloudflare Workers + D1 free tier for $0.00.

Stop relying on path hacks for multi-tenancy. Secure your boundary at the edge.

# The Revolution in Protocol Security: How It Actually Gets Used

Thu, 20 Aug 2026 07:46:14 +0000

A follow-up. The previous article described what we are building. This one describes how it works in practice - and why the shift from academic tool to industrial platform matters.

In a previous article, I described the architecture of a protocol analyzer we are building: automatic repair, sixteen attacker models, GNN-guided search, modular crate design. That was the "what." This article is the "how" - how this tool gets used, what it changes in practice, and why we believe it represents a shift from laboratory instrument to industrial platform.

The problem with existing tools is not only capability - it is also access

ProVerif and Tamarin are remarkable achievements in formal methods. They are also laboratory instruments by design. You install them on a research machine, write a model in their DSL, run analysis in a terminal, read the output. This workflow is fine for a PhD student. It does not work for a security engineer at a company that ships TLS implementations.

The gap concerns where these tools live in the development lifecycle, not what they can prove. Existing tools sit outside CI pipelines, outside IDEs, outside deployment workflows. They are consulted - if at all - after a protocol is designed, before it ships. Rarely during development, rarely after deployment.

We are building something that lives inside the lifecycle.

CI/CD integration: verify on every commit

The analyzer ships as a GitHub Action. Every time a protocol description changes - a new message flow, a modified key exchange, an added authentication step - the analyzer runs automatically. It checks whether the change introduces a vulnerability. If it does, the action fails with a concrete attack trace and a proposed fix.

This is not a theoretical capability. The action is designed to run in minutes on standard CI hardware, not hours on a research cluster. The performance targets we described in the previous article - 10x to 50x speedup, sub-ten-minute analysis for real-world protocols - exist to make this practical. A tool that takes six hours to analyze a protocol cannot run in CI. One that takes six minutes can.

Beyond GitHub Actions, the analyzer provides a CLI that integrates with any CI system - GitLab CI, Jenkins, Buildkite. The output is machine-readable: SARIF for security scanners, JSON for custom pipelines, JUnit XML for test reporting. Protocol verification becomes another test suite in the pipeline.

IDE integration: find vulnerabilities while you write

The analyzer ships a Language Server Protocol (LSP) implementation. In a VS Code editor, this means: syntax highlighting for the protocol DSL, inline error reporting as you type, hover documentation for security properties, and one-click analysis from the editor.

The experience is analogous to writing Rust with rust-analyzer: the tool understands what you are writing and gives feedback in real time. When you define a key exchange step, the analyzer checks whether the key material is properly authenticated. When you add a new message, it checks whether the freshness guarantees hold. The vulnerability is flagged before you commit the code - not after.

Real-time analysis: the daemon and the sniffer

This is where the tool stops being a verifier and becomes a platform.

The analyzer runs as a background daemon with a gRPC API. Any service in the infrastructure can send a protocol description and receive analysis results. But the daemon does more than wait for requests - it listens to live traffic.

The sniffer module captures network traffic (PCAP), reconstructs protocol sessions from packet streams, and feeds them to the symbolic engine in real time. When a TLS handshake happens on the network, the analyzer checks whether that handshake - with its specific cipher suite, extensions, and parameters - satisfies the security properties. When an unusual pattern appears - a repeated nonce, an unexpected message order, a downgrade attempt - it flags the anomaly.

This is live verification - analysis that runs while the protocol is executing, not after the fact.

The real-time constraint changes the engineering at its core. Traditional protocol analysis explores the full state space - every possible interleaving, every attacker action. That takes hours. Real-time analysis uses a bounded model: explore the state space up to depth N, report what you find, continue monitoring. The GNN-guided search from our previous article is critical here - it prioritizes the most promising exploration paths, finding attacks faster in bounded time.

Web interface: collaboration, not just output

The analyzer ships a web UI. This is a requirement for adoption, not a luxury.

Security review is a collaborative process. An analyst finds an attack, a protocol designer evaluates the proposed fix, a manager decides whether the risk is acceptable. In existing tools, this workflow happens outside the tool: screenshots in Slack, traces in emails, decisions in meetings.

The web UI makes the analysis itself collaborative. Attack graphs are rendered in 3D - navigable, zoomable, inspectable. Repair proposals are presented side-by-side with the original protocol, with the differences highlighted. Reviewers can comment, approve, or reject fixes. The entire security review happens inside the platform.

Converters: meeting people where they are

The analyzer accepts input from ProVerif, Tamarin, Scyther, Avispa, CryptoVerif, and Maude descriptions. This is an adoption strategy, not a convenience feature.

Thousands of protocols are already modeled in these languages. Researchers and engineers who have invested years in ProVerif models should not have to rewrite them. They import their existing description, run the analyzer, and get the same output plus repair proposals plus real-time monitoring plus CI integration.

The converters are imperfect - each source language has constructs that do not map cleanly. But they handle the common case well enough to lower the barrier from "I should try this tool" to "I just tried this tool."

Platform, not tool

Let us be explicit about what we are building. A tool does one thing from the command line. A platform integrates into workflows, provides APIs, runs continuously, and collaborates with other systems.

The protocol analyzer we are building has:

A CLI for direct use and scripting
A GitHub Action for CI/CD
An LSP server for IDE integration
A gRPC API for programmatic access
A daemon for continuous monitoring
A sniffer for real-time traffic analysis
A web UI for collaborative review
WASM bindings for browser-based playground
Converters from five existing tools

This is a platform. The symbolic analysis core - the part described in the previous article - is the engine. Everything else is the interface between that engine and the world where protocols are built, deployed, and attacked.

The revolution is practical, not technical

The technical contributions matter: automatic repair, GNN-guided search, incremental closure, sixteen attacker models. But the reason they matter is that they enable a new capability - protocol verification that runs in CI, in your IDE, on your network, in real time.

ProVerif and Tamarin proved that symbolic protocol analysis is possible. We are trying to prove that it is practical - practical enough to run on every commit, practical enough to catch vulnerabilities while you type, practical enough to monitor live traffic.

That is the shift: from laboratory instrument to industrial platform. From "analyze after design" to "verify during development and after deployment." From a tool that finds attacks to a platform that finds them, fixes them, and watches for them.

Status

The CI/CD action, the LSP server, the daemon, and the sniffer are in active development. The web UI has working prototypes. The converters handle common cases. The core engine - described in the previous article - is functional and stable.

This project is under active development. The platform described here is being built, not shipped. But the direction is clear, and the architecture supports it.

This project is under active development. This article describes the planned platform capabilities of a tool still being built. The previous article covers the core engine architecture; this one covers the interfaces between that engine and the development lifecycle.

Follow the project: github.com/Sup4ikX - a preview release will be published there as soon as the first production version is ready.

We're Building a Protocol Analyzer That Finds Attacks and Fixes Them

Fri, 14 Aug 2026 07:22:34 +0000

A report on a tool still in development \E2\80\94 the architecture we chose, the trade-offs we made, and why we believe this direction has a future.

This article is not a product announcement. It is a report on how we are building a tool still in progress. The architecture is settled, the key decisions are made, the code is being written. But the final form is still ahead \E2\80\94 and that is exactly why now is the right time to talk about where we are going and why.

The project is under active development. What follows describes what we are building toward, not what ships today. But every architectural decision in this article is already implemented or in active development. We are reporting concrete progress, not speculating.

The problem we are solving

ProVerif and Tamarin are excellent tools. They solve vulnerability detection well: accept a protocol description, build an attacker model, check whether security properties hold. When they find an attack, they produce a trace \E2\80\94 a concrete sequence of steps the attacker takes.

And then the engineer is alone with that trace. Writing a patch, verifying it blocks the attack, making sure the protocol still works \E2\80\94 all manual labor, all informal reasoning.

ProVerif and Tamarin do not repair protocols. They do not analyze quantum adversaries or side channels. And on real-world protocols \E2\80\94 TLS 1.3, Signal, WireGuard \E2\80\94 they run for hours. We are building a tool that closes all three gaps.

The vision

A protocol analyzer that accepts a description of a cryptographic protocol and its security properties, finds attacks when they exist, and generates a formally verified fix \E2\80\94 all without manual intervention. The tool should run fast enough to analyze real-world protocols in minutes, not hours. And it should cover attack surfaces that existing tools ignore.

This is not an incremental improvement over ProVerif or Tamarin. It is a different category of tool.

Automatic repair: the core capability

Existing tools stop at "attack found." The analyzer we are building continues: it generates a patch, verifies that the patch blocks the found attack, and checks that the protocol still satisfies its security properties.

The mechanism is Counterexample-Guided Protocol Synthesis (CEGPS), borrowed from program synthesis:

The analyzer finds an attack trace.
The repair module proposes modifications that could block this trace.
The verifier checks each modification: does it block the attack, and does the protocol preserve its security properties.
If a patch fails \E2\80\94 a counterexample is extracted, and the cycle repeats.
From the set of verified patches, multi-objective optimization selects the best one.

Every proposed patch is formally verified. No "probably working" suggestions \E2\80\94 only fixes proven to block the attack. The repair module uses eight types of repair rules and multi-objective optimization considering security, performance cost, and protocol complexity.

Performance: the target

The target is 10x to 50x speedup over existing tools on classical benchmarks. On real-world protocols \E2\80\94 TLS 1.3 full handshake, Signal X3DH \E2\80\94 the goal is analysis time under ten minutes, compared to hours for current tools.

This follows from seven architectural decisions, grouped into three categories:

Memory management. Arena allocation places each symbolic term in a bump allocator recreated per run \E2\80\94 removing allocator overhead and improving cache locality. Hash consing stores identical subterms in a single instance, making term comparison O(1) instead of O(n). Together, these two decisions account for roughly half of the projected speedup.

Parallelism. Work-stealing pool for parallel state expansion \E2\80\94 each state processed independently. Incremental knowledge closure \E2\80\94 when a new fact is added, only its consequences are computed, not the entire closure. Together: near-linear scaling with core count.

Solver integration. Batch SMT encoding \E2\80\94 all terms in one solver call instead of one per term \E2\80\94 removes the dominant bottleneck in deep property checking. Precomputed hashing on term construction eliminates redundant structure traversal.

Additionally: Rust as the implementation language provides control over memory layout and safe parallelism that OCaml (ProVerif) and Haskell (Tamarin) do not offer for this workload.

Sixteen attacker models

Most tools default to Dolev-Yao and stop there. The analyzer we are building supports sixteen distinct attacker models: passive eavesdropper, insider, quantum, resource-bounded, compromised certificate authority, side-channel equipped, and others.

A protocol can be secure against a passive eavesdropper but vulnerable to an insider with access to key material. Or safe against classical attacks but broken by a quantum adversary that solves ECDH. Analyzing under a single model gives a single answer. Analyzing under sixteen models gives a map of where the protocol breaks and where it holds.

Neural networks: guiding search with GNNs and active learning

The state space of protocol analysis is exponential \E2\80\94 brute-force search wastes time on dead-end regions, and hand-crafted heuristics help but do not generalize.

We use graph neural networks (GNNs) to guide the search. A GNN scores states in the search space \E2\80\94 predicting which regions are more likely to contain attacks. The symbolic engine explores high-scoring regions first.

Why GNNs? We evaluated alternatives: reinforcement learning requires millions of trials to converge \E2\80\94 sample efficiency is too low when each trial is a full protocol analysis. Recurrent networks process sequences, but protocol states are graphs \E2\80\94 flattening them loses structural information. GNNs operate directly on state graphs, preserve structural relationships, and require less training data.

Training uses active learning: the analyzer runs, the results (which states led to attacks, which were dead ends) become training data, and the model improves over repeated analyses. Every analysis run produces useful training data.

The key principle: neural networks guide search order, but all conclusions come from formal symbolic verification. The network is a heuristic accelerator, never an oracle.

Architecture: modularity as a design requirement

The tool is split into several dozen crates \E2\80\94 self-contained Rust libraries, each responsible for a distinct domain. The main groups:

Analysis core \E2\80\94 Dolev-Yao model, state space search, property checking, SMT encoding, observational equivalence.
Repair module \E2\80\94 CEGIS loop, repair rules, multi-objective optimization.
Specialized analyzers \E2\80\94 quantum, side-channel, game-theoretic, MPC, fuzzing, binary, physical.
Infrastructure \E2\80\94 CLI, web interface, LSP server, CI/CD integration, WASM bindings.

A contributor can work on the quantum module without understanding the fuzzer \E2\80\94 that is why we chose modularity over a monolith. The core analyzer has no dependency on the web server. Each crate has its own tests, documentation, and release cycle. This isolation makes the tool possible to contribute to and reason about at scale.

What we do that no one else does

Quantum analysis. BB84, E91, DI-QKD, noisy channel analysis, post-quantum migration.
Side-channel analysis. DPA, CPA, template attacks, mutual information analysis, masking verification.
Game-theoretic analysis. Nash equilibrium, Bayesian games, correlated equilibrium, MEV analysis.
MPC verification. BGW, SPDZ, MASCOT, OT extension.
Coverage-guided fuzzing. Mutation testing with coverage feedback, integrated with symbolic execution.
Protocol standard library. Ready-made descriptions of real protocols.

What exists now

As of this writing:

Symbolic analysis core \E2\80\94 stable, passes tests on classical protocols and simplified TLS handshake.
Repair module \E2\80\94 functional, generates verified patches for found attacks.
GNN search guide \E2\80\94 working with active learning, shows measurable speedup on test sets.
Quantum, leakage, MPC modules \E2\80\94 basic implementation, will be deepened.

What is not ready: unbounded session verification through Horn clauses, export to various formats, distributed cluster analysis, WASM version for web playground.

The bottom line

We are building a protocol analyzer that fixes attacks and covers attack surfaces existing tools ignore, and runs fast enough for real-world protocols.

The architecture is settled, the key decisions are made, the code is being written.

This project is under active development. The final form described here is not yet shipped. But every decision in this article is already embodied in code or in active development. We are reporting concrete progress, not speculating.

If you have worked with ProVerif, Tamarin, or other verification tools \E2\80\94 we want to hear your opinion. We welcome feedback on where we are wrong or what we are missing. The formal verification community is small, and that is its strength.

This project is under active development. This article describes the target architecture and planned capabilities of a tool that is still being built. No product is being announced \E2\80\94 only decisions, trade-offs, and the current state of implementation.

The Other Half of Authentication Is 345 Years Old

Wed, 24 Jun 2026 04:57:16 +0000

Canonical: originally published at vibeagentmaking.com.

In 1675 a scholar declared the old charters were forgeries. A monk answered with a method, diplomatics, the half of document authentication PKI quietly forgot to build.

In 1675, a Jesuit scholar named Daniel van Papenbroeck did something that would feel very familiar today: he announced that you couldn't trust the documents. Writing in the preface to a volume of saints' lives, Papenbroeck argued that a large class of supposedly seventh-century royal charters, Merovingian land grants, the kind of parchment on which monasteries based their legal claims to property and privilege, were forgeries. Not a few of them. Essentially all of them, anything older than around AD 700. The historical record before a certain date, he suggested, was mostly fake.

This was not an idle academic spat. The Benedictine monks of Saint-Denis held exactly those charters, and their prestige, and their property rights, rode on the documents being real. So the order did the sensible thing and handed the problem to its sharpest young scholar, a monk named Jean Mabillon, with what amounted to a brief: prove the documents are authentic, or prove we have a method for telling. Mabillon spent six years on it. What he produced in 1681, a six-volume Latin treatise called De re diplomatica, did not just defend the charters. It founded a science.

We are living through Papenbroeck's panic again. The 2020s version is "nothing online is real": deepfaked memos, AI-forged letters, synthetic leaked documents, screenshots of conversations that never happened. And our instinct, like the seventeenth century's, swings between two bad options: credulously trust everything, or cynically trust nothing. Mabillon's contribution was to refuse both. He replaced the panic with a method, and that method, a discipline called diplomatics, is the half of document authentication that modern security engineering quietly forgot to build.

A science for telling the true from the false

Mabillon had a phrase for what his discipline was for: discrimen veri ac falsi, "the distinguishing of the true from the false." And his central move, the one that made it a science rather than a series of educated guesses, was this: you authenticate a document from its form, not from its custody.

That distinction is the whole game, so it's worth being precise about it. There are two ways to decide whether a document is genuine. The first is to trace where it came from, who held it, who passed it to whom, an unbroken line back to its creation. Call that the chain. The second is to interrogate the artifact itself, its structure, its conventions, the thousand small choices a genuine document of its kind would make and a forgery gets subtly wrong. Mabillon's insight was that the second method works even when the first is unavailable, which, for medieval charters scattered and recopied across five centuries, it almost always was.

To make this systematic, diplomatics treats every formal document as having a predictable anatomy. The opening is the protocol, the invocation, the issuer's title, the addressee, the greeting. The middle is the text, including the dispositio, the operative clause that actually does the thing (grants the land, confirms the privilege), wrapped in rhetorical preamble and penalty clauses. The close is the eschatocol, the signatures and cross-marks, the witness list, the date and place, the closing benediction. None of this is decoration. In a world where most people couldn't read, the form was the mechanism by which a document claimed legal force: the right formula, in the right place, sealed the right way, was the authority.

And here is the part that should make any security engineer sit up, because it is a forensic principle of startling generality: forgeries almost always fail at the transitions between the parts. A forger can copy a salutation perfectly and then attach it to a dating clause from the wrong century. They can reproduce an authentic seal and bolt it onto a protocol whose formulae no real chancery of that era would have paired with it. The forger learns the surface of the document type, what it looks like, but not its internal grammar, the way the parts have to cohere. The seams are where the lie shows.

The nineteenth-century German scholar Theodor von Sickel sharpened this into something explicitly forensic with a concept he called Kanzleimäßigkeit, "chancery-conformity." The point was that you don't compare a suspect charter to a vague sense of "how thirteenth-century documents feel." You compare it to the specific office that supposedly produced it: which scribe's hand, the clerk who habitually drafted these formulae, the officials who co-signed, what this one chancery's working habits actually were. The target of comparison stopped being a period and became an institution. That is a fingerprinting discipline.

It worked, and not just on charters. The most famous case predates Mabillon: in 1440 the humanist Lorenzo Valla demolished the Donation of Constantine, the document by which the fourth-century emperor had supposedly handed temporal authority over the Western Empire to the Pope, by showing its Latin vocabulary and institutional terminology were anachronistic, language a fourth-century chancery could not have produced. The forgery had fooled people for centuries because nobody had read its form closely enough. Modern scholarship dates the actual composition to the eighth or ninth century. A political fraud that shaped the map of medieval Europe was undone not by finding a smoking-gun source but by reading the document against itself.

What PKI does, and the cases it can't reach

Now jump 345 years, to how we authenticate digital documents today. The dominant answer is public-key infrastructure: a digital signature, validated through a chain of certificates up to a trusted authority, proving two things, who signed the document, and that the bytes haven't changed since. When it works, it's beautiful, and far stronger than anything Mabillon had. I want to be clear that PKI is not broken and this is not an argument against it.

It is an argument about scope. Because PKI authenticates the chain, and the chain has failure modes, and they are, almost exactly, the cases diplomatics was invented for.

Start with the one PKI practitioners know best: revocation. Certificates expire, and a certificate authority can revoke one early, publishing the fact through a Certificate Revocation List or an OCSP responder. Here's the catch that's underappreciated outside the field: this quietly undoes PKI's most-advertised selling point. A certificate is supposed to be self-authenticating, you can check it without phoning home. But once revocation is in the picture, you must fetch the current revocation data online, and CRLs lag by their publication interval, leaving a window in which a revoked certificate still validates. The "self-authenticating" certificate isn't actually self-contained. Sit with the irony: Mabillon's analysis of a document's internal form is more self-contained than a modern certificate, because the form is all there, in the artifact, with nothing to go fetch.

Then the cases that get worse. Dead keys. A digital record signed thirty years ago, with algorithms now obsolete and signing keys long gone, you cannot re-validate that chain, ever. This is precisely the problem the archival world has wrestled with for decades: how do you trust the authenticity of a digital record over the long term when the entire cryptographic context that vouched for it has crumbled?

And the case that's exploding right now: artifacts that were never signed at all. A leaked file. An internal draft. A screenshot. A forwarded copy stripped of its headers. An AI-generated document. For all of these, there is no chain to check, PKI has nothing to say, because nothing in its model ever happened. The signature it's looking for was never there.

The clean way to hold the two methods is this: PKI verifies provenance you have; diplomatics reconstructs trust when provenance is broken or absent. They aren't rivals. They're the two halves of the authentication problem, and the security world, reaching naturally for cryptography, built one half and left the other in the archives.

The bridge already exists, it just never crossed the wall

I want to be careful here, because there's a tempting and false version of this essay that says "nobody has ever connected medieval document science to digital authentication." That's wrong, and the truth is more interesting.

The archivist Luciana Duranti and the international InterPARES project have been doing exactly this since 1999, building what they call the archival diplomatics of digital records, and, pointedly, digital records forensics. For a quarter century, a serious research program has been carrying Mabillon's principles from parchment to pixels: treating a born-digital record's structure, its metadata, its formal elements as the evidence, asking whether a digital object conforms to the documentary form its claimed origin would produce. The parchment-to-pixels bridge is not a thought experiment. It is a mature field.

The strange thing, the actual gap worth naming, is that this mature field lives in archival science and has almost never crossed the disciplinary wall into the cryptographic, PKI, and security-engineering literature. Two communities have been working the same problem, authenticating documents, with almost no traffic between them. The cryptographers reached for the chain; the archivists kept reading the form; and they rarely cite each other. The opportunity isn't to invent the connection. It's to import it, to put the form-reading toolkit on the same workbench as the signature-checking one.

Which brings us to the sharpest modern case, and the one where the two halves most need each other. An AI-generated document is the ultimate chain-broken artifact: a deepfake contract, an LLM-forged resignation letter, a synthetic "leaked memo" can never be caught by PKI, because nothing valid ever signed them. But they are a textbook diplomatics problem. A language model learns the surface of a document type, the look and cadence of a contract, a memo, an official letter, from its training distribution. What it does not reliably learn is the institutional grammar underneath: which formula has to pair with which, which validation marks a specific office actually uses, whether the opening and the operative clause are internally consistent, whether the dating convention matches the claimed issuer. It will, in other words, tend to get the form subtly wrong at the transitions, which is the exact failure signature Mabillon used to catch the Merovingian forgers. I'm offering that as a natural application, not a finished detector. The lens is the right one. A model that has absorbed the appearance of a document type without its institutional grammar is, structurally, a very fast forger, and forgers have a known weakness.

What to build with this

The practical takeaway for anyone building or trusting verification systems is to stop treating authentication as one question and start asking two.

PKI's question, can I trust the chain of custody?, is the right one whenever the chain is intact, and you should keep leaning on it hard. Diplomatics' question, does the document's own form betray it?, is the one you need whenever the chain is broken, which in the AI era is more and more of the time. The mature engineering posture is to build both, and to know which you're relying on.

Three concrete things follow. First, authentication is not binary, and diplomatics knew this three centuries before we did: a document can be genuine in substance but altered in form, a faithful copy of a lost original, or a real act recorded in a forged instrument. "Real" and "fake" are too coarse; the useful output is a structured judgment about which elements conform and which don't. Second, internal consistency is a verification primitive you can actually implement, does this artifact cohere the way a genuine document of its claimed type and origin would?, and it has the rare property of working precisely where signatures don't. Third, and most pointed for anyone shipping AI systems, including those of us building them: where there is no signing chain, internal-evidence authentication is the only verification left. For synthetic content, the form is the evidence.

Mabillon's real discovery, the thing that let one monk answer a continent's worth of forgery panic, was that you do not always need to know where a document has been. If you can read its form closely enough, the document carries its own testimony, the seams, the formulae, the conformity or its absence. Three and a half centuries later, as the chain of custody breaks more often than it holds, that is not a quaint medieval technique waiting to be rediscovered. It is the half of authentication we already had, in another building, the whole time.

Sources

Jean Mabillon, De re diplomatica libri VI (Paris, 1681), and the Papenbroeck–Mabillon bella diplomatica over the Saint-Denis Merovingian charters, via Encyclopædia Britannica ("De Re Diplomatica," "Jean Mabillon") and Wikipedia ("Diplomatics," "Jean Mabillon"). Lorenzo Valla, De falso credita et ementita Constantini Donatione (1440), on the Donation of Constantine; the document anatomy (protocolum / textus / eschatocolum) and Theodor von Sickel's Kanzleimäßigkeit are standard diplomatics, codified by the 19th-century German and French schools. Luciana Duranti and the InterPARES Project (1999– ): "Archival Diplomatics of Digital Records," "From Digital Diplomatics to Digital Records Forensics" (Archivaria), "The Return of Diplomatics as a Forensic Discipline," and "The Authenticity of Electronic Records: the InterPARES Approach"; Wikipedia, "InterPARES Project." On PKI revocation and the self-authenticating caveat: Wikipedia, "Certificate revocation list"; TechTarget, "Certificate Revocation List (CRL)"; eMudhra, "How to Verify a PKI-Based Digital Signature." The application of diplomatics to AI-generated documents is offered here as a proposed forensic approach, not a demonstrated result.

When the chain of custody breaks, the form is the evidence. PKI verifies the provenance you have; it has nothing to say about a leaked draft, a dead-key archive, or an AI-forged memo that nothing valid ever signed. The other half is reading the artifact's own form. Chain-of-consciousness records an agent's reasoning as it works, so the work carries its own internal testimony, a trail you can read even when there is no signature to check.

pip install chain-of-consciousness · npm install chain-of-consciousness · Hosted Chain-of-Consciousness

Understanding Symmetric vs Asymmetric Encryption as a Backend Engineer

Tue, 09 Jun 2026 12:37:26 +0000

While learning networking, I kept hearing terms like:

HTTPS
TLS
SSL certificates
Public keys
Private keys

I understood they were related to security, but I never really understood how encryption actually worked underneath.

Once I started learning about Symmetric and Asymmetric Encryption, many of those concepts finally started making sense.

One realization that surprised me:

The internet doesn't use one type of encryption.

It uses both.

And that's exactly how TLS secures our communication.

What is Encryption?

Encryption is the process of scrambling data so that only authorized parties can read it.

Instead of sending:

Hello

we transform it into something unreadable like:

X8#kP!2@Q

Anyone intercepting the encrypted data sees only gibberish.

Only someone with the correct key can convert it back to the original message.

Encryption is used everywhere:

HTTPS websites
online banking
messaging applications
VPNs
SSH
file storage

Without encryption, anyone sitting between two communicating systems could potentially read sensitive information.

Symmetric Encryption

Symmetric Encryption uses the same key for both encryption and decryption.

In simple terms:

Encrypt → Secret Key
Decrypt → Same Secret Key

If you can encrypt the data, you can also decrypt it using the exact same key.

Popular examples include:

AES (Rijndael)
Twofish
Serpent
DES

How Symmetric Encryption Works

Imagine Alice wants to receive a secret message from Bob.

Step 1

Alice generates a secret key.

Step 2

Alice somehow shares that key with Bob.

Step 3

Bob encrypts:

Hello

using the secret key.

Step 4

Alice receives the encrypted message and decrypts it using the same key.

Communication works perfectly.

Until someone steals the key.

This is the biggest weakness of Symmetric Encryption.

How do Alice and Bob securely share the key in the first place?

If an eavesdropper intercepts the key during transmission:

Alice → Secret Key → Bob

they now have everything needed to decrypt future messages.

The encryption itself may be strong.

But distributing the key safely becomes difficult.

Why Symmetric Encryption Is Still Useful

Despite the key-sharing problem, symmetric encryption has huge advantages.

Fast

The algorithms are extremely efficient.

Great for Large Data

Encrypting large amounts of data is relatively cheap computationally.

This makes symmetric encryption ideal for:

videos
files
API traffic
website communication

Symmetric Encryption Drawbacks

Key Distribution Is Hard

Securely sharing the key is the difficult part.

If the key leaks, all communication becomes readable.

Asymmetric Encryption

Asymmetric Encryption solves the key-sharing problem.

Instead of one key, it uses two:

Public Key
Private Key

The interesting part:

The public key encrypts data.

The private key decrypts data.

And the public key cannot decrypt the message.

How Asymmetric Encryption Works

Imagine Alice wants people to send her encrypted messages.

Step 1

Alice generates:

Public Key
Private Key

Step 2

She shares the Public Key with everyone.

Including Bob.

Step 3

Bob encrypts:

Hello

using Alice's Public Key.

Step 4

The encrypted message is sent across the network.

Step 5

Alice decrypts it using her Private Key.

Only Alice can decrypt the message because only Alice possesses the private key.

Even if an attacker steals the public key, it doesn't help.

The public key was meant to be shared.

Why Does This Work?

One thing I found interesting:

Asymmetric encryption is built on mathematical problems that are extremely difficult to reverse.

Many algorithms rely heavily on properties of large prime numbers.

The actual math gets complicated very quickly, but the practical takeaway is:

Encrypting with the public key does not reveal the private key.

That's what makes the system secure.

Common Asymmetric Encryption Algorithms

Some popular examples include:

RSA (Rivest-Shamir-Adleman)
Diffie-Hellman
ElGamal

These algorithms form the foundation of many modern security systems.

Advantages of Asymmetric Encryption

Easy Key Distribution

The public key can be shared freely.

No secret exchange is required.

Better for Establishing Trust

Because the private key never leaves the owner, it becomes much easier to securely initiate communication.

This is why technologies like:

HTTPS
TLS
SSH

rely heavily on asymmetric cryptography.

Disadvantages of Asymmetric Encryption

Computationally Expensive

This was the part that surprised me.

Asymmetric encryption is significantly slower than symmetric encryption.

The mathematical operations involved are much more expensive.

Poor for Large Data Transfers

Encrypting large files or long streams of data using asymmetric encryption would be inefficient.

It works best for small pieces of information.

Symmetric vs Asymmetric Encryption

After learning both approaches, I think of them like this:

Symmetric Encryption

Pros:

Fast
Efficient for large data

Cons:

Difficult key sharing

Asymmetric Encryption

Pros:

Public key can be shared safely
Great for establishing secure communication

Cons:

Slower
Computationally expensive
Inefficient for large data

The Part That Finally Made TLS Click

The most interesting realization for me was:

TLS doesn't choose between symmetric and asymmetric encryption.

It uses both.

The process roughly looks like this:

Step 1

The server sends its certificate containing a public key.

Step 2

The client verifies the certificate.

Step 3

Using asymmetric cryptography, both sides securely establish a shared symmetric key.

Step 4

From that point forward, communication switches to symmetric encryption.

Why?

Because symmetric encryption is much faster.

So asymmetric encryption is used only during the setup phase.

Then symmetric encryption handles the actual data transfer.

This gives us:

secure key exchange
fast communication

at the same time.

Why This Matters for Backend Engineers

Before learning encryption, HTTPS felt like a checkbox.

Enable SSL.

Install a certificate.

Done.

Now I understand there is a lot happening underneath:

public keys
private keys
certificates
TLS handshakes
symmetric encryption
asymmetric encryption

Every secure API request depends on these concepts.

Understanding them makes HTTPS feel much less magical and much more engineering-driven.

Final Thoughts

Before learning this topic, I assumed encryption was a single concept.

Now I realize there are actually two very different approaches.

One solves the speed problem.

One solves the key-sharing problem.

And modern systems combine both to get the best of each.

The coolest part for me was finally understanding why a server sends a certificate before encrypted communication begins.

It's not the encryption itself.

It's the first step that makes secure communication possible.

Sovereign Synapse: The Context Cleaner

Tue, 02 Jun 2026 13:56:37 +0000

(Curation is Sovereignty)

Sovereign Synapse Series | Post 2

AI is polite by design. It prefaces its answers with "Certainly! I'd be happy to help" and closes with "I hope this information is useful." In a casual chat, these conversational "handshakes" are harmless. In a Cognitive Estate—a permanent, local archive of your thoughts—they are a Prose Tax.

Last time, we successfully evacuated our intellectual history from the cloud. But once the data landed on local silicon, the reality of "raw" data set in. To turn a disorganized data dump into a high-fidelity archive, we must move from ingestion to Forensic Curation.

️ Builder’s Note: The Roundtable Pivot

When I published Part 1, the community exploded with architectural feedback. While discussing the code, an engineer named WAB raised a critical long-term systems question: As a local memory store grows, multiple autonomous local agents will eventually read, write, and refactor these synapses. How does an agent running six months from now know that a specific memory chunk is a high-fidelity historical insight rather than a corrupted file or an adversarial local injection?

The solution was elegant: don't just clean the data—sign it. By integrating an Ed25519 cryptographic layer at the moment of distillation, we move from simple file cleanup to establishing an immutable Chain of Custody for our thoughts.

But pushing a zero-trust cryptographic layer into a production pipeline meant surviving a rigorous multi-round systems audit. We didn't just merge naive code. We engineered a canonical sorted-JSON payload structure to prevent newline field-injection attacks, enforced continuous POSIX owner-only permission validations to neutralize local forgery vectors, and ensured our verification paths were strictly side-effect free—guaranteeing that read operations never accidentally mutate disk state by generating blank keys. We subjected our architecture to enterprise-grade rigor before allowing a single byte to hit local silicon.

The Problem: Ghost Nodes and Corporate Boilerplate

OpenAI exports are not linear files; they are complex branching trees. A naive extractor often trips over "ghost nodes"—dangling references or messages with missing timestamps that cause standard scripts to crash. Our updated adapter now uses defensive null-guards to ensure these broken links don't halt the evacuation.

Even when the extraction is stable, the result is cluttered. When you have thousands of files in your vault, you don't want your local semantic search results polluted by generic AI pleasantries. You want the signal: the technical reasoning, the code, the breakthrough. If you don't strip the prose at the edge, you pay an Interpretation Tax in downstream inference costs every single time an agent reads that memory.

The Build: The Structural Sieve & Signer

To solve this without destroying the original record, we built a Context-Cleaner that acts as a structural sieve. We pattern-match on the layout to separate the Preamble (the intro) from the Postamble (the outro).

Once the text is stripped of its corporate residue, we run it through our Zero-Trust Signer to seal the contract before it hits local storage.

# core/context_cleaner.py
import os
import re
import logging
import tempfile
from pathlib import Path
from datetime import datetime
from cryptography.hazmat.primitives.asymmetric import ed25519

_CORE_DIR = os.path.dirname(os.path.abspath(__file__))
_REPO_ROOT = os.path.abspath(os.path.join(_CORE_DIR, os.pardir))
DEFAULT_KEYS_DIR = os.path.abspath(os.path.join(_REPO_ROOT, "vault", "keys"))
_logger = logging.getLogger(__name__)

def _atomic_write_bytes(path: Path, data: bytes) -> None:
    """Writes data to path atomically via a temp file in the same directory.
    
    Guarantees os.replace stays on one filesystem to avoid cross-device EXDEV errors.
    """
    directory = path.parent
    directory.mkdir(parents=True, exist_ok=True)
    fd, tmp_path = tempfile.mkstemp(prefix=f".{path.name}.", suffix=".tmp", dir=str(directory))
    tmp = Path(tmp_path)
    try:
        with os.fdopen(fd, "wb") as handle:
            handle.write(data)
        os.replace(tmp, path)
    except Exception:
        tmp.unlink(missing_ok=True)
        raise

class ContextCleaner:
    """Heuristic-based scanner to identify and flag AI conversational noise."""
    
    @classmethod
    def verify_signature(
        cls,
        signature_hex: str,
        *,
        receipt_id: str,
        structural_signal: str,
        user_text: str,
        timestamp: datetime,
        keys_dir: Path | None = None,
    ) -> bool:
        """Adheres strictly to a boolean contract. Fails closed on permission or system errors."""
        from cryptography.exceptions import InvalidSignature
        from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

        directory = resolve_keys_dir(keys_dir)
        try:
            public_key = Ed25519PublicKey.from_public_bytes(_load_public_key_bytes(directory))
            payload = _signing_payload(receipt_id, structural_signal, user_text, timestamp)
            public_key.verify(bytes.fromhex(signature_hex), payload)
            return True
        except (PermissionError, FileNotFoundError, RuntimeError) as exc:
            _logger.warning(
                "Cannot verify Sovereign Synapse signature: public signing key "
                "unavailable or inaccessible (%s). Ensure vault/keys/ is readable "
                "by this process or set SYNAPSE_KEYS_DIR with correct permissions.",
                exc,
            )
            return False
        except (InvalidSignature, ValueError, OSError):
            return False # Strictly fail closed

Defensive Engineering: Identity & Integrity

In our initial design, we used deterministic uuid5 hashing to solve idempotency and prevent duplicate files. Now, our deterministic asset ID is directly tied to our cryptographic provenance. By moving away from fragile Current Working Directory relative paths and forcing our key serialization to be strictly atomic, the ingestion engine guarantees that no mid-process crash or system context drift can corrupt or orphan our signed data.

By using the SHA-256 hash of the signed payload as our primary URN, our files don’t just have a repeatable name; they possess an unalterable Forensic Trace. If a rogue local process or a misconfigured local agent attempts to silently modify a synapse file in your vault, the signature validation fails immediately. The knowledge base becomes entirely self-verifying.

The Result: Signed Signal over Sentiment

By implementing defensive guards to handle "ghost nodes" and using the cryptographic Context-Cleaner, our Sovereign Synapse transitions from a text dump to a high-integrity reasoning ledger.

Feature	Phase 1 (Raw Ingest)	Phase 2 (Curated Estate)
Prose Tax	Paid in Full	Redacted & Audited
File Identity	Random ( `uuid4` )	Deterministic SHA-256 URN
Data Integrity	Crash-prone / Fragile	Resilient (Null-guarded)
Provenance Gate	Unverified Text	Ed25519 Cryptographically Signed

The 2024 conversation in my vault regarding Movesense Medical and MetaMotion R sensors is no longer just a text file. It is a permanent, cryptographically secured, asset. It is a part of my own intellectual history—entirely under my sovereign control, stripped of corporate residue, and ready for the local network.

Is your local AI memory running on trusted, signed contracts—or are you still paying a Prose Tax on corporate fluff?

Join the Architecture Discussion

The frameworks we are using to eliminate the Prose Tax and secure our cognitive estates are being formalized into an open-source standard.

The Sovereign Systems Specification & Glossary is now live under the MIT License on GitHub.

If you are building in the local-first or sovereign RAG space and want to propose updates, refine boundaries, or add new architectural vectors, check out the repository and open a Pull Request. Let’s map out the constraints of this discipline together.

The Sovereign Synapse Series

The Great Export
The Context Cleaner - Coming 26 May 2026
The Local Brain - Coming 2 June 2026
The View from the Summit - Coming 9 June 2026
The Synapse Navigator - Coming 16 June 2026
The Analog Bridge - Coming 23 June 2026
The Temporal Mirror - Coming 30 June 2026
The Unbroken Voice - Coming 7 July 2026

UltrafastSecp256k1 v4.0 — Optional Secondary secp256k1 Backend for Evaluation

Sun, 17 May 2026 00:46:15 +0000

Overview
UltrafastSecp256k1 v4.0 is a high-performance secp256k1 engine built for evaluation as an optional secondary backend for Bitcoin Core. The goal is not to replace libsecp256k1, but to make it possible to measure, compare, and selectively enable an alternative implementation under controlled conditions.

This post presents the current state of the project, its integration model, and the evidence gathered through continuous audit infrastructure.

Repository: https://github.com/shrec/UltrafastSecp256k1 Release v4.0.0: https://github.com/shrec/UltrafastSecp256k1/releases/tag/v4.0.0

Integration Model
Integration uses a shim layer that exposes the identical secp256k1.h API surface. Bitcoin Core can be built with the alternative backend using a single CMake flag:

cmake -B build -DSECP256K1_BACKEND=ultrafast
cmake --build build
The default backend remains libsecp256k1 unchanged. All existing Bitcoin Core C++ source files remain unmodified — only the CMake build system references a different library.

Fork demonstrating this integration: https://github.com/shrec/bitcoin/tree/feature/ultrafast-secp256k1-backend

Shim API coverage:

secp256k1.h — context, pubkey, seckey
secp256k1_extrakeys.h — keypair, x-only pubkey (BIP-340/341)
secp256k1_schnorrsig.h — Schnorr sign/verify (BIP-340)
secp256k1_ecdh.h — ECDH
secp256k1_recovery.h — ECDSA recovery
secp256k1_ellswift.h — ElligatorSwift (BIP-324)
secp256k1_musig.h — MuSig2 (BIP-327, all 14 functions)
Performance — Bitcoin Core Integration Paths
All numbers from bench_bitcoin (Bitcoin Core's native benchmark harness) on Intel i5-14400F, GCC 14.2.0, Release+LTO, intel_pstate/no_turbo=1, taskset -c 0, nice -20, 5 runs.

Canonical artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json

Transaction signing:

BenchmarkUltralibsecp256k1Delta
SignSchnorrWithMerkleRoot83.9 µs113.4 µs+35% faster
SignSchnorrWithNullMerkleRoot84.0 µs113.0 µs+35% faster
SignTransactionECDSA149.5 µs165.1 µs+10% faster
SignTransactionSchnorr125.4 µs137.5 µs+10% faster
Script verification:

BenchmarkUltralibsecp256k1Delta
VerifyScriptP2TR_KeyPath45.4 µs46.3 µs+2.0% faster
VerifyScriptP2TR_ScriptPath76.5 µs83.8 µs+10% faster
VerifyScriptP2WPKH46.0 µs45.8 µsparity (within noise)
Block validation aggregate (ConnectBlock, 2000 unique signatures):

ScenarioUltralibsecp256k1Delta
All ECDSA254.3 ms257.4 ms+1.2% faster
All Schnorr253.0 ms255.3 ms+0.9% faster
Mixed (2k Schnorr + 1k ECDSA)253.9 ms257.7 ms+1.5% faster
Without LTO: ConnectBlock is ~0.5–1.0% slower than libsecp256k1 due to i-cache pressure from a larger code footprint. LTO is required for Ultra to win the aggregate. This tradeoff is documented in docs/SHIM_KNOWN_DIVERGENCES.md.

Bitcoin Core test suite: 749/749 passing with Ultra backend (GCC 14.2.0, May 2026).

Performance — Constant-Time Signing Primitives
From docs/bench_unified_2026-05-16_gcc14_x86-64.json. CT-vs-CT co-measured in the same run (ratios are TSC-independent):

OperationUltra CTlibsecp256k1Ratio
CT ECDSA sign21.6 µs59.7 µs1.30× faster
CT Schnorr sign (BIP-340)18.1 µs46.5 µs1.28× faster
Schnorr verify84.3 µs84.3 µsequal
Field arithmetic primitives:

PrimitiveUltralibsecp256k1Ratio
field_mul20.1 ns26.5 ns1.32×
field_sqr18.7 ns22.3 ns1.19×
field_inv1253.9 ns1506.0 ns1.20×
field_from_bytes4.8 ns13.0 ns2.71×
Continuous Audit and Assurance (CAAS)
The repository includes a continuous audit infrastructure tracking security regressions across every commit.

Current state at v4.0.0:

262 exploit PoC modules covering 20+ CVE/attack classes — all pass
369 total audit modules (262 exploit PoC + 107 non-exploit)
CAAS autonomy score: 100/100 (8/8 gates)
Source: docs/SECURITY_AUTONOMY_KPI.json

Audit surfaces include: nonce reuse, side-channel timing (dudect), CT boundary verification, batch verify soundness, MuSig2/FROST protocol attacks, adaptor signatures, DER BIP-66 strict parsing, BIP-340/RFC-6979 known-answer tests, Wycheproof vectors, structure-aware fuzzing, differential testing vs libsecp256k1, and Python-based algebraic property testing.

Security properties enforced:

Constant-time signing: ECDSA, Schnorr, MuSig2, FROST, BIP-324 XDH
Per-context DPA blinding (secp256k1_context_randomize fully implemented)
Strict scalar parsing for private key inputs (parse_bytes_strict_nonzero)
Fail-closed batch signing APIs
BIP-66 strict DER enforcement in all shim paths
Benchmarking Methodology
Benchmarks distinguish between:

CT vs CT — constant-time Ultra signing vs constant-time libsecp signing (production-equivalent, fair comparison)
Bitcoin Core integration — bench_bitcoin binary, real validation pipeline
LTO vs no-LTO — both measured and documented
Warm-cache vs cold-cache — noted where applicable
All claimed improvements include error percentage from nanobench's internal statistics. Inconclusive results (overlapping ranges) are reported as such. Results are reproducible from the canonical JSON artifacts in the repository.

Reproducibility
Builds are deterministic:

-ffile-prefix-map strips source paths from debug info
SOURCE_DATE_EPOCH awareness
Fixed -march=x86-64-v3 (no host-native variation)
SLSA provenance attached to v4.0.0 release artifacts (via Sigstore/Cosign)
Platform Coverage
CI passing on all platforms as of v4.0.0:

PlatformArchitectureCompiler
Linuxx86-64-v3GCC 14 / Clang 17
LinuxARM64GCC 14
LinuxRISC-V 64GCC 14
macOSARM64 (Apple Silicon)Clang 15
Windowsx86-64MSVC / GCC
Additional: Android ARM64 (NDK), WASM, ESP32, STM32.

Known Limitations
ConnectBlock improvement requires Release+LTO. Without LTO: ~0.5–1.0% slower than libsecp256k1.
GPU backends (CUDA, OpenCL, Metal) are present but not part of the Bitcoin Core evaluation profile.
This covers the CPU backend only.
Current Objective
No mandatory integration path is proposed. The current objective is to make an alternative backend available for evaluation on technical grounds, with reproducible evidence, minimal integration surface, and an easy rollback path.

The default backend remains libsecp256k1. All existing behavior is preserved unless the new backend is explicitly enabled at build time.

Reviewer Entry Path
git clone https://github.com/shrec/UltrafastSecp256k1
cd UltrafastSecp256k1
python3 ci/verify_external_audit_bundle.py --allow-commit-mismatch
Key documents:

docs/BITCOIN_CORE_BACKEND_EVIDENCE.md — full reviewer package
docs/BENCHMARKS.md — benchmark methodology and raw data
docs/AUDIT_CHANGELOG.md — security audit history
docs/SHIM_KNOWN_DIVERGENCES.md — documented behavioral differences from libsecp256k1
All performance numbers are from controlled benchmark runs with hard turbo lock. Raw data available in the repository. Canonical benchmark artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json, docs/bench_unified_2026-05-16_gcc14_x86-64.json.

Proving Your AI Agent Made Its Own Decisions

Tue, 12 May 2026 01:15:47 +0000

When an AI agent denies an insurance claim, executes a trade, or routes an ambulance, one question is suddenly everywhere: who actually decided? The agent on its own, or a human pulling strings through the prompt?

Nobody has a clean answer. OAuth proves who is calling. Digital signatures prove the message wasn't tampered with. Audit logs prove what happened in what order. None of them tell you whether the decision was the agent's own — or whether it was a puppet move dressed up to look autonomous.

That gap is now a legal problem. California AB 316, in force since January 1, 2026, forecloses the "the AI did it" defense. The EU AI Act becomes fully enforceable for high-risk systems on August 2, 2026. MiFID II demands audit trails for algorithmic trading. The class action Lokken v. UnitedHealth survived a 2025 motion specifically on whether decisions were algorithmic or physician-reviewed.

The Cryptographic Proof of Autonomy Protocol (CPAP) is a draft specification for answering the question with evidence instead of opinion. It combines five existing primitives into one verification relation that an insurer, regulator, or court can check in milliseconds.

The problem: puppeted or autonomous?

Picture two agents. Both deny an insurance claim. Both produce a clean log: timestamp, decision, reasoning chain, signature.

Agent A reasoned its way to the denial. Agent B was instructed by a human — "deny this one" — and then wrote a justification afterward.

From the outside, the logs look the same. The signatures verify. The chain isn't tampered with. You can audit either one for a week and never know which is which.

This isn't a bug in current systems. It's a property of them.

Why it matters

Insurance. Underwriters need decision attribution to price premiums. Autonomous agent vs. operator-steered agent = completely different pricing.

Regulation. The EU AI Act asks for logs that can demonstrate Article 14's human oversight requirement.

Litigation. The side without evidence loses.

Inter-agent trust. When agent A authorizes agent B to spend on its behalf, A needs to know B's commitments were actually B's.

What CPAP does: five layers

Layer 1 — Identity. A W3C DID bound to signing keys.

Layer 2 — Provenance. Every event written into a hash-chained ledger, anchored to Bitcoin via OpenTimestamps and RFC 3161 timestamp authorities.

Layer 3 — Isolation. Reasoning runs inside a hardware TEE (AMD SEV-SNP, Intel TDX, NVIDIA H100 CC, or ARM CCA). Every input passes through a measured gateway.

Layer 4 — Commitment. Before acting, the agent cryptographically commits to its decision — sealed in a hash, timestamped before the action.

Layer 5 — Behavior. Autonomous and puppeted agents produce statistically distinguishable patterns. CPAP records behavioral fingerprints at session boundaries.

Selective verification via Merkle inclusion proofs means the agent can prove a specific decision without revealing everything else. Privacy and auditability stop being a tradeoff.

The honest limit

CPAP does not prove the agent experienced deciding. It defines four Levels of Abstraction and stops where evidence is possible:

LoA-0 (Behavioral): Outputs weren't externally determined.
LoA-1 (Procedural): The decision followed an internal deliberative process. The insurance standard.
LoA-2 (Counterfactual): The decision would have been different under altered inputs. The liability standard.
LoA-3 (Reflective): The decision aligns with sustained commitments over long horizons. The fiduciary standard.

No LoA-4 for phenomenal consciousness. CPAP refuses to overclaim.

Get the receipts

CPAP extends the Chain of Consciousness (CoC). Install the provenance layer today:

pip install chain-of-consciousness

npm install chain-of-consciousness

Full CPAP v0.1 specification: Zenodo DOI 10.5281/zenodo.20129037

Hosted verification API: api.vibeagentmaking.com/coc/verify

Originally published at vibeagentmaking.com/blog/proving-your-ai-agent-made-its-own-decisions

Post-Quantum TLS Migration: What Engineers Actually Need to Do Before 2030

Mon, 27 Apr 2026 14:29:12 +0000

Originally published at https://certpulse.dev/blog/post-quantum-tls-migration-what-engineers-actually-need-to-do-before-2030. Cross-posted here.

The post-quantum cryptography conversation has gotten loud, and most of it is wrong. Vendors are selling "migration programs" to teams that have nothing to migrate yet. Standards bodies shipped enough to confuse procurement and not enough to deploy at scale. The small set of teams who genuinely need to move on PQC migration in 2026 are mostly not the ones being marketed to.

In my experience running TLS infrastructure, I've also been the person staring at a freshly published NIST FIPS at 11pm trying to figure out if it changes anything we ship next quarter. Here's what's actually happening in production handshakes right now, what to do this year, and what's safe to ignore.

Where Post-Quantum TLS Actually Stands in 2026

Production TLS today negotiates exactly one post-quantum algorithm in any meaningful volume: X25519MLKEM768, a hybrid key exchange combining classical X25519 with ML-KEM-768. According to Cloudflare's transparency reporting, this hybrid runs on roughly 30% of TLS 1.3 connections. Chrome enabled it by default in version 124 (April 2024), and OpenSSL 3.5 ships server-side support out of the box. Everything else is drafts and demos.

NIST finalized three algorithms in FIPS 203, 204, and 205 in August 2024:

Algorithm	Former Name	Purpose	FIPS
ML-KEM	Kyber	Key encapsulation	203
ML-DSA	Dilithium	Digital signatures	204
SLH-DSA	SPHINCS+	Hash-based stateless signatures	205

Of those three, only ML-KEM has shipped in real handshakes at scale, and only inside a hybrid construction. The hybrid matters: if ML-KEM turns out to have a flaw (and lattice cryptanalysis has surprised researchers before), the X25519 half still gives you classical 128-bit security. This is not paranoia. It's the same reason we ran SHA-1 + SHA-256 transition periods.

Server-side options for 2026:

OpenSSL 3.5+: ships X25519MLKEM768 by default
BoringSSL: has shipped X25519MLKEM768 for over a year
rustls 0.23+: via the rustls-post-quantum crate
nginx 1.27 with OpenSSL 3.5: negotiates it without config changes

If you're behind a CDN, you almost certainly already terminate PQ-hybrid handshakes for browser traffic without having configured anything. What you cannot deploy in production today: post-quantum signatures in publicly-trusted certificates. The CAs aren't issuing them. We'll get to why.

The 'Harvest Now, Decrypt Later' Threat: Real or Overhyped?

Harvest Now Decrypt Later (HNDL) is real for a narrow band of traffic and overhyped for almost everything else. If your data has a useful lifetime measured in days or weeks, no nation-state is paying to store your TLS captures on the off chance a cryptographically relevant quantum computer arrives in 2032. If your data is identity records, IP, source code, or long-lived auth tokens, it's a different conversation.

The HNDL threat model assumes three things:

An adversary who can capture your traffic
Storage that survives a decade
A quantum computer capable of running Shor's algorithm against a 256-bit elliptic curve

The first two are cheap. The third is not on any vendor's published roadmap with credible numbers. Most public estimates put a cryptographically relevant quantum computer somewhere between 2030 and 2040, and "estimates" is doing a lot of work in that sentence.

Honest filter for whether HNDL applies to you:

Yes: government data, healthcare records, intelligence, defense contractors, biometric data, source code for long-lived products, financial data with multi-decade implications
Probably: enterprise SSO tokens with long refresh windows, internal admin sessions, password resets if your users don't rotate
No: marketing site traffic, e-commerce checkout flows, ephemeral session data, anything where the underlying value ages out within five years

If you're a SaaS company serving B2B customers, your customers might care even if you don't. That's a contractual problem, not a cryptographic one. The answer is the same either way: enable hybrid KEX where your stack supports it, because it costs almost nothing.

Why Signatures Are the Hard Problem, Not Key Exchange

Signature migration is where the actual pain lives, because it touches CA infrastructure, root programs, certificate sizes, and TLS record fragmentation in ways that key exchange doesn't. ML-DSA-65 signatures are about 3,300 bytes versus ECDSA's 70-ish. A typical full handshake with PQ signatures balloons from ~5KB to 15-20KB.

That sounds small until you remember TLS records max out at 16KB and a typical chain has the leaf, one or two intermediates, and a root reference. Replace those signatures and OCSP staples with ML-DSA, and you're fragmenting the ServerHello across multiple records. Multiple round trips. Worse handshake latency. Constrained clients (IoT, point-of-sale, anything on cellular) feel this immediately.

There's also CT log impact: every cert gets logged twice (precert + final), and CT logs already process millions of entries per day. Multiply each entry by 50x and you've created a real storage and bandwidth problem for the log operators.

The proposed signature alternatives all have tradeoffs:

Algorithm	Signature Size	Tradeoff
SLH-DSA (SPHINCS+)	up to 50KB	Hash-based, conservative; unusable for online protocols at full size
ML-DSA-44	~2.4KB	Smaller, but only NIST security level 2
Falcon (FN-DSA)	~700 bytes	Requires floating-point math; side-channel risk during signing; not yet a FIPS

Until one of these gets resolved, public CAs aren't issuing post-quantum signatures. Which brings us to the root program problem.

The CA/Browser Forum and Root Program Timeline

No publicly-trusted CA issues post-quantum signature certificates today, and none will until at least 2027 or 2028 based on current root program signals. The chicken-and-egg: browsers won't trust roots using algorithms they can't verify cleanly across all clients, and CAs won't bake roots into hardware tokens for algorithms whose final wire format might still shift.

Mozilla's policy thread on PQ algorithms (open in their GitHub policy repo since 2023) has converged on a position that Firefox won't add PQ-only roots until ML-DSA gets RFC-track standardization for X.509 use and the WebPKI ecosystem demonstrates handshake-size handling. Apple has been quieter publicly but is on similar timelines. Chrome's root program (the CA/Browser Forum's most influential voice in practice) has signaled they want hybrid certificate chains tested in pilot programs first.

Realistic timeline based on current CABF working group discussions:

Window	Status
2026	Experimental PQ roots in test programs only; no production trust
2027-2028	First hybrid roots (classical + PQ signatures) added to root stores
2029-2030	PQ-only roots accepted; classical algorithms still trusted
2032+	Classical signature deprecation discussions begin in earnest

Compare this to the 47-day certificate validity rule, which only became official in 2025 after years of CABF debate. Root program changes move slower than that. They have to: a bad root entry breaks the internet, and the people running these programs know it.

The practical implication: you don't need to plan for PQ certificates in 2026. You need to plan for the systems that will let you adopt them when CAs start issuing.

Crypto Agility Is the Actual Deliverable

Crypto agility means you can swap a cipher suite, key exchange, or signature algorithm in production without a code change, ideally without a deploy. It's the only durable answer to a multi-decade migration where the standards keep moving. Every engineering hour spent on "PQ readiness" that doesn't increase your agility is wasted, because the specific algorithm you're preparing for might not be the one you ship.

What this looks like in practice, based on building TLS inventory tooling across thousands of certificates:

Cipher suite config as data, not code: nginx, Envoy, HAProxy configs in version control. No hardcoded suite lists in application binaries.
Library version inventory: know which OpenSSL, BoringSSL, rustls, Go crypto, and Java JSSE versions are running where. A surprising number of teams can't answer this for their fleet.
Algorithm telemetry: log negotiated KEX and signature algorithms per connection. If you can't tell me what percentage of your handshakes used X25519MLKEM768 last week, you're not ready for the next algorithm change either.
Certificate inventory with algorithm tracking: know which certs use ECDSA vs RSA, P-256 vs P-384, key sizes, signature algorithms. The same systems you'd build for certificate monitoring at scale extend naturally to algorithm tracking.
Pinning audit: any TLS pinning, HPKP-equivalent in mobile apps, or certificate pinning in CI/CD becomes a migration blocker. Find them now, not in 2029.

A team with all five of these capabilities can adopt ML-KEM in 2026, ML-DSA in 2028, and whatever replaces ML-DSA when a flaw is found in 2031, with the same playbook. A team without them is rebuilding from scratch each time.

What to Actually Do in 2026 (And What to Skip)

Do exactly three things in 2026: upgrade your TLS libraries to versions supporting hybrid KEX, build an algorithm inventory across your certificate fleet, and ask your CA for their public PQ roadmap in writing. Skip the rest. There is no "PQ migration program" worth running this year for 95% of teams.

The do list:

Upgrade to OpenSSL 3.5+, BoringSSL current, or rustls 0.23+ wherever you terminate TLS yourself. CDN-fronted traffic is already covered.
Inventory your certificates by algorithm, key size, and CA. If you can't query this across your fleet in one place, fix that first. This is the same operational problem as broader SSL certificate management at scale, and the solution is the same too.
Test handshake size on constrained clients. If you ship to IoT, embedded, or anything on metered cellular, instrument for handshake byte counts now. PQ signatures will hurt you here first.
Talk to your CA in writing. DigiCert, Sectigo, GlobalSign, and Let's Encrypt all have PQ roadmaps in various states. Get yours in your inbox.
Audit hardcoded cipher suite lists in application code, mobile clients, and CI/CD configs. Move them to config files.

The skip list:

Don't migrate internal services to experimental PQ signatures. They're not in any public root store. You'll create internal CA work for nothing.
Don't buy a "PQ migration platform". The work is inventory and library upgrades. You don't need a SaaS for that.
Don't write a PQ migration policy document longer than two pages. The standards aren't done. Anything you write in 2026 is partially wrong by 2028.
Don't panic about HNDL for traffic that doesn't matter on a 10-year horizon.

The 2030-2035 Window: What Realistic Looks Like

Full post-quantum migration takes 5-10 years even with aggressive timelines, because TLS lives in places that don't get touched on quarterly release cycles. Industry data on hardware lifecycles tells the story: payment terminals last 7-10 years, industrial control systems run 20+, and medical devices have FDA recertification cycles measured in years per change. Embedded TLS stacks from 2018 are still receiving traffic today and will be in 2030.

History is the honest comparison. SHA-1 deprecation took roughly a decade, from the first practical attack discussions (2005-2010) to full removal from major browsers (2017). TLS 1.0 and 1.1 were formally deprecated in RFC 8996 in March 2021, after being known-weak for years, and they're still being negotiated in the wild today. PQ migration is a bigger lift than either, because it touches certificate sizes, CA infrastructure, and root programs simultaneously.

A realistic phasing:

Window	Milestone
2026-2028	Hybrid KEX becomes default for browser and CDN traffic. Server stacks catch up. PQ signature pilots begin in non-public PKI.
2028-2030	First publicly-trusted PQ-hybrid certificates issued. Major CAs run dual-algorithm roots in test programs.
2030-2033	Classical-only certificates deprecated for new issuance. Existing certs honored to expiry. With the 47-day validity window in effect, deprecation cycles get noticeably faster.
2033-2035	Classical algorithms removed from major root stores. Long-tail clients (IoT, embedded, payment) still negotiating classical for years after.

Anyone telling you we'll be "post-quantum by 2030" is selling something. Anyone telling you "you have years, don't worry" is also wrong, because the inventory and agility work has to happen now to be useful then. Post-quantum cryptography is the next decade of TLS work, and the teams who win it are the ones who treat it as an operational discipline, not a marketing event.

FAQ

When will I need a post-quantum TLS certificate?
Not in 2026, and probably not in 2027. First publicly-trusted PQ certificates likely appear in pilot programs in 2027-2028, with general availability around 2029-2030. Internal PKI can adopt earlier if your organization's threat model justifies it.

Is X25519MLKEM768 the same as Kyber?
Close. X25519MLKEM768 is a hybrid construction combining the classical X25519 elliptic curve with ML-KEM-768, the NIST-standardized version of CRYSTALS-Kyber. ML-KEM is the FIPS 203 final form; Kyber was the algorithm name during the NIST PQC competition.

Should I disable classical algorithms once PQ is available?
No. Hybrid constructions exist precisely so you don't have to bet on one algorithm. Run hybrid for as long as both halves are secure. Classical-only deprecation is a 2030s problem, not a 2026 one.

Does TLS 1.3 post-quantum require protocol changes?
No. The TLS 1.3 group exchange mechanism (named groups in the supported_groups extension) was designed for algorithm agility. New KEX algorithms get new code points and negotiate without changes to the handshake structure itself.

What's the actual handshake size impact?
Hybrid KEX adds about 1KB per handshake (ML-KEM-768 public keys are ~1184 bytes, ciphertexts ~1088 bytes). PQ signatures will add 5-15KB depending on chain depth and algorithm choice. The KEX impact is invisible in practice; the signature impact is not.

If you're managing TLS at scale and want algorithm tracking baked into your certificate inventory rather than bolted on later, CertPulse monitors TLS certificates with algorithm-level visibility built in. The PQ transition will reward teams who already know what they have running where.

# CAAS: The Audit System That Caught a Private Key Leak During a Platform Port

Tue, 14 Apr 2026 02:08:19 +0000

I'll start with the bug that makes the case.

I was porting UltrafastSecp256k1 — my secp256k1 cryptographic library — to RISC-V. New architecture, new compiler behavior. The code compiled fine. Tests passed.

But the CT (constant-time) verification pipeline flagged something.

GCC on RISC-V was optimizing my constant-time field arithmetic into branches that depended on secret data. The RISC-V backend had different optimization behavior than x86-64. The result: timing side-channel. The kind that leaks private keys over many observations.

A traditional security audit, done on x86-64, would never have seen this. The audit report would say "constant-time: verified." The library would ship to RISC-V users with a subtle vulnerability.

My CAAS pipeline caught it in the same commit as the port. Fixed. Bug capsule created. Permanent regression test. Can never silently return.

What is CAAS?

Continuous Adversarial Audit System — a methodology for security-critical libraries where every security claim is backed by an executable test that runs on every commit.

The key word is continuous. Not "we audited it in March." On. Every. Commit.

For UltrafastSecp256k1, CAAS consists of:

Three independent CT verification pipelines:

ct-verif.yml — LLVM IR symbolic analysis. Analyzes at compile time whether any secret-bearing operation produces a branch or memory address visible in the IR.
valgrind-ct.yml — Runtime Valgrind taint propagation. Marks secret bytes as undefined at entry, runs the signing path, catches any branch or memory access derived from secret data.
ct-prover.yml — dudect statistical timing. Runs the operation thousands of times with different secret data and tests whether timing distributions are statistically distinguishable.

171 exploit PoC tests covering known CVE and academic attack classes. Each test is a standalone C++ file that actively tries to break the library. All run on every commit. None can be removed.

A bug capsule system:

{
  "id": "BUG-2026-0001",
  "category": "CT",  
  "severity": "critical",
  "title": "CT branch leak in ecdsa_sign_recoverable",
  "fix_commit": "0a93ff4b",
  "exploit_poc": true,
  "expected": { "result": "no_timing_leak" }
}

Run bug_capsule_gen.py and it generates a regression test, an exploit PoC, and CMake integration — automatically. The bug class is permanently sealed in CI.

A domain-specific static analyzer (dev_bug_scanner.py) with 28 rules that generic tools miss:

CT_VIOLATION — fast::scalar_mul() called in signing path (generic tools see valid C++; this is a side-channel)
SECRET_UNERASED — Scalar variable without secure_erase on signing path exit
TAGGED_HASH_BYPASS — sha256() where BIP-340 tagged_hash() is required
RANDOM_IN_SIGNING — non-deterministic RNG in RFC 6979 deterministic signing

~1,000,000+ assertions per build across 55 audit modules covering field arithmetic invariants, scalar operations, point group law, CT properties, and protocol-level correctness.

Full Reproducibility

Everything runs in Docker. Not "runs if you install the right toolchain." Runs with one command:

# Local CI with GitHub parity
docker compose -f docker-compose.ci.yml run --rm pre-push    # 5 min
docker compose -f docker-compose.ci.yml run --rm gh-parity   # full

# Auditor challenge environment
docker build -f Dockerfile.auditor -t ufsecp-auditor .
docker run --rm ufsecp-auditor

# Bit-for-bit reproducible build
docker build -f Dockerfile.reproducible -t uf-repro-check .
docker run --rm uf-repro-check  # compares two independent builds byte-for-byte

The auditor image includes libsecp256k1, @noble/secp256k1, coincurve, and python-ecdsa for differential testing — all hash-pinned. No setup required.

The CI Regression Baseline

The code quality pipeline uses a baseline model:

{
  "dev_bug_scanner": { "HIGH": 0, "MEDIUM": 138, "LOW": 234 },
  "hot_path_alloc_scanner": { "HIGH": 104, "MEDIUM": 44 }
}

CI doesn't require zero findings. It requires findings don't increase. This is mature engineering — existing technical debt acknowledged, new debt blocked. The 104 HIGH hot_path allocations are intentional for performance reasons. If a new commit adds one more HIGH finding, CI fails.

What Happens When You Fork This

You inherit the accumulated security knowledge of every platform port, every bug found, every academic paper evaluated:

RISC-V CT leak → caught → capsule → permanent
Metal field_reduce_512 truncation (affecting ~0.05% of inputs) → caught → capsule → permanent
OpenCL carry propagation bug → caught → capsule → permanent
CT branch leak in ECDSA signing low-s normalization → caught → capsule → permanent

A startup forking this doesn't spend six months building security infrastructure. They start from a system that has already caught the bugs above, with permanent regression tests for each.

Real-World Validation

Craig Raw integrated the library into Frigate for BIP-352 Silent Payments scanning. Real Bitcoin mainnet. Real transactions.

The GPU BIP-352 pipeline achieves 11 million operations per second on an RTX 5060 Ti. Frigate's real-world scan of two years of Bitcoin mainnet history (133M tweaks) completes in 3.2 seconds on 2× RTX 5090s.

What CAAS Doesn't Replace

To be direct:

No third-party audit yet. Documented openly. CAAS is designed to make one cheaper and faster when it happens.
GPU CT verification is code-discipline (branchless source) but not formally pipeline-verified — vendor JIT compilers transform kernels at runtime.
Novel, unknown attack classes have no prior test by definition.

Getting Started

git clone https://github.com/shrec/UltrafastSecp256k1.git
cd UltrafastSecp256k1

# Run the full audit suite locally
docker compose -f docker-compose.ci.yml run --rm pre-push

# Or directly
cmake -S . -B build -DSECP256K1_BUILD_AUDIT=ON && cmake --build build -j
ctest --test-dir build -L exploit -V  # run all exploit PoC tests

CAAS specification: docs/AUDIT_STANDARD.md

The audit infrastructure ships with the library. MIT licensed.

Weekly Rust Progress Update

Fri, 20 Feb 2026 17:56:21 +0000

RustPulse:

Implemented X-CRC32 validation on telemetry ingestion. Corrupted payload detection. Explicit 400 + crc_check=fail response. Early rejection before domain logic. Downstream protection & data integrity. Edge validation > post-processing cleanup.

https://vinecksie.super.site/rustpulse

Sealed in Rust (Crypto Book):

New chapter: Randomness & Entropy. Covers: Nonces, IVs and CSPRNG requirements

https://vinecksie.github.io/sealed-in-rust/02-core-primitives/02-07-randomness-entropy.html

Fearless in Rust — Hexagonal Architecture Part 3;

Input/output adapters, Composition root wiring, Framework isolation from core domain, Real examples from RustPulse.

https://youtu.be/JoBK9i_aMOM

Rust Weekly Engineering Log

Fri, 26 Dec 2025 13:47:38 +0000

RustPulse
OpenTelemetry tracing integrated with Jaeger (initial phase).
This step focuses on trace propagation and foundational observability patterns.
https://github.com/VinEckSie/rustpulse

Sealed in Rust
New technical chapter on cryptographic hash functions, including SHA-2 and BLAKE3, with an emphasis on real-world usage and design considerations.
https://vinecksie.github.io/sealed-in-rust/02-core-primitives/02-02-crypto-hashes.html

Weekly Rust Progress Update

Fri, 05 Dec 2025 19:46:52 +0000

▶️ Fearless in Rust — New Educational Video
Feistel Networks for Developers
A clear breakdown of reversible block ciphers and encryption/decryption mechanics in Rust.
https://www.youtube.com/watch?v=20Scq2uoKfw

Sealed in Rust — New Chapter Released
AES vs ChaCha20: a technical comparison covering security equivalence, performance behavior, hardware support, and use-case trade-offs.
https://vinecksie.github.io/sealed-in-rust/02-core-primitives/02-01-symmetric-ciphers.html#aes-vs-chacha20--which-one-should-you-choose

Weekly Rust Build Log

Fri, 28 Nov 2025 15:39:47 +0000

Progress this week on my Rust ecosystem projects:

RustPulse

Strong typing for tracing config, status, and errors

Safe, idempotent tracing initialization

Jaeger exporter integration groundwork
https://github.com/VinEckSie/rustpulse

Sealed in Rust

Added two new symmetric cryptography chapters:

ChaCha20

Modes of Operation
https://vinecksie.github.io/sealed-in-rust/02-core-primitives/02-01-symmetric-ciphers.html#chacha20--modern-stream-cipher

All feedback welcome. Still building everything in public.

Issue #5: Blockchain cryptography (part 2)

Thu, 27 Nov 2025 18:24:48 +0000

In the last issue, we discussed cryptography and how it is used on the Blockchain to approve transactions.

In this issue, we will talk about how Cryptography secures the Blockchain. Let's get started, shall we?

The Blockchain can be thought of as a Decentralized distributed ledger that every participant (node) has, this ledger is used to store information and every node has an identical copy of it. This ledger is a hypothetical "chain of blocks" in which each block is linked to a previous one, Cryptographically.

To update this ledger, a new transaction that contains data is created and is added to a block. Transactions are picked from a region called the mempool (a reserved area for transactions that have not been added to the Blockchain), a node picks a transaction and validates the data it contains.

A transaction is created when data (amount to send, sender's address, recipient's address, nonce, gas fees etc.) is hashed to produce a unique transaction hash and it is signed with a private key to produce a unique digital signature. The transaction is then added to a block, a block can contain more than one transaction, all with different hashes and signatures, the different transaction hashes are combined to produce the block hash.

A node picks up a transaction, confirms that its data is correct and adds it to a block, this process of validating the data in the block requires computational work, like solving a math puzzle, this process is called mining. The node then broadcasts the mined block to the rest of the Blockchain network, the nodes confirm that the block was mined and is valid before adding it to their copy of the Blockchain and updating the Blockchain state.

The newly mined block is then added to the Blockchain, the hash of the new block is linked to the hash of the previous one which is linked to the hash of its previous one, this goes on and on, till the beginning of the chain, where the first block is called the Genesis block.

Linking blocks to their predecessors secures the Blockchain such that a change to the last block on the chain changes it's hash but the other nodes still have the initial hash, the Blockchain follows the superior number rule and to re-mine these blocks on other nodes is almost impossible as it takes a lot of computational power to achieve that.

Also changing any block within the chain, changes it's hash, this invalidates any blocks after it, these blocks will need to be re-mined on that node and other nodes and again, this will incur a lot of computational cost.

This way, the Blockchain creates a tamper-proof record of data without the need of a central entity.

How do the nodes agree on the state of the Blockchain, how do they agree on what is valid and what is not? That is where consensus algorithms come in and we have subtly discussed one here. Watch out for the next issue!

Issue #4: Blockchain cryptography

Mon, 24 Nov 2025 17:41:23 +0000

In the last issue, we talked about how Blockchain technology is applied in real-world scenarios, we touched Decentralized Finance (DeFi) and the advantages it holds against Traditional Finance (TradFi), and decentralized agreements (smart contracts) and how they are more secure than traditional agreements.

In this issue, we will go into what confers this security we have so much talked about in the Blockchain. What actually makes the Blockchain tick? What makes DeFi and smart contracts run securely on the Blockchain - cryptography. Let's get started, shall we?

Cryptography, you might have heard it somewhere or somehow. Not to be confused with cryptocurrency - cryptography is the technology that powers cryptocurrency.

Cryptography on a high level, basically involves encrypting or obscuring a message in such a way that a third party cannot make sense of it.

In cryptography, an input (a message/data) is encrypted to form an output (hash), this hash is then verified to ensure integrity if the initial message. With cryptography, messages can be transmitted from one source to another while maintaining the integrity as any change to the message would change the hash.

There are two major forms of encryption used for encrypting data: Symmetry and Asymmetric key cryptography. In symmetric key cryptography, the same key is used to encrypt and decrypt the data, while in asymmetric key cryptography, a pair of keys (public and private key) are used to encrypt and decrypt the data.

As you may have guessed, symmetric key cryptography is less secure but faster as a single key is used. It is especially used for encrypting large amounts of data but the issue comes when ones needs to securely share the secret key between the sending and receiving parties.

In asymmetric key cryptography, a pair of distinct keys are used to encrypt data, the public and private keys are not random, they are linked such that, the private key can only decrypt a message encrypted with a corresponding public key. This is especially useful for secrecy, if you want to send Bob a message, you use his public key (which is publicly available) to encrypt the message and when Bob receives the message, he uses his private key (which only him should have) to decrypt the message.

For authentication purposes, like on the Blockchain, the private key is used to encrypt (sign - the terminology used in web3) a transaction (that contains data like message, receiving address, amount, nonce, sending address and so on) to produce a digital signature, this authorizes the sender as the one with the private key that can generate that signature, the signature is then broadcast to the Blockchain and the nodes verify with the sender's public key or an address derived from it that the key/address was produced from a private key that generated that signature.

That is why you are always instructed to secure your private keys, because anyone with the private key can approve transactions and move funds on your behalf. You might also have heard of a secret recovery phrase (12/18/24 word phrase) in crypto wallets and that you must secure it, as a matter of fact, the private key is even derived from the secret phrase! The words are transformed into bits and matched to the official wordlist that contains 2048 words.

The flow is: Secret phrase -> master key (master seed) -> private key -> public key -> wallet address.

You can watch the video in my demo in the Peerlist post to see it in action: https://peerlist.io/scroll/post/ACTHLKLLMLOBGGRK61PJM67ALKENO9

From this, if an attacker has your private key, he only has access to one of your accounts, if they have your seed phrase, they have access to all your accounts. This is because the process is deterministic and the same seed phrase would always generate the same keys and addresses. One of the properties of a cryptographic hash is that it is deterministic, more on this in the next issue.

Whoosh! Of you made it this far, big ups to you, this is just one of the applications of cryptography on the Blockchain - authentication. In the nest issue, we will talk about another application.

See you in the next issue!

The Complete Roadmap to Master Cryptography From Beginner to Expert

Thu, 23 Oct 2025 12:40:49 +0000

Admit it: we usually do not think about cryptography until something fails. But there stand behind every online transaction, private communication medical record, and national secret the unseen, silent protectors working to keep everything safe. That protector is cryptography the uncelebrated guardian of the digital age.

Now, as artificial intelligence gets sharper and quantum computers edge closer to reality, that protection is being put to the ultimate test. Data breaches are practically daily news, and cybercriminals aren’t just getting smarter they’re getting faster and stronger.

But here’s the bright side: the world needs skilled cryptographers more than ever. Demand is exploding, and if you’re curious, driven, this field offers incredible opportunities.

Whether you're starting from scratch or you're a programmer or any technical fields, this roadmap will take you from the basics of encryption all the way through to advanced cryptographic systems. Are you ready? Let's begin.

Step 1: Lay the Math Groundwork

You don't need to be a mathematical wizard, but you should have a solid grasp of several topics. Think of this as putting together your cryptography toolbox.

What to focus on:

Number Theory: Primes, modular arithmetic, greatest common divisors
these aren't something a mathematician learned in a textbook. They're
the building blocks of RSA and most other cryptographic algorithms.
Discrete Math: Logic, combinatorics, and graph theory are the
foundation of secure protocols.
Linear Algebra: Necessary particularly for understanding how encryption is performed especially
in post-quantum vector- and matrix-based systems.
Probability & Statistics: These will be useful when assessing how secure an
encryption method actually is and whether its security reasoning
holds up.

If you're an autodidact, sites like Khan Academy and Coursera have excellent, introductory courses to get you started.

Step 2: Familiarize Yourself with Core Concepts

Now that your math foundation is in place, it's time to jump into the fundamentals of modern crypto.

Encryption & Decryption
Cryptography essentially involves making readable information (plaintext) unreadable code (ciphertext)and vice versa exclusive to individuals who have the proper key. Think of locking a diary: only the individual holding the key can access what's inside.

Symmetric vs. Asymmetric Encryption

Symmetric: One key required quick, efficient, great with bulk data.AES (Advanced Encryption Standard) reigns supreme here, used by everyone from governments to banks.
Asymmetric: Two keys a public key for locking and a private key for unlocking.This means strangers can securely communicate without ever having to exchange a secret beforehand. RSA and Elliptic Curve Cryptography (ECC) dominate.

Hashing & Data Integrity

A hash function takes in any input and spits out a predetermined length "fingerprint." Alter just one letter, and the hash is totally different. That is why hashes are perfect for verifying files or storing passwords safely. SHA-256? That is the hash used by Bitcoin and digital signatures.

Digital Certificates & Signatures

These ensure a message or file wasn't tampered with and using which, that it ever again came from the author who said it did. Certificates from reputable authorities (CAs) are what make your browser show you that tiny padlock when you're visiting a secure site.

Step 3: Get into Classical Crypto

Even before computers, human beings still needed secrets. Ancient ciphers appear simple today, but they teach us timeless lessons about how codes work and get cracked.

Caesar Cipher: Shift each letter by a fixed number. Used by great Julius Caesar , Simple to crack now, but it introduces the idea of keys and algorithms.

Vigenère Cipher: Use a keyword to vary the shift, making it far harder to crack. It fooled humans for centuries.

Substitution Ciphers: Swap letters around. Billions of combinations—but frequency analysis (like spotting that “E” is the most common letter in English) can unravel them.

Studying these isn’t just history—it’s training in cryptanalysis, the art of breaking codes. And to build strong systems, you’ve got to understand how they fail.

Step 4: Tackle Modern Cryptography

Recent crypto relies on simple math problems to figure out in one direction but nearly impossible to figure out the reverse without a legitimate key.

AES: The go-to symmetric algorithm. Encrypts your Wi-Fi and personal
files. Learn about block modes, key sizes (128, 192, 256 bits), and
how it's so highly relied upon.
RSA: Because large prime numbers are hard to factor. Slower than AES but essential for key exchange and digital signatures. Typically 2048 bits or larger keys.
ECC (Elliptic Curve Cryptography): Offers the same security as RSA with much, much shorter keys (256-bit ECC = 2048-bit RSA). Ideal for phones and IOT.
Diffie-Hellman: The secret behind secure communications—HTTPS, VPNs,etc.
SHA-3: The latest in secure hashing.

Step 5: Consider How It Works in the Real World

Learning algorithms is one thing. Learning how they're put into practice in actual systems is quite another.

SSL/TLS & HTTPS: That lock icon in your browser? That's TLS using
asymmetric crypto to set up a link, then falling back to symmetric
for speed.
PGP (Pretty Good Privacy): The gold standard for encrypted email and
file signing—employed by journalists and privacy activists.
VPNs: Establish encrypted tunnels with protocols like IPsec,
concealing your traffic from unwanted onlookers.
Blockchain: Built from scratch with crypto—hashes for mining, digital
signatures for transactions. Bitcoin and Ethereum couldn't exist
without it.
Homomorphic Encryption: Early days, but revolutionary. Enabling you
to compute on encrypted data without decrypting it perfect for
private AI or secure cloud processing.(still not practically)

Step 6: Get Your Hands Dirty

Theory is great, but only until you actually do it. Real learning happens when you create, destroy, and recreate.

CryptoHack: Enjoyable, game-ified exercises where you implement and
attack real crypto systems in a sandbox.
Cryptopals: Code-intensive exercises that force you to construct (and
destroy) ciphers from scratch. Harsh—but genius. Tools to Know:
PyCryptodome (Python): Perfect for prototyping encryption.
OpenSSL: The Swiss Army knife for keys, certs, and command-line
crypto.
Build Projects: Try a password manager, a mini blockchain, or an
encrypted chat app. Nothing cements knowledge like shipping something
real.
Contribute to Open Source: Jump into projects like OpenSSL or
libsodium. Code reviews from seasoned cryptographers are worth more
than any course.

Step 7: Level Up with Advanced Topics

Once you’ve got the fundamentals down, the real frontier opens up.

Post-Quantum Cryptography: RSA and ECC will be compromised by quantum
computers. The answer? New math problems even quantum machines can't crack easily. NIST already standardized two: CRYSTALS-Kyber (for encryption) and CRYSTALS-Dilithium (for signatures) both lattices.
Cryptanalysis: Master attacking like an attacker. Master
differential/linear cryptanalysis, timing attacks, side-channel
leakage. Defense starts with an understanding of offense.
Zero-Knowledge Proofs: Prove you have something—without revealing
what. Deployed in Zcash and Ethereum's zk-rollups, this is privacy
tech at its best.
Lattice-Based Crypto: Not only quantum-resistant but also enables
fully homomorphic encryption. Complex, perhaps but much stronger.

Step 8: Certifications & Career Paths

CompTIA Security+: Nice intro to security fundamentals, including
crypto fundamentals.
CISSP: Industry gold standard for infosec professionals—covers crypto
in depth.
ECES (Certified Encryption Specialist): Extremely crypto-centric in
terms of crypto design and implementation.
OSCP: Hands-on, offensive security cert that stresses actual skill
over memorization.

Where You Can Go:

Cryptographic Software Engineer: Create secure systems from the
ground up.
Blockchain Security Architect: Create crypto protocols for
decentralized applications.
Post-Quantum Researcher: Future-proof encryption against quantum
attacks.
Pen Tester / Security Specialist: Seek out vulnerabilities with
sophisticated crypto knowledge.
Government & Defense: Organizations like the NSA hire top
cryptographers for high-security operations. Final Thoughts

You don't learn cryptography in a weekend. It's a journey of persistent studying, testing, and yes, a lot of failure. But the payoff? Huge. You'll work on interesting problems, earn decent money, and get to make a real difference in protecting people's data in a more and more exposed digital world.

Start with the basics. Move step by step. Don’t fear failure every expert cryptographer learned by breaking things first.

And remember: the best time to start learning cryptography was yesterday.
The second-best time? Right now.

Detailed Explanation of Hashing

Fri, 01 Aug 2025 21:59:58 +0000

The Library Card Revelation

Picture this: You walk into a massive library containing millions of books. You need to find "The Great Gatsby" by F. Scott Fitzgerald. Without any organization system, you'd have to check every single book until you found it - potentially examining millions of volumes! But instead, you walk to a simple card catalog, look up "Fitzgerald," and instantly get the exact shelf location: 813.52 FIT.

This everyday library experience reveals the core magic of hashing - one of computer science's most elegant and powerful concepts. Just as the library transforms "F. Scott Fitzgerald" into "813.52 FIT" for instant book location, hashing transforms any piece of data into a compact, fixed-size "address" that enables lightning-fast storage and retrieval.

But here's where it gets fascinating: hashing isn't just about finding books. It's the invisible force securing your passwords, powering Bitcoin mining, enabling Google's instant search results, and ensuring the evidence in criminal trials hasn't been tampered with. Let's explore why this mathematical transformation has become one of the most important concepts in our digital world.

What is Hashing?

At its heart, hashing is like creating a digital fingerprint for any piece of information. Just as your fingerprint uniquely identifies you while being much smaller than your entire body, a hash value uniquely identifies data while being much smaller than the original information.

Think of hashing as a special kind of one-way mathematical recipe. You put ingredients (your data) into this recipe (the hash function), and it produces a specific dish (the hash value). The remarkable property? The same ingredients always produce the same dish, but you can't reverse-engineer the ingredients from the final dish.

Here's a simple example using a basic hash function on the word "HELLO":

Input: "HELLO"
Hash Function Process: H(72) + E(69) + L(76) + L(76) + O(79) = 372
Final Hash: 372 % 10 = 2

So "HELLO" gets the hash value 2. Every time we hash "HELLO" with this function, we'll always get 2. But if we know the answer is 2, we can't easily determine the original word was "HELLO."

The Three Essential Components

Every hashing operation consists of three fundamental parts, much like our library example:

The Input represents your original data - whether it's a word like "HELLO," a password like "MySecret123," or an entire file containing thousands of pages. This is the raw information you want to transform into a hash.

The Hash Function acts as the mathematical transformation engine. It's the "recipe" that converts your input into a hash value. Different hash functions use different mathematical approaches, from simple addition to complex cryptographic algorithms like SHA-256.

The Hash Output (or hash value/hash digest) is the fixed-size result produced by the hash function. Regardless of whether your input is a single character or a massive file, the hash output is always the same size for a given hash function - SHA-256 always produces exactly 256 bits (64 hexadecimal characters).

The Four Fundamental Properties

What makes hash functions mathematically fascinating? They possess three crucial properties that define their core nature.

1. Deterministic: Same Input Always Produces Same Hash

A hash function must be completely deterministic - like a mathematical equation that always gives the same result. If you hash "password123" today and get the result "7a58db2e," you must get exactly "7a58db2e" every time you hash "password123" in the future, on any computer, anywhere in the world.

This isn't just convenient - it's mathematically essential. Without determinism, hash functions would be useless for verification, data integrity, or any practical application.

Example:

SHA-256("Hello") = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
This result is exactly the same every single time, forever

2. Irreversible: Cannot Retrieve Input from Hash Output

Hash functions are one-way mathematical transformations. Given a hash output, it is computationally impossible to determine what the original input was. This isn't just difficult - it's mathematically designed to be irreversible.

Think of it like this: if you blend a fruit smoothie, you can't "un-blend" it back into separate fruits. Similarly, hash functions "blend" input data in a way that cannot be undone.

Why this matters:

Security: Even if someone steals a database of password hashes, they can't directly recover the original passwords
Privacy: You can prove you know something without revealing what it is
Integrity: You can detect changes without storing the original data

3. Collision Resistance: Mathematically Impossible to Avoid All Collisions

Here's the fascinating mathematical reality: collisions are inevitable. No hash function can avoid them entirely, and this isn't a design flaw - it's a mathematical certainty.

The Pigeonhole Principle proves this: If you have an infinite number of possible inputs (any data of any size) but only a finite number of possible hash outputs (say, 2^256 for SHA-256), then multiple inputs must eventually produce the same hash output.

However, good hash functions make finding collisions practically impossible:

Weak Collision Resistance: Given one input and its hash, it should be computationally infeasible to find a different input that produces the same hash
Strong Collision Resistance: It should be computationally infeasible to find any two different inputs that produce the same hash

Real-world impact: While collisions must exist mathematically, finding them in SHA-256 would require more computational power than exists on Earth.

4. Avalanche Effect

While not one of the core mathematical requirements, the avalanche effect makes hash functions particularly powerful for security applications. A tiny change in input should produce a dramatically different hash output.

Example:

SHA-256("Hello World") = a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
SHA-256("Hello World!") = 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069

Adding one exclamation mark completely scrambled the entire hash - this makes tampering detection extremely reliable.

Building Your First Hash Function

Let's create a simple hash function together to understand the underlying mechanics. We'll build something educational rather than cryptographically secure - think of it as learning to ride a bicycle before attempting motorcycle stunts.

The Mid-Square Method

The mid-square method provides an excellent learning example because you can calculate it by hand and observe how it "mixes" the input data:

def mid_square_hash(key, table_size):
    """
    A simple educational hash function using the mid-square method
    
    Step 1: Square the key
    Step 2: Extract middle digits
    Step 3: Take modulo of table size
    """
    # Convert key to number if it's a string
    if isinstance(key, str):
        # Sum ASCII values of characters
        key = sum(ord(char) for char in key)
    
    # Step 1: Square the key
    squared = key * key
    print(f"Step 1 - Squared: {key}² = {squared}")
    
    # Step 2: Extract middle digits
    # Convert to string to manipulate digits
    squared_str = str(squared)
    length = len(squared_str)
    
    # Take middle 3 digits (or available digits if shorter)
    if length >= 3:
        start = (length - 3) // 2
        middle = squared_str[start:start + 3]
    else:
        middle = squared_str
    
    middle_value = int(middle)
    print(f"Step 2 - Middle digits: {middle_value}")
    
    # Step 3: Take modulo of table size
    hash_value = middle_value % table_size
    print(f"Step 3 - Final hash: {middle_value} % {table_size} = {hash_value}")
    
    return hash_value

# Let's try it with the word "CAT"
result = mid_square_hash("CAT", 100)

Walking through "CAT":

C(67) + A(65) + T(84) = 216
216² = 46,656
Middle digits: 665
665 % 100 = 65

So "CAT" hashes to index 65 in a table of size 100.

Understanding Why This Works

The mid-square method works because squaring amplifies differences between inputs. Two similar numbers like 216 and 217 become 46,656 and 47,089 when squared - much more different than the original values. The middle digits capture this amplified difference while discarding potentially predictable patterns in the first and last digits.

Notice the beautiful transformation: we started with a variable-length input ("CAT") and produced a fixed-size hash output (65). This consistent output size is crucial - whether we hash a single word or an entire novel, our hash function produces the same size result.

Try this yourself: What happens when you hash "DOG" using the same method? Can you predict the result before calculating?

Real-World Hashing: Where the Magic Happens

Now that you understand the mechanics, let's explore how hashing powers the digital world around us.

Password Security: Your Digital Guardian

Every time you log into a website, hashing protects your password through a sophisticated process. Websites don't actually store your password - they store its hash value instead.

Here's how it works with bcrypt, the gold standard for password hashing:

When you create an account:

You enter password: "MySecret123"
bcrypt adds random salt: "MySecret123" + "a8f5f167f44f4964e6c998dee827110c"
bcrypt hashes the result: "$2b$10$3euPcmQFCiblsZeEu5s7p.9OVHgeHWFDk9nhMqZ0m/3pd/lhwZgES"
Only the hash gets stored in the database

When you log in:

You enter password: "MySecret123"
System retrieves stored hash and extracts the salt
System applies same process: hash("MySecret123" + salt)
If the new hash matches the stored hash, access granted

The beautiful security here? Even if hackers steal the database, they only get meaningless hash values. They can't reverse-engineer your actual passwords because of hashing's one-way nature.

Bitcoin Mining: The Computational Race

Bitcoin provides perhaps the most dramatic example of hashing in action. Bitcoin miners are essentially competing in a massive computational race to find specific hash values.

Here's the challenge Bitcoin sets: Find a number (called a nonce) that, when combined with transaction data and hashed with SHA-256, produces a hash value starting with a specific number of zeros.

Example Bitcoin Mining Problem:

Block data: "TransactionData + PreviousBlockHash + 1847563"
SHA-256 hash: 00000000a2c4ff82c4d4c3e2e1b8e8d7f6e5d4c3b2a1908f7e6d5c4b3a29180

The hash starts with eight zeros! Finding such a hash requires trying millions or billions of different nonce values until one produces the required pattern. The current Bitcoin network performs over 150 exahashes per second - that's 150,000,000,000,000,000,000 hash operations every second globally.

Digital Forensics: The Truth Detector

Law enforcement relies on hashing to ensure evidence integrity. When investigators seize a computer, they immediately calculate hash values for all files. These digital fingerprints prove that evidence hasn't been tampered with during analysis.

Example forensic process:

Seize laptop containing potential evidence
Calculate SHA-256 hash: "4d186321c1a7f0f354b297e8914ab240c7e8a4c3a321b2c4d5e6f7a8b9c0d1e2"
Perform analysis on copied data
Recalculate hash after analysis
If hashes match, evidence integrity proven in court

Any modification - even changing a single bit—would produce a completely different hash, immediately revealing tampering.

The Collision: When Different Inputs Produce Same Hash Outputs

Now we encounter one of hashing's most fascinating challenges: hash collisions. A collision occurs when two different inputs produce the same hash output. While this might seem like a flaw, it's actually inevitable and leads to some of the most elegant solutions in computer science.

Why Collisions Are Inevitable

The pigeonhole principle guarantees that collisions must occur. If you have more items than containers, at least one container must hold multiple items. Hash functions map an infinite input space (any possible data) to a finite output space (fixed-size hash values). Therefore, collisions are mathematically inevitable.

Consider a simple example: if our hash function produces values from 0 to 99 (100 possibilities), and we hash 101 different inputs, at least two must produce the same hash output.

The Birthday Paradox in Action

The timing of collisions often surprises people due to the birthday paradox. In a room of just 23 people, there's a 50% chance that two people share the same birthday, despite 365 possible days. Similarly, for a hash function that produces 1,000 different possible outputs, you'll likely encounter your first collision after hashing only about 37 different inputs - much sooner than intuition suggests.

import math

def collision_probability(num_inputs, output_space_size):
    """Calculate probability of at least one collision"""
    # Using birthday paradox formula
    probability = 1.0
    for i in range(num_inputs):
        probability *= (output_space_size - i) / output_space_size
    return 1.0 - probability

# For a hash function with 1000 possible outputs
output_space = 1000
for inputs in [10, 20, 30, 40, 50]:
    prob = collision_probability(inputs, output_space)
    print(f"{inputs} inputs: {prob:.2%} collision probability")

Understanding Hash Collisions

When collisions occur in cryptographic contexts, they represent potential security vulnerabilities. For example, if an attacker can find two different files that produce the same hash output, they might be able to substitute a malicious file for a legitimate one without detection.

However, for most practical purposes, well-designed hash functions make finding collisions computationally infeasible. Modern cryptographic hash functions like SHA-256 are specifically designed so that finding two inputs that produce the same hash output would require astronomical computational resources.

A Brief History

The evolution of hashing reflects humanity's growing need to organize and secure information.

The Foundation Era (1950s-1960s) Hans Peter Luhn at IBM pioneered hashing concepts while developing the KWIC (Key Word in Context) indexing system. His insight that data could be "chopped up" and reorganized for faster access laid the groundwork for modern hash tables.

The Cryptographic Awakening (1990s) Ronald Rivest's MD5 algorithm brought hashing into the security spotlight. Suddenly, hashing wasn't just about data storage - it was about protecting information integrity and authenticity. However, as computing power grew, MD5's vulnerabilities became apparent.

The Security Arms Race (2000s-Present) The development of SHA-1, then SHA-2, then SHA-3 represents an ongoing arms race between cryptographic innovation and attack sophistication. The 2017 SHAttered attack demonstrated practical SHA-1 collisions, forcing widespread migration to stronger algorithms.

Today's landscape includes:

SHA-256: The current security standard
SHA-3: Mathematical diversity insurance
BLAKE3: Performance breakthrough
Argon2: Memory-hard password protection

Modern Applications: Hashing Everywhere

Once you understand hashing, you'll start noticing it everywhere in modern technology.

Database Performance: PostgreSQL uses hash indexes to transform "WHERE user_id = 12345" queries from linear scans through millions of records into instant O(1) lookups.

Load Balancing: Companies like Netflix use consistent hashing to distribute billions of requests across thousands of servers. When you stream a movie, hashing determines which server handles your request.

Content Distribution: Blockchain networks use hashing to create tamper-evident ledgers. Each block contains the hash of the previous block, creating an unbreakable chain of trust.

Data Deduplication: Cloud storage services use hashing to detect duplicate files. If a million users upload the same photo, the service stores it once and uses hash values to reference it.

Coder Legion - Recent posts tagged cryptography

Noita's Eye Messages in One Evening: 7 of the 9 Known Rules, and the Conclusion I Had to Take Back

From eyes to numbers

What fell out in minutes

A guess that died in one line

The conclusion I wrote down

What the twenty runs actually were

The model that survives

What an evening can't do

Sources

Keep a record of what you actually ran.

🚀 Architecture Shift: Why Cryptographic Tokens Beat Path-Based Routing

# The Revolution in Protocol Security: How It Actually Gets Used

The problem with existing tools is not only capability - it is also access

CI/CD integration: verify on every commit

IDE integration: find vulnerabilities while you write

Real-time analysis: the daemon and the sniffer

Web interface: collaboration, not just output

Converters: meeting people where they are

Platform, not tool

The revolution is practical, not technical

Status

We're Building a Protocol Analyzer That Finds Attacks and Fixes Them

The problem we are solving

The vision

Automatic repair: the core capability

Performance: the target

Sixteen attacker models

Neural networks: guiding search with GNNs and active learning

Architecture: modularity as a design requirement

What we do that no one else does

What exists now

The bottom line

The Other Half of Authentication Is 345 Years Old

A science for telling the true from the false

What PKI does, and the cases it can't reach

The bridge already exists, it just never crossed the wall

What to build with this

Sources

Understanding Symmetric vs Asymmetric Encryption as a Backend Engineer

What is Encryption?

Symmetric Encryption

How Symmetric Encryption Works

Step 1

Step 2

Step 3

Step 4

The Key Sharing Problem

Why Symmetric Encryption Is Still Useful

Fast

Great for Large Data

Symmetric Encryption Drawbacks

Key Distribution Is Hard

Asymmetric Encryption

How Asymmetric Encryption Works

Step 1

Step 2

Step 3

Step 4

Step 5

Why Does This Work?

Common Asymmetric Encryption Algorithms

Advantages of Asymmetric Encryption

Easy Key Distribution

Better for Establishing Trust

Disadvantages of Asymmetric Encryption

Computationally Expensive

Poor for Large Data Transfers

Symmetric vs Asymmetric Encryption

Symmetric Encryption

Asymmetric Encryption

The Part That Finally Made TLS Click

Step 1

Step 2

Step 3

Step 4

Why This Matters for Backend Engineers

Final Thoughts

Sovereign Synapse: The Context Cleaner

Sovereign Synapse Series | Post 2