DEV Community: Juan Carlos Isaza

My adaptive memory stayed empty in production, and it wasn't a bug

Juan Carlos Isaza — Mon, 07 Sep 2026 18:25:48 +0000

I had a table in the database that was supposed to fill itself. Its job was to learn from failures: every time the system tried a variant of something and it didn't work, it saved it, to recycle later in another context where it might. A laboratory of failed attempts, piling up.

In production it had zero rows. It had been deployed for days and hadn't saved a single record. Meanwhile a neighbouring table —another memory, the one that notes which work is already exhausted so as not to repeat it— was growing normally.

The temptation is obvious: there's a bug in the write. I went looking for it, and it wasn't there.

Zero rows isn't the same as a write error

The path that saves into that table emits a warning if the write fails. I searched the logs for those warnings: zero. No write had failed.

That's a fact, not an absence of one. If the path had been taken and had failed, it would have left a trace. Zero traces and zero rows fit only one explanation: the write path never ran. Not ran-and-failed. Didn't run.

That's the difference between a real negative and a negative that was never put to the test, and they look the same unless you look for the positive control —something the log WOULD show if the path had been taken—. Without it, "healthy and quiet" and "dead" look identical.

Two mechanisms starving each other

Why didn't it run? Because of another mechanism, upstream, doing its job well.

That system has a negative memory: when it exhausts everything it knows how to try against a target, it notes it down, so as not to spend effort again on something it already knows won't pay. It's a sensible optimisation. But it sat before the phase that generated new variants —the phase that, on failing, would have fed the library—. As soon as a target went "exhausted", that phase was skipped entirely. And if the phase never runs, it never produces a failure to save.

Each mechanism, on its own, is correct. The negative memory avoids useless work. The library learns from failures. Together they formed a deadlock: the first starved the second. The library could only fill from a phase the other one switched off.

It's a recurring pattern: when you add a mechanism to contain what another one does, and the system starts behaving strangely, suspect the design before the code. The symptom —a table at zero— looked like a bug; it was a tension between two pieces that are each fine on their own.

A value with two meanings is two fields

There was a second problem, and it's the more instructive one. The library only saved one kind of failure: the one where the system processed the attempt and returned a normal result, without success. The other kind —when the attempt was blocked up front, without ever being processed— it discarded, with a reasonable argument: a block says more about the target's posture than about the variant.

But that argument falls apart when recycling. The variant blocked at one target is an untried candidate at another, with a different configuration. Discarding it was, precisely, failing to learn from the most common failure.

The fix was not to collapse the two meanings into one. "Processed failure" and "blocked failure" are two distinct signals, so they go in two distinct fields: two counters. That way the library saves both, and whatever recycles them orders them —the processed ones, more informative, first; the blocked ones, at the back, but present—. A value with two meanings isn't one field: it's two.

What was left

Two fixes on the same symptom. Neither touched the write, which was always correct. One broke the deadlock —letting the phase feed the library even when the target is "exhausted"—; the other split the two faces of failure. And the table at zero, which looked like the bug, was the messenger: a path that never ran and a condition too narrow, seen through the same hole.

I killed the process and the drain still hung: a grandchild held the pipe

Juan Carlos Isaza — Sun, 06 Sep 2026 18:29:06 +0000

A program of mine hung for forty minutes. Not spinning at a thousand loops a second: at zero percent CPU. It wasn't doing too much work; it wasn't doing any work at all. And still it wouldn't finish.

The program does something common: it orchestrates external command-line tools. It launches one, reads what it writes to standard output, and moves on to the next when it's done. So it doesn't get stuck when a tool drags, each one has a timeout: when it fires, the process is killed and we carry on.

That's the part that failed, and it failed where no one looks: after killing the process.

Killing the process doesn't close the pipe

When you read a subprocess's output, you read from a pipe: one end writes (the subprocess), the other reads (you). Your reader doesn't finish when the subprocess dies. It finishes when EOF arrives, and a pipe's EOF arrives only when the last write end is closed.

Almost always they coincide: the subprocess is the only writer, it dies, its end closes, EOF arrives, your reader finishes. All in microseconds.

But "almost always" isn't "always". The tool I launched launched another one in turn —a grandchild—. And that grandchild inherited the pipe's write end, because on Unix a child inherits its parent's open descriptors unless told otherwise.

So when the timeout fired, I killed the child. Its end closed. But the grandchild was still alive, with its copy of the descriptor open. The last write end hadn't closed. EOF never came. And my reader sat waiting for an EOF that would never arrive —at zero percent CPU, blocked in a read(), indistinguishable from slow work—.

The symptom that deceives

What makes this failure so hard to see is that it doesn't look like a failure. An infinite-loop hang burns CPU: you see it in top instantly. This one spends nothing. The thread is asleep in the kernel waiting for data that isn't coming. In the process list it looks healthy. In the metrics it looks like it's "taking a while". The only way to tell "hung forever" from "running slow" is to look at the thread stack and see the read() that never moves.

The fix isn't killing better

