blindrange

demos

Everything runnable, grouped by what you actually want to do: see whether it works, put real data in, or check the claims yourself — including the attacks we run against our own design.
# all of these assume the package and, optionally, the public network
git clone https://github.com/alviso/blindrange && cd blindrange
python3 -m venv .venv
.venv/bin/pip install --upgrade pip && .venv/bin/pip install -e .
# then run the demos with .venv/bin/python3. A venv is not politeness:
# most current Pythons refuse to install into the system one at all.

See whether it works

Sixty seconds, no account, nothing stored anywhere you care about.

Encrypted orders, three panels

One screen with your view, the network's view, and buttons that kill nodes while you query. The fastest way to understand what this is: the same rows are readable on the left and pseudorandom on the right, and killing a node changes neither.
The demo in two halves. Left: readable customer orders with
              amounts, dates and statuses, returned by a range query over
              amount and date. Right: the same data as a node operator sees
              it — opaque I: keys mapped to base64 blobs — above a list of
              eight live nodes each with a kill button.
python3 examples/webdemo/app.py   # → http://127.0.0.1:8600
202 rows in 39ms over eight nodes holding 62,517 keys · the node panel is what an operator actually gets

contrast.py

The same thing without a browser: prints what the owner reads beside what the network stores.
python3 examples/contrast.py

The live network running now

Three nodes across two continents, self-reported key counts next to proved possession, and each node's share of a distribution pool.
python3 examples/whos_here.py     # the same roster, from a terminal

Put real data in

These are the ones shaped like something you might actually run.

blindrange-audit — an audit trail its host cannot read

The workload where this design wins on the merits rather than as a privacy tax: append-only is what the index already is, and tamper-evidence falls out of per-record AEAD. Ships from Vector, Fluent Bit or the OpenTelemetry Collector with configuration alone — no plugin to write.
python3 examples/auditlog/audit.py --state ~/.blindrange/audit.brdb
# → http://127.0.0.1:8710
Deliberately has no delete route · full write-up

S3-compatible gateway

Point anything that already writes to S3 at storage that cannot read it — backup tools, compliance archivers, Loki, rclone. Verified against boto3 including multipart, prefix and delimiter listings, and SigV4.
python3 examples/s3gateway/gateway.py --state ~/.blindrange/s3.brdb
# → http://127.0.0.1:8720, path-style addressing
No range GETs, no versioning, buckets are implicit — the page lists every gap rather than failing mysteriously

Off-site backup with a searchable catalog

Plain boto3, no blindrange imports at all — it would work unchanged against AWS. It exists to show the gap: plain S3 gives you a catalog and a provider who reads everything; encrypting before upload takes the catalog with it. This keeps both, because a prefix listing is an index lookup over encrypted keys.
python3 examples/s3backup/backup.py backup ~/src --bucket work
python3 examples/s3backup/backup.py find work --name '*.py' --since 1h
python3 examples/s3backup/backup.py what-they-see work
Measured: 14 files restored byte-identical, diff -r clean — and the node holds neither the contents nor the filenames

The client app

Drop a CSV in, get a schema with an honest one-sentence description of what it leaks, then query it. For when you want your own data in without writing code.
blindrange init      # schema wizard
blindrange ui        # → http://127.0.0.1:8700

Check the claims

The part most projects don't ship. If the disclosures are only as good as our willingness to run the attacks, you should be able to run them too.

The attack harness

Runs the real attacks from the literature against our own design and prints the numbers — snapshot equality, frequency inference, and an ML query-watcher. It is how we know leaf_width bounds reconstruction by construction rather than by hope.
python3 prototype/attack.py
python3 prototype/bounded_demo.py   # the leaf-width bound, measured

verify_log.py checks us

We compute the payout shares, which makes us the one party you'd otherwise have to trust. This remembers the log's tree head and demands proof, next run, that nothing already published has changed. Tested by actually cheating: rewriting a past share from 333 to 900 is rejected.
python3 examples/verify_log.py
  consistent with the 2 entries seen previously  ✓  (1 new)

Benchmarks

Ingest and delete, run against the real public network rather than localhost — which is where every interesting bug turned up.
python3 examples/bench_logs.py --records 100000
python3 examples/bench_delete.py --state my.brdb
What none of these are. This is a research prototype on a demo network with no durability promises. Run your own nodes for anything you would mind losing, and read the threat model first — it is explicit that this is not for healthcare or high-stakes PII, and why.
blindrange.dev · build on it · audit log · live network · source