Introducing Shorenet Research

Digital evidence is asked to carry a great deal of weight, and it is usually asked to carry it on trust. A screenshot, an export, a report from a tool: each is offered as a record of what happened, and each ultimately rests on the credibility of whoever produced it. That is a weak place for evidence to stand, and it gets weaker as the cost of producing convincing fabrications falls.

Shorenet exists to move that weight off the operator and onto something checkable. This section is where we explain how, in enough detail that a reader can disagree with us.

What this is

Shorenet Research is a place for method notes and technical write-ups: how evidential capture is constructed, what each link in the proof chain actually establishes, which parts are cryptography and which parts are engineering assurance, and where the boundaries of the claim sit. It is intended for forensic examiners, expert witnesses, counsel who have to cross-examine this kind of material, and engineers who want to check the reasoning rather than accept a summary.

It is deliberately not a product blog. There will be no release notes, no feature announcements and no customer stories here. Those belong elsewhere. What belongs here is the reasoning we would have to defend in front of someone whose job is to find the hole in it.

The standard these pages are held to

A single rule governs everything published in this section: state the boundary before opposing counsel does.

A proof chain is only as useful as the honesty of the claim attached to it. Cryptography can establish that a set of bytes is the set of bytes that was captured, unmodified, at a given time. It cannot establish that our interpretation of those bytes is the right one, because interpretation is not a cryptographic operation. Those are two different kinds of assurance, they fail in different ways, and conflating them is the fastest route to an exhibit that does not survive contact with a competent challenge.

So where something is proved, we will say what is proved and by what. Where something is engineering assurance earned through testing, differential validation against independent implementations, and refusing to produce output we cannot stand behind, we will say that instead. Where a capability is a design target rather than something shipping today, it will be labelled as a target. We would rather publish a narrower claim that holds than a broader one that has to be walked back under questioning.

What will appear here

Expect write-ups on the structure of the proof chain and what each gate establishes; on why the decrypted plaintext, not our rendering of it, is the evidence of record; on failing closed as an evidential discipline rather than a reliability feature; and on the testing methodology that reconstruction faithfulness depends on. Expect also, in time, notes on things we got wrong and corrected, because a method that has never published a correction is a method nobody has checked.

These pages are versioned and revised in place rather than reissued, so a citation to a URL or to a section anchor stays valid. Every substantive change is recorded in the revision history at the foot of the page.

If you think an argument here is wrong, we would like to know. Challenges from practitioners who would have to defend this method in a hearing are the most useful thing we can receive.