The reflex is to try to kill the grandchildren too —a process group, a session, the whole tree—. Sometimes you can, sometimes you can't: a process can escape the group, a grandchild can outlive its parent on purpose.

But there's a simpler and more honest way out, and it comes from a single question: which process, exactly, is going to close that descriptor? If the answer is "none that I control", then waiting for EOF is waiting for something that won't happen. And a wait on something that won't happen isn't fixed by waiting better: it's bounded.

The fix was to put a timeout on the drain itself. After killing the process, we wait for EOF for a few seconds; if it doesn't come, we abandon the read and move on. Whatever the tool managed to write before is already captured, so nothing is lost. And a descriptor a grandchild keeps open stops mattering: no one waits on it indefinitely.

The rule, beyond pipes

Every wait —a loop that spins until a condition holds, an await on a descriptor— has one question behind it: which process is going to make that condition true? If there's none, the wait is impossible, and an impossible wait gives no error: it looks exactly like work that's taking a while. Zero percent CPU, not advancing, forever.

Before you write the wait, name the process that will end it. If you can't name it, don't write it without a cap.

Fifty seconds for half a megabyte: the optimisation that fixed the constant, not the order

Juan Carlos Isaza — Sat, 05 Sep 2026 18:29:16 +0000

A cryptography library had a bottleneck no test could see: encrypting half a
megabyte took fifty seconds. Every test passed. They had been passing for months.

The cause is a trap that keeps recurring: a correct, well-documented
optimisation that fixes the constant and not the order — and whose comment,
precisely because it is well written, convinces the reader the problem is already
solved.

What the code did

Quipu renders encrypted data as a sequence of symbols. To do
that it converts the whole message into a single huge integer and repeatedly
divides it to extract digits, the same way you would convert a base-10 number to
base 2 by hand.

The code did not divide one digit at a time. It carried a sensible optimisation:
divide by the largest power of the base that fits in a machine word, extracting
nine digits per pass instead of one. The comment explaining it opened by saying
that doing it one at a time would be quadratic, and then described the
improvement.

All true. And the result was still quadratic: extracting nine digits per pass
divides the work by nine; it does not change how the work grows.

That sentence — "doing it this way would be quadratic" — reads in the past tense,
as if it described the previous state. It described the current one.

The measurement, which is the only thing that says so

Size	Time	Factor per doubling
64 KiB	0.79 s	—
128 KiB	3.16 s	×4.0
256 KiB	12.6 s	×4.0
512 KiB	50.7 s	×4.0

Exactly four, three times running. That is textbook quadratic: every time the
input doubles, the time quadruples. Extrapolating, ten megabytes would have cost
about five and a half hours.

And here is the point: a correctness test sees none of this. A slow algorithm
produces exactly the same bytes as a fast one. The suite stayed green, and would
have stayed green forever.

The fix is two hundred years old

Nothing had to be invented. Divide-and-conquer radix conversion is a classical
algorithm: instead of peeling digits off one end, you split the number in half —
dividing by a power with half as many digits — and repeat on each half. The tree
has as many levels as the size has doublings, and each level costs one big
multiplication instead of thousands of divisions.

Size	Before	After
512 KiB	50,698 ms	457 ms	111×
10 MiB	~5.6 h	41.4 s	~490×

The factor per doubling dropped from 4.00 to 2.82, which is not an arbitrary
number either: it is what you get from combining the tree with fast big-integer
multiplication.

What to check BEFORE writing it

And this is what separates an improvement from one that makes things worse:
divide-and-conquer only pays off if your big-integer library's division is
sub-quadratic.

If division is schoolbook, splitting in half and recursing is still quadratic —
and with a worse constant than the loop you set out to replace. You would have
written an algorithm that is more elegant, harder to read, and slower.

The library in use turned out to ship Burnikel-Ziegler recursive division, so it
pays off. That gets checked before the first line is written, not after measuring
a disappointing result.

How to avoid this in the next repository

The question that saves the five and a half hours is not "is this optimised?" but
"did the ORDER change, or only the constant?" — and it is answered with two
sizes and one division, not by reading the code:

if doubling the input doubles the time, it is linear;
if it quadruples, it is quadratic;
if it goes up by ~2.8, there is a tree and a fast multiplication behind it.

It costs a minute. And that measurement deserves to become a test that fails if
someone reintroduces a loop: a cost regression is invisible to a correctness
suite, because the code still gives the right answer — it just takes five hours.

I said no data was leaving. On the first good run, two records left

Juan Carlos Isaza — Fri, 04 Sep 2026 18:42:58 +0000

I was asked whether the system was sending patient data to an external body while the integration was half-built. I went and read the logs of every run. They all died early: some with a 415 because the content type wasn't what the other end expected, others with a 500. Not one showed an outbound call.

I answered that nothing was going out.

The first run that got past the 500 sent two requests carrying real clinical data.

My answer had been false from the start, and the worst part is that it was false in a way that felt rigorous: I had looked. I had evidence. The evidence was logs of real executions, not assumptions.

A negative says nothing on its own

The mistake wasn't misreading the logs. It was not noticing what produced that silence.

