bigpickle/sigil
0
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Harden Sigil: DESIGN.md

Browse Source
This commit is contained in:
bigpickle 2026-10-05 21:24:28 +08:00 committed by leora
parent 5e1db8afcd
commit bcd89a5db1
1 changed files with 36 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
DESIGN.md
View File

@ -152,23 +152,49 @@ it needs a human identity model of its own, which is a separate piece of work.
## Audit trail ## Audit trail
Append-only, and the raw material for signed work attestations: every Hash-chained, and the raw material for signed work attestations: every
enrolment, challenge, verification, code issuance, redemption, refusal and enrolment, challenge, verification, code issuance, redemption, refusal and
revocation, with actor, subject and key fingerprint. Code hashes are stored, revocation, with actor, subject and key fingerprint.
never codes; enrolment secrets are hashed and deleted on use, so a database
leak yields neither. Each row folds in the previous row's digest, so editing or deleting an event
breaks every digest after it, and `verify_chain` reports the first bad id. That
makes tampering *detectable*. It does not make it *impossible*: an attacker with
write access to the database can recompute the chain, because the digests are
unkeyed. To commit to a log you need the head digest anchored outside the
database's reach, or signed. Worth doing when the attestations start mattering,
not before.
Secrets are not in the log and not in the database in the clear. Codes and
session tokens are stored as digests, enrolment secrets are hashed and spent
once. So a stolen database yields no live credential — which is only true
because the review looked for it.
## Status ## Status
Working reference implementation with 54 passing tests. **Not production ready, 80 passing tests, and a hardening pass that closed real defects. The worst were
and not reviewed.** Specifically missing: independent cryptographic review, concurrency: one-time codes were redeemable repeatedly (753 sessions from 200
encryption at rest, rate limiting on challenge issuance, agent revocation codes under load), and a bootstrap secret could enrol more than one key. Those
expiry, and transport assumptions. The tests show the logic is correct; they do are now atomic compare-and-set operations, each covered by a test that races
not make it safe. twelve threads. Session tokens are stored hashed, keys can be encrypted,
challenge issuance is rate limited, rekey revokes old sessions, and the log is
hash-chained.
**Still not production ready**, and the reason is not a to-do list:
- **No independent review.** Everything above is self-review. Self-review finds
the bugs you already suspected. This needs someone else.
- **The chain is unkeyed** — detectable, not tamper-proof (see *Audit trail*).
- **The service is unwritten.** TLS, CSRF, transport, secret storage, routes.
- **Revocation has no expiry semantics**, and there is no key recovery.
- **Humans remain unattributable** to themselves, which is accepted and is a
cost, not an oversight.
The tests show the logic is correct. They do not make it safe.
## Next ## Next
1. Independent security review before this guards anything real. 1. Independent security review before this guards anything real. The hardening
pass made it reviewable; it did not substitute for one.
2. Secret broker on top — scoped, short-lived leases bound to a key fingerprint. 2. Secret broker on top — scoped, short-lived leases bound to a key fingerprint.
Its issuance and redemption logs *are* the work-attestation substrate, so it Its issuance and redemption logs *are* the work-attestation substrate, so it
is the natural second piece. is the natural second piece.