Files
Shade/docs/archive/V3.12.md
Sterister e6fdf31b49
Some checks failed
Test / test (push) Has been cancelled
Cross-platform vectors / TypeScript vectors (bun) (push) Has been cancelled
Cross-platform vectors / Kotlin vectors (gradle) (push) Has been cancelled
Docker build and publish / docker (push) Has been cancelled
Publish / publish (push) Has been cancelled
release(v4.0.0): Shade GA — V3.x consolidation + audit prep
V3.1 → V3.12 consolidated and tagged for the first GA release. Wire
format unchanged from 0.4.x — 4.0 peers interoperate with 0.4.x peers
byte-for-byte. The version bump is semantic: audit-cycle complete,
opt-in surface fully exposed, threat model refreshed for every new
surface.

Highlights:
- All 24 @shade/* packages bumped to 4.0.0 in lockstep.
- CHANGELOG 4.0.0 section is the canonical manifest of what landed.
- THREAT-MODEL extended (§10 fingerprint gates, §11 WebRTC P2P, §12
  Web-Worker boundary) + residual-risks table refreshed.
- OpenAPI now covers all 27 routes: prekey, transfer, KT, inbox,
  bridge, observer, /metrics, /healthz, /ready.
- MIGRATION 0.3.x → 4.0 documented + smoke-tested against
  shade migrate-storage on a real SQLite DB.
- docs/audit/REVIEW-BUNDLE.md + SCOPE.md ready for external reviewer.
- scripts/soak.ts harness for the GA-stable 2-week soak window.
- All V*.md plans archived under docs/archive/ with Status: Done.
- Voice/Video carved out into V5.0; 4.0 audit focuses on the frozen
  non-realtime stack.

Tests: TS 1000/1000 + Kotlin 11/11 cross-platform vectors green.
Docker: gt.zyon.no/stian/shade-prekey:4.0.0 builds and reports
  version 4.0.0 on /health.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 18:35:35 +02:00

3.3 KiB

Shade V3.12 — Key Transparency

Status: Done (0.4.0). Designnotat: docs/V3.12-DESIGN.md. Operatør-/recovery-guide: docs/key-transparency.md. Effort: XXL (4+ måneder, multi-quarter) Forrige: V3.5 (hovedplattformene stabile først) Adresserer: V2.3 §1A


Mål

Reduser tillit til prekey-server fra "blind tillit" til "verifiserbar log". Når serveren utleverer et bundle, skal det være kryptografisk forpliktet i en append-only log som klienter (eller tredjeparts-auditors) kan verifisere. Et split-view-angrep der serveren viser ulike bundles til ulike klienter blir fanget av gossip.


Pre-requisite: designnotat

Ingen kode før dette er review'd og approved:

  • Trusselmodell-tillegg: hva CT/attest faktisk løser, hva som forblir åpent.
  • Datastruktur-valg: append-only Merkle log (CT-stil), CONIKS-tre, eller hybrid.
  • Friskhetsbevis: hvor ofte signed tree heads utgis; hva er "stale"?
  • Klient-verifikasjonssteg: må klient verifisere på hver bundle-fetch, eller probabilistisk?
  • Witness/auditor-rolle: hvem kjører dem? Hvordan gossip mellom klienter?
  • Operatørkost: log-størrelse, signing-frekvens, backup-strategi.
  • Migrasjon: eksisterende prekey-server → log-utvidet.

Designnotatet er en docs/V3.12-DESIGN.md-PR som må review'es av minst én ekstern crypto-orientert reviewer.


Mulig scope (etter designnotat)

Inn (estimat)

  • Append-only log som tillegg til prekey-server.
  • Inklusjons-bevis ved bundle-fetch (Merkle-path).
  • Fravær-bevis for "denne adressen har ikke registrert siden timestamp T".
  • Signed tree heads (STH) publisert på fast interval.
  • Klient-bibliotek: @shade/key-transparency med verifisering.
  • Witness-API: tredjeparts-auditor kan hente STH-er og logge gossip.

Ut (eksplisitt)

  • Federated log (multi-server gossip) — for stort for første iterasjon.
  • Legal/compliance-side av audit-log.
  • "Vi løser MITM-på-første-kontakt-helt" — KT alene fanger split-view, ikke første-kontakt.

Risiko-vurdering

KT er det vanskeligste enkeltpunkt i hele roadmapen:

  1. Halvveis-implementert KT er verre enn ingen KT — gir falsk trygghet, brukere slutter å verifisere OOB.
  2. Operativt komplekst — log må aldri skrive om historie. En enkelt restart-bug = ødelagt integritet.
  3. Klient-verifikasjons-logikk må kjøre på hver bundle-fetch, eller risikere at én "gammel" klient blir lurt.
  4. Witness-økosystem krever uavhengige aktører — Shade alene kan ikke garantere det.

Beslutningskriterium: Hvis designnotatet etterlater åpne "hvordan håndterer vi X?"-spørsmål uten klare svar, parker V3.12. Pragmatisk alternativ er V3.3 (fingerprint-gate) + V3.10 (social recovery) — som sammen gir 80 % av MITM-beskyttelsen uten KT-kompleksiteten.


Akseptansekriterier (hvis det implementeres)

  • Designnotat passert ekstern review.
  • Klient detekterer split-view i ende-til-ende-test (server gir to versjoner av samme adresse → klient fanger mismatch).
  • Witness-API testet med minst én ekstern auditor-instans.
  • Operatør-doc dekker recovery hvis log korrumperer.

Avhengigheter

  • V3.5 — Android/TS paritet må være solid før vi legger på et nytt verifikasjons-lag.

Migrasjon

Helt opt-in. Operatører som ikke ønsker KT kjører videre uendret.