The runs died before reaching the code that sends. The log didn't say "I didn't send"; it said "I never got to the part that sends". Those are two different statements and they produce exactly the same output: nothing.

That's the general shape of the problem, and it turns up everywhere once you look for it:

A counter at zero can mean "it didn't happen" or "the counter was never incremented". A "not found" can mean "it doesn't exist" or "I looked in the wrong place". A green test can mean "it passed" or "it skipped itself". An exit 0 can mean "it worked" or "the command was strangled by a pipe that swallowed the exit code". A silent dashboard can mean "everything is fine" or "the process feeding it has been dead for three weeks".

In all five, the evidence is identical. And in all five, the optimistic reading is the reassuring one, so it's the one chosen without thinking.

The positive control

The fix isn't to be more suspicious. It's to demand one specific thing before accepting any negative:

Find something the log MUST show if the path was actually taken.

If the system had reached the part that sends, something would have to appear in the log: the "preparing request" line, the batch identifier, the connection attempt. Any signal that is impossible without having gone through there.

If that signal isn't there, you haven't demonstrated that it doesn't send. You've demonstrated that you don't know whether it sends. And "I don't know" is a perfectly respectable answer; "it doesn't send" was a lie.

When that witness exists, the negative starts to count, because now it does separate the two worlds: got there and didn't send, versus never got there.

And you have to look again after the first success

This is the second half, and in my case it was the expensive one.

I looked after the failures. That's the natural thing: you investigate when something goes wrong. But the behaviour I'd been asked to check only appeared when things went right, and that doesn't happen until someone fixes the 415 and the 500.

So the complete rule has two moments: check that the path executed, and check again after the first successful run, not only after the failed ones. The first green is the most dangerous moment in an integration, because that's when the new code finally runs end to end and nobody is watching: it has already been filed as solved.

Anything that can stay silent must say why it is silent

From this comes a design consequence that changed how I write anything that watches.

A process that only speaks when it finds a problem is indistinguishable from a dead process. Both produce the same silence, and silence is exactly what we read as "all good".

So a watcher that can legitimately stay quiet must emit, every cycle, why it is quiet: "412 entries checked, 0 violations" instead of saying nothing. It costs one line. And it turns "healthy and quiet" into something that looks different from "dead", which is exactly what the watcher exists to distinguish.

The same goes for tests: a suite that reports "0 failures" without saying how many tests it ran has said nothing. Zero out of zero is green.

What's left

Before claiming something does not happen, check that the code capable of doing it actually ran. If you can't check that, the answer is "cannot be determined", not "no".
Find the witness: the signal the log would have to show if the path had been taken.
Look again after the first success, not only after the failures.
Anything that can legitimately stay silent must say why it is silent, every cycle.

None of the four costs money or any appreciable time. The one I was missing was the first, and the bill was two transmissions of patient data that I had certified did not exist.

Don't claim a security boundary holds — demonstrate it

Juan Carlos Isaza — Thu, 03 Sep 2026 18:20:16 +0000

A system has to run a chunk of code you don't control —a plugin, a dependency, something generated— and you want to guarantee that code cannot touch the file system or spawn processes. Not that it "shouldn't": that it can't, mechanically. That's capability confinement, and it's one of the central problems of runtime security.

Designing it and demonstrating it are two different things, and confusing them is expensive.

A design is a claim

You can write an impeccable document: "access to fs and to spawning processes is controlled like this, with these mechanisms, under this threat model". It's real and necessary work. But it's a claim. And the failure mode of a security boundary is that it looks like it holds until it doesn't —silent, invisible in tests, visible only when someone crosses it—.

In security, an unverified claim has exactly the shape of a beautiful, wrong architecture. The design can assume that a module-loader hook fires at a point where it actually doesn't, and all the reasoning hanging off that is correct and worth nothing.

The mechanisms exist, and there are several

In Node, to name a concrete runtime, there are at least three layers, and they aren't interchangeable:

The native permission model (--permission, --allow-fs-read…), which cuts access to fs and to spawning processes at the whole-process level.
SES / Hardened JavaScript (Compartments, lockdown()), which confines what each module can import within the process.
Module-loader interception, which controls what resolves when the code asks for something.

Choosing well among them is the design. But choosing well doesn't prove the choice holds against the real dependency tree you're going to run.

Demonstrate instead of claim

The alternative to signing off a design is delivering a confinement harness: untrusted code that tries to reach the dangerous capability —open a file, spawn a process— against the real runtime and its real dependency tree, and a log that shows each attempt was blocked. Or, if something escapes, exactly where.

The difference isn't cosmetic. "I think it's confined" and "here's the evidence that an attempt to read a system file from the plugin returned permission denied" are claims of very different weight. The second is the discipline I use for everything else applied to security: cross the program boundary and measure what comes out, not what you think comes out.

The honest part

There's a temptation to sign off the boundary from an authority you haven't earned —because the design looks good, because the mechanisms exist—. The honest discipline is the opposite: what you can back today, you back; what depends on a runtime detail you don't master, you don't assert from memory: you validate empirically, and what can't be demonstrated yet is marked as the seam to co-review, not hidden.

