(04) Notes
Notes, working ones.
These are working notes on how software claims become inspectable: through interfaces, tests, release evidence, operational limits, and the choices behind shipped systems. If you only read one, start with the one on constant-time claims.
-
Sharing code is not the same decision as sharing a package
The reflexive move when two things share code is to extract it into its own package. That's the wrong test. The right one is a trigger, decided and named bef... Read →
-
A constant-time claim is a trust problem, not a comprehension problem
Explaining constant-time execution is the easy part, and it isn't what a skeptical reader needs. What transfers warrant is a leak detector that must fail on ... Read →
-
Skipping the releases that change nothing
A published version is a promise about bytes, not a diary of work. Here's why some of gm-crypto-rs's hardest cycles were never published at all. Read →
-
Keeping unsafe out of the default build
The fast paths needed unsafe. Rather than let them into the core, they live in a crate you opt into — so the core keeps unsafe_code = "forbid". Read →
-
Conformance is byte-identity, or it's nothing
Crypto tests don't ask whether the output looks right. They ask whether it's the same bytes as a reference under the same mode semantics — the subtle half. Read →
-
Catching constant-time regressions in CI
Constant-time is easy to satisfy once and lose without noticing. Here's the CI tripwire that fails the build when a leak creeps back — a detector, not a proof. Read →
-
Starting a notebook
A public engineering notebook earns its keep when each note carries one useful claim, a concrete decision, and enough evidence that a skeptical reader can ve... Read →