A demonstrated boundary covers exactly the gap a claimed one leaves open. And for whoever has to trust the confinement, a harness that attacks its own boundary and keeps the evidence is worth more than the word of whoever designed it.

My detector was blind across 1,029 of 6,309 lines and its three tests stayed green

Juan Carlos Isaza — Thu, 03 Sep 2026 01:35:07 +0000

The guard worked. I had written it so that no session open in one project could touch another project's files, it had three tests, and all three were green. They had been green for months.

It was blind across 1,029 of the 6,309 lines it was watching. Eight hundred and twenty-four of them executable.

And the three tests kept passing, because all three looked at paths that were already clean.

The defect isn't in the detector: it's in how you test it

You test a detector with cases. The natural thing is to take them from the system itself: feed it the real files and check that it finds nothing, because the system is healthy. A hundred cases, all green, and the feeling of having measured something.

Nothing has been measured.

A bench made only of negatives over artefacts that are clean today comes out green with the correct rule and comes out green with a rule that doesn't look. A file with no violations returns empty in both worlds: the one where the detector works and the one where it broke three months ago. The two results are identical, so the bench cannot tell them apart.

What that bench measures is the watched artefact, not the watcher. And the watcher is precisely the piece whose failure never complains.

It's the disguised form of a very familiar error, which is why it slips through: the tests exist, they are well written, they are readable, and they pass. There is nothing to flag in code review. The defect isn't in any line; it's in the set.

The pair

The fix is cheap and fits in one sentence: every probe ships with two cases, not one. The one that MUST see something and the one that MUST NOT.

With only the first, an instrument that says yes to everything passes just the same. With only the second, a blind one does. You need both, and you need them together: each covers exactly the other's blind spot.

And there are two conditions that get forgotten the moment you write the second case, and they are what separates a real pair from a decorative one.

First: the red case has to fail through the real path. Breaking the rule in the test harness doesn't count. You have to break it in the code being measured, and require the test to actually go red. If mutilating the detector leaves the test green, what you were measuring was the harness. And it's worth checking that the mutant compiled: a test that goes red because the code doesn't build has demonstrated nothing about the rule.

Second: the detector is also tested against synthetic input. The real files aren't enough. You have to fabricate a text that DOES contain the violation and another that doesn't, and push both through the same seam the real path uses. If the test enters through another door — a helper, an already-constructed object — the red can come from the harness rather than the detector, and you're back where you started.

The mutant already exists, and it's free

This is the part with the highest return per minute invested, and almost nobody uses it.

When you fix a detector, the previous version of the rule is the mutant you need. It's in history, one command away:

git show HEAD:path/to/detector.py > /tmp/previous_version.py

Run the new pair of tests against that old version. If the red case goes red with it, the pair discriminates: it distinguishes the good rule from the blind one. If it comes out green against both, the new tests are worth no more than the old ones and nothing has been fixed yet.

It costs a minute. It's the difference between believing you repaired a detector and knowing it.

How the blind spot surfaced, which also teaches something

No test found it. Pulling the opposite thread did.

The guard was producing a false alarm: it warned every time a command redirected to any file at all, even /dev/null. Annoying and visible. While writing the missing case to fix that false positive, its silent twin appeared: writing directly into another project's file never warned at all. It had been like that from day one.

They weren't two defects. It was one, seen from both sides. The noisy side complained every day; the blind side was never going to complain.

From which comes a practical rule that holds for any detector: when you fix a false positive, go looking for the false negative that shares its cause. The noisy one leads you to the mute one, and the mute one is the expensive one.

What's left

Three things, and none of them costs money:

A bench of only negatives does not discriminate, however many cases it has. If all your tests assert "there's nothing here", they come out green with the good rule and with a dead one.
Every probe goes out with its pair, the red fails through the real path, and the mutant comes from history.
Every noisy alarm hides a silent twin. Go find it when you fix the loud one.

And the uncomfortable part: this happened in a guard of mine, written by me, with tests written by me. Discipline doesn't collapse while auditing someone else's work; it collapses exactly where the thing being checked is something you just wrote, because thinking it through feels like verification and isn't.

Sealing a file so nobody can argue you touched it

Juan Carlos Isaza — Tue, 01 Sep 2026 18:24:09 +0000

An argument about a digital file is almost never lost over what the file says. It is lost one question earlier:

How do we know that is the file you received, and not the one you edited last night?

If the answer is "trust me", you have already lost. However right you are on the substance.

This problem is not exclusive to a courtroom. The auditor receiving a log dump has it. So does the team documenting an incident, or anyone keeping a copy of a contract signed over email. In every case the need is the same: being able to prove that a set of bytes has not changed since a given moment — and having that proved by someone who is not you.

That is why I wrote Tunjo: a Rust tool that walks material read-only, computes its fingerprint, and signs a record anyone can verify.

Why a tree and not a hash

The obvious approach would be to concatenate everything and take one SHA-256. It works, and it is useless in practice.

When someone disputes one file — a specific email out of four thousand — a single hash leaves you two options: hand over the complete set so it can be recomputed, or ask to be believed. The first exposes material that has no business being exposed; the second is not evidence.

A Merkle tree solves exactly that. Each file is a leaf, each pair of nodes combines upward, and a root remains. To prove a leaf belongs to that root, you only need to show that leaf and the path of hashes to the top: a few kilobytes. The rest of the set is never touched.

Two details of the tree that are not optional:

// Domain separation: a leaf can never pass itself off as an internal node.
h.update([0x00]);          // leaf
h.update([0x01]);          // internal node

// And the root binds the number of leaves.
h.update([0x02]);
h.update(n.to_be_bytes());

Without the first, a leaf hash could be presented as if it were a node of the tree. Without the second you get the classic ambiguity of trees with an odd number of leaves: two different sets can produce the same root. It is an old, well-known bug, and it keeps showing up in new implementations.

The fingerprint covers state, not just content

The leaf is not the hash of the file: it is the hash of the complete element — path, size, timestamp, status and content hash.

The difference matters. If the fingerprint covered only content, moving a file to another folder, renaming it, or replacing it with a link pointing at the same content would leave the root intact. And those three moves change what the set means: where a document was is part of the fact being documented, not a presentation detail.

Signing for ten years from now

The record is signed with the triple-hybrid signature from Quipu: Ed25519 + ML-DSA-87 (FIPS 204) + SLH-DSA-SHA2-256s (FIPS 205) — and all three must validate.

This is not algorithm collecting. The useful life of this is not measured in months: a case file can take years to resolve, and the signature has to still verify at the end. The three pieces fail for different reasons — Ed25519 against a quantum computer; ML-DSA for being recent and lattice-based; SLH-DSA only if the hash function breaks — and all three are needed at once for the seal to hold. One falling does not bring down the record.

The cost is honest: the signature weighs about 34 KB. To seal a set of files, that is noise.

Verifying the signature is not enough

This is the easiest mistake to make when implementing something like this. The signature covers the complete JSON of the record, including the integrity root. If verification stops at checking the signature, you have accepted a root nobody recomputed: someone holding the key could sign a record whose root does not correspond to the elements it lists, and it would pass.

That is why verification always recomputes the tree, and only then looks at the signature. There is a dedicated test for that exact case: an authentic signature over a lying root must fail.

$ tunjo verificar acta.json --origen ./evidence
SEAL VALID
  content:  4 elements, 3 with verifiable content
  root:     d9f6f68f591c6af087838dc27049a4194ab70525c350b79ec22446f9c12f9e33

1 DISCREPANCY(IES) against evidence:

ALTERED    attachments/c.pdf
           record: 3fdbaf9c795e22f14e16974c37b62ed381b9c8c4ac7bcbe1a01f13d08ec46643
           disk:   9af5d94042eafbf2c335aa874085b263ff0201aee5e5033fd4c432e92de0093d

When a fact is missing, make noise

An integrity tool that hides its own failures is worse than not having one, because it produces confidence without backing. Three decisions on that:

An unreadable file stops the sealing. It is not skipped silently. If it really is unreadable, you have to ask for that explicitly, and then the record logs it as an error: of that element it is recorded that it existed and that reading failed, and nothing more.

About the clock, the truth is told. The record requires declaring how it was checked against an external source. If nothing is declared, it writes "NOT VERIFIED" rather than staying quiet. Without a third-party timestamp this proves relative order, not a certain date — and it says that too.

Symbolic links are not followed. Where they point is recorded. Following them would take the acquisition outside the material that was received.

What it deliberately does not do

It does not detect intrusions, does not attribute authorship, and concludes nothing. I could add heuristics saying "there was an attack here", and it would be a mistake: whoever signs a report has to be able to defend every statement line by line, and nobody defends a heuristic they did not write. When that statement falls, it drags the rest of the report with it.

Nor does it prove the past. It attests from the instant of acquisition: if the material arrived already altered, the seal faithfully certifies altered material. That is written in the record it generates, not in the fine print.

The verifier is public, and not out of generosity

If the only person who can check a seal is the one who issued it, it is not evidence — it is a claim in technical formatting. That is why the verifier is free software and its code is published.

I checked it the only way that counts: I cloned the public repository on a clean machine, built it from scratch, and used that binary to verify a record sealed elsewhere. Valid. Then I altered one byte of an attachment and the same binary flagged that file and only that one.

git clone https://github.com/isazajuancarlos/tunjo
cd tunjo && cargo build --release
./target/release/tunjo verificar acta.json --origen ./evidence

Rust, AGPL-3.0, and the tests include a simulation of 240 comparisons: one byte is altered in each of 120 files, and it is required to flag that one and only that one, and to leave no false positives once restored. Detecting is easy; discriminating is the work.

They steal your database and cannot crack a single password

Juan Carlos Isaza — Mon, 31 Aug 2026 18:15:58 +0000

Picture the worst Monday: someone walked off with a dump of your users table. Emails, names, and the password column.

The good news is that you do not store passwords in the clear — you store hashes, with Argon2id. The bad news is that this matters less than it seems.

Why the hash alone is not enough

Argon2id makes every attempt cost memory and time. It is a real defence and you should use it. But look at what holds it up: making each attacker attempt expensive.

And the attacker holding your database plays by different rules:

They are not in a hurry. No rate limit, no account lockout, no logs to give them away. They can take months.
They do not guess randomly. They start with leaked password lists, which cover an uncomfortable fraction of any real user base.
They do not use your server. They use GPUs rented by the hour.

Raising Argon2's cost helps, but you pay it on every legitimate login and they pay it once per candidate. The arithmetic is not on your side: if a password sits in the first ten thousand entries of a leaked list, no reasonable parameter saves it.

The underlying problem is that the attacker has everything they need. The hash, the salt and the parameters are all in the same dump. They can compute the whole function on their own.

The idea: make a piece missing

What if computing the hash depended on a secret that is not in the database?

The simple version is a pepper: a key in the application config that gets mixed with the password before hashing. It helps, and it has two serious problems:

It usually leaks along with the database. If the attacker got into the server, the environment variable was one cat away.
It cannot be rotated. Changing the pepper invalidates every hash at once.

An OPRF solves the first one at the root: the secret lives in another service, and the elegant part is that this service never sees the password.

What an OPRF is, without the maths

An Oblivious Pseudo-Random Function is a computation between two parties with an unusual property:

You send your password blinded — mathematically masked. The server receives noise.
The server applies its secret key k to that noise and returns more noise.
You unblind it and get a value that can only be obtained with that key k and that password.

The server does not learn your password. You do not learn its key. And without talking to it, nobody can compute that value.

That value is what you hash with Argon2id and store.

Now the attacker holding your database has the hash, the salt, the parameters… and is missing k. They cannot test a single candidate offline. To attack, they have to talk to the OPRF service once per attempt — and there you do have rate limits, quotas and logs.

They have turned an unlimited offline attack into a measurable online one. That is the whole trick, and it is enormous.

The part almost nobody implements: the "verifiable"

There is a catch. If the OPRF server is compromised, or simply uses the wrong key, it returns garbage values and you never find out: you hash garbage, store it, and lock out all your users. Worse, someone controlling the server could answer with a key they know.

That is why the variant that matters is the verifiable one (VOPRF, RFC 9497): the server attaches a DLEQ proof that it used the correct key, and the client verifies it against a public key it has pinned.

And here is the detail that makes half the integrations you will find out there decorative: that public key has to be pinned out of band. If your client asks for it from the same server it is about to verify, you have verified nothing — you asked the examinee to bring their own answer key.

It is an easy mistake to make. I made it: two of my own clients would fetch the key from the server if the integrator omitted it. It was fixed by making it mandatory.

What breaks, said before it happens to you

No architectural decision is free, and this one has three real costs:

1. Your logins depend on another service. If the OPRF does not answer, you cannot verify passwords. And here the only correct answer is to fail closed: if the service is down or the proof does not validate, the login fails. The temptation to "degrade to unhardened" turns an outage into a bypass — and an attacker who can take the service down skips the whole protection.

2. The key k never rotates. Rotating it invalidates every secret hardened with it. It is a once-and-for-all decision and must be treated as one.

3. It adds latency to login: one network round trip. Measurable, small, but not zero.

If your application cannot accept point 1, this is not for you. I would rather say so here than afterwards.

How it is used in Django

I wrote the primitives in Rust following RFC 9497 and verified them against the official Appendix A.1.2 vectors, then packaged them for Python. The Django integration is a hasher that plugs in where yours already sits:

pip install quipu-oprf-django

# settings.py
PASSWORD_HASHERS = [
    "quipu_oprf_django.hashers.OprfArgon2PasswordHasher",   # preferred
    "django.contrib.auth.hashers.Argon2PasswordHasher",     # migration
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
]

QUIPU_OPRF = {
    "BASE_URL":   os.environ["QUIPU_OPRF_URL"],
    "API_KEY":    os.environ["QUIPU_OPRF_API_KEY"],
    # 64 hex, PINNED OUT OF BAND. Do not ask the server for it.
    "PUBLIC_KEY": os.environ["QUIPU_OPRF_PUBKEY"],
    "TIMEOUT":    5.0,
}

Migration is gradual: existing users keep logging in with their old hasher and get hardened the next time they sign in.

The package is Apache-2.0 on purpose. It lives inside your authentication server, and putting a network copyleft licence in there would be indefensible.

Self-host it or pay for it

The server is open source (AGPL) and you can run it yourself: it is one binary with SQLite and needs nothing else. If you do that, you pay me nothing, and that is perfectly fine.

What is charged for at oprf.xiliux.com is not having to operate it: availability, quota, and making sure the key k survives your deployments. Because the day you lose that key, you lose every password at once.

What this is not

It is not magic and it replaces nothing you should already be doing: keep using Argon2id with serious parameters, keep your second factor, keep limiting attempts.

What it does is take away the most profitable attack an adversary has against a stolen database. That is not nothing.

The code is at github.com/isazajuancarlos/quipu. The VOPRF primitives are Apache-2.0 and conform to RFC 9497. The project does not yet have an independent cryptographic audit, and that has to be said too.

Hybrid encryption: why combine classical and post-quantum cryptography

Juan Carlos Isaza — Sun, 30 Aug 2026 18:16:42 +0000

When a new cryptographic algorithm appears, a tension shows up: classical algorithms such as X25519 or Ed25519 have resisted attacks for years, but are vulnerable to a future quantum computer; post-quantum ones such as ML-KEM or ML-DSA resist quantum attacks, but are newer and less tested. Hybrid encryption resolves the tension: use both at once.

The idea in one sentence

Combine a classical and a post-quantum algorithm so that the system only breaks if both fail simultaneously.

A classical attacker would have to break the post-quantum algorithm; a quantum attacker would have to break the classical one and the post-quantum one. You gain security against the future without betting everything on a young algorithm.

Two places to apply it

Key exchange (encrypting for a recipient). You combine:

X25519 — classical key exchange, fast and heavily tested.
ML-KEM-1024 — NIST's post-quantum key encapsulation mechanism, at its highest level.

The two resulting keys are mixed with a context-bound derivation function (HKDF), so that neither one alone is enough.

Digital signatures (authenticity). You combine:

Ed25519 — classical signature.
ML-DSA-87 — NIST post-quantum signature.

The message is accepted only if both signatures verify — an AND combiner.

One principle that never breaks

There is a golden rule in cryptography, Kerckhoffs's principle: a system must be secure even if the attacker knows its entire design; security lives in the key, not in hiding the format. A good hybrid system uses public, audited primitives — XChaCha20-Poly1305 to encrypt, Argon2id to derive keys from passwords, HKDF to separate domains — and never invents its own cryptography.

How Quipu applies it

Quipu is a free library implementing exactly this approach for data at rest: hybrid X25519 + ML-KEM-1024 encryption, hybrid Ed25519 + ML-DSA-87 signatures, and only verified primitives underneath. It targets NIST security level 5 (CNSA 2.0) and is open source, so anyone can review how it works.

An honest note: Quipu composes standard primitives, but the composition has not yet passed an independent cryptographic audit. For real high-value secrets, that external review is the seal worth waiting for.

The code is at github.com/isazajuancarlos/quipu, AGPL-3.0.

Quipu: post-quantum encryption in pure Rust, with a Python wheel

Juan Carlos Isaza — Sat, 29 Aug 2026 18:37:43 +0000

Protecting data that must stay secret ten years from now is a problem for today: an adversary can capture your encrypted traffic now and decrypt it once quantum capability exists (harvest now, decrypt later). Quipu is a free hybrid post-quantum encryption library for data at rest: it combines proven classical cryptography with the new kind, so that it only breaks if both fall at once.

Pure Rust, and why

Quipu started out aiming at several languages: a Rust core with a C ABI on top and bindings for Python, Node and Go. It worked, but the lesson was clear: maintaining a stable C interface plus four bindings, each with its own packaging and interoperability tests, was complexity that did not pay for itself against the real goal — protecting data at rest — and it widened the attack surface with unsafe we did not want.

Today Quipu is pure Rust: memory safe, no garbage collector, no first-party unsafe. And for people who do not write Rust, it ships as a native Python wheel via PyO3 — the surface that non-Rust users actually need. One codebase, one thing to audit. It is the same philosophy that guides the rest: where good cryptography exists, reuse it; simplicity is a security decision, not a convenience.

Installation

cargo add quipu              # Rust
pip install quipu-crypto     # Python (native wheel, PyO3)

Encrypt and decrypt in Python

import quipu

# Symmetric, with a passphrase
blob = quipu.encrypt_stream(b"sensitive data", "my-passphrase")
assert quipu.decrypt_stream(blob, "my-passphrase") == b"sensitive data"

# Post-quantum, for a recipient
pub, sec = quipu.generate_keypair()          # X25519 + ML-KEM-1024
c = quipu.encode_to_recipient(b"secret", pub)
assert quipu.decode_as_recipient(c, sec) == b"secret"

What is underneath

Encryption: XChaCha20-Poly1305 (authenticated AEAD).
Key derivation: Argon2id (brute-force resistant) + HKDF.
Post-quantum: X25519 + ML-KEM-1024 for keys; Ed25519 + ML-DSA-87 for signatures.
Security level: NIST category 5 (CNSA 2.0).

These are all standard, verified primitives — the ML-KEM-1024 and ML-DSA-87 known-answer tests run against NIST's official ACVP vectors. Quipu composes them; it does not invent its own cryptography.

Free and transparent

Quipu is open source (AGPL-3.0). You can read every line and audit the format, which is specified byte by byte. It is published on crates.io and, as a Python wheel, on PyPI.

Honest status: the composition has not yet passed an independent cryptographic audit. Until that external seal exists, treat it as software for review and experimentation, not for protecting real high-value secrets.

The code is at github.com/isazajuancarlos/quipu.

What is post-quantum cryptography, and why migrate now?

Juan Carlos Isaza — Sat, 29 Aug 2026 14:07:24 +0000

The cryptography protecting your data today — keys, HTTPS, signatures — rests on mathematical problems that current computers cannot solve in any reasonable time. A large enough quantum computer could solve some of them. That is what post-quantum cryptography is: algorithms designed to resist both classical and quantum computers.

The threat is not only in the future

You might think: "no quantum computer can break my encryption yet, so I can wait." The problem is an attack called harvest now, decrypt later:

An adversary captures your encrypted traffic today and stores it. Once quantum capability exists years from now, they decrypt it.

If your data must stay secret ten years from now — medical records, trade secrets, personal data — the threat is present, not future. What you encrypt today with classical cryptography could be read tomorrow.

The new NIST standards

NIST, the US standards body, finalised the first post-quantum algorithms in 2024 after years of public analysis:

ML-KEM (formerly CRYSTALS-Kyber): for key exchange — how two parties agree on a shared secret securely.
ML-DSA (formerly CRYSTALS-Dilithium): for digital signatures — how to verify a message is authentic and unaltered.

These are no longer academic experiments. They are standards that governments and large companies are starting to require.

Hybrid encryption: the prudent approach

Post-quantum algorithms are new, and "new" in cryptography means "less battle-tested". That is why current best practice is hybrid: combine a well-established classical algorithm with a post-quantum one. The result only breaks if both fall at once. You gain post-quantum protection without giving up decades of confidence in classical cryptography.

Where to start

Inventory where you use cryptography and which data must last years.
Prioritise long-lived data at rest — the most exposed to "harvest now".
Adopt hybrid encryption rather than wholesale replacement.
Use libraries that compose verified primitives, not home-made cryptography.

That last point is the key one, and it is the philosophy behind Quipu, a free hybrid post-quantum encryption library for data at rest.

The code is at github.com/isazajuancarlos/quipu. It is AGPL-3.0, and the composition has not yet passed an independent cryptographic audit — which is worth saying out loud.

Quipu: cifrado post-cuántico en Rust puro, con una rueda para Python

Juan Carlos Isaza — Mon, 24 Aug 2026 18:38:41 +0000

Proteger datos que deben seguir siendo secretos dentro de diez años es un problema de hoy: un adversario puede capturar tu tráfico cifrado ahora y descifrarlo cuando exista la capacidad cuántica (harvest now, decrypt later). Quipu es una librería libre de cifrado híbrido post-cuántico para datos en reposo: combina criptografía clásica probada con la nueva, de modo que solo se rompe si ambas caen a la vez.

Rust puro, y por qué

Quipu nació apuntando a varios lenguajes: un núcleo en Rust con una C ABI encima y bindings para Python, Node y Go. Funcionaba, pero la lección fue clara: mantener una interfaz de C estable más cuatro bindings, cada uno con su empaquetado y sus pruebas de interoperabilidad, era complejidad que no pagaba para el objetivo real —proteger datos en reposo— y ampliaba la superficie de ataque con unsafe que no queríamos.

Hoy Quipu es Rust puro: memoria segura, sin garbage collector, sin unsafe de primera parte. Y para quien no programa en Rust, se distribuye como rueda nativa de Python (vía PyO3) — que es la superficie que el cliente que no es de Rust de verdad necesita. Una sola base de código, una sola cosa que auditar. Es la misma filosofía que guía el resto: donde hay buena criptografía, se reutiliza; la simplicidad es una decisión de seguridad, no una comodidad.

Instalación

cargo add quipu              # Rust
pip install quipu-crypto     # Python (rueda nativa, PyO3)

Cifrar y descifrar en Python

import quipu

# Simétrico con contraseña
blob = quipu.encrypt_stream(b"datos sensibles", "mi-passphrase")
assert quipu.decrypt_stream(blob, "mi-passphrase") == b"datos sensibles"

# Post-cuántico para un destinatario
pub, sec = quipu.generate_keypair()          # X25519 + ML-KEM-1024
c = quipu.encode_to_recipient(b"secreto", pub)
assert quipu.decode_as_recipient(c, sec) == b"secreto"

Qué hay debajo

Cifrado: XChaCha20-Poly1305 (AEAD autenticado).
Derivación de claves: Argon2id (resistente a fuerza bruta) + HKDF.
Post-cuántico: X25519 + ML-KEM-1024 para claves; Ed25519 + ML-DSA-87 para firmas.
Nivel de seguridad: categoría NIST 5 (CNSA 2.0).

Todo son primitivas verificadas y estándar —los KAT de ML-KEM-1024 y ML-DSA-87 se comprueban contra los vectores oficiales del NIST (ACVP)—: Quipu las compone, no inventa criptografía propia.

Libre y transparente

Quipu es código abierto (AGPL-3.0). Puedes leer cada línea y auditar el formato, especificado byte a byte. Está publicado en crates.io y, como rueda de Python, en PyPI.

Estado honesto: la composición aún no ha pasado una auditoría criptográfica independiente; hasta ese sello externo, trátalo como software para revisión y experimentación, no para proteger secretos reales de alto valor.

Si necesitas proteger datos en reposo con visión post-cuántica y un formato auditable, hablemos.