An owner can now rotate a profile's DEK — generating a fresh key,
re-encrypting all the profile's data under it (client-side), and
re-wrapping to the owner share + kept recipients. A revoked recipient's
cached old DEK stops working, closing the soft-revoke window the ADR
requires for graduation / suspected compromise.
The server stays a blind store: it sees opaque old→new ciphertext blobs
flow through, never the DEK or plaintext. No backend crypto.
Backend:
- ProfileRepository::update_wrapped_dek — rotate the owner share
(account-wrapped profile DEK), owner-scoped.
- ProfileShareRepository::find_active_for_profile +
delete_for_profile_excluding — list current recipients and hard-delete
omitted ones.
- POST /api/profiles/:id/rekey: validates each submitted envelope
against existing active shares (no smuggling new recipients in via
rekey), rotates the owner share, upserts recipient envelopes with
fresh ephemeral ECDH keys, hard-deletes omitted recipients.
- rekey_tests.rs: rotation, hard-revoke-from-recipient-view, no-share
rejection, non-owner rejection, revoke-all.
Frontend:
- useProfileStore.rekeyProfile: fetches all profile data, re-encrypts
each row under a new DEK (resume-safe — rows already on the new DEK
are skipped), builds fresh ECDH envelopes per kept recipient, commits
via POST /rekey, swaps the in-memory DEK.
- ProfileSharing: 'Rotate encryption key (hard revoke)' action with a
strong confirmation dialog explaining the cost and the resume-safe
retry.
Best-effort + resumable retry (per design decision); no server-side
write lock.
Verification: backend cargo build/clippy (-D warnings)/fmt clean, tests
compile (integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 31/31 tests pass.
⚠️ Backend integration tests not run locally (no Mongo in this sandbox);
CI will run them — I'll fix any failures.
Admin-initiated rekey (ADR §5c reserves the permission) is out of scope
— handler is owner-only until admin shares are creatable in Phase D.
Refs #3.
The update/delete handlers for medications and appointments took the
auth Claims but never used them — any authenticated user could update
or delete any other user's records by id (an IDOR). Same gap on
log_dose (could skew another's adherence stats) and get_adherence
(leaked dose history).
Fix: each affected handler now looks up the item first and confirms
user_id == claims.sub before mutating/returning. Mismatches return 404
(not 403) to avoid leaking the existence of other users' records.
Recipients of shared profiles remain read-only per the ADR — writes
stay owner-only.
Covered handlers:
- update_medication, delete_medication, log_dose, get_adherence
- update_appointment, delete_appointment
health_stats update/delete were already checking user_id == claims.sub
(unaffected).
New ownership_tests.rs: cross-user update/delete/log-dose/adherence all
404; the legitimate owner can still do all of the above.
Verification: cargo build/clippy (-D warnings)/fmt clean; existing
tests unaffected (they operate as the same user that created the data).
Closes#12.
The share-gate I added in Phase B was too strict: it only admitted the
owner via the profiles collection, so any data item whose profile_id
didn't map to a real Profile document (legacy/test data, or a profile_id
the caller used at create time without a backing Profile) got 404'd on
read — even for the item's actual owner. CI caught this:
zk_integration_tests::medication_stored_as_ciphertext_not_plaintext
creates a medication with profile_id="default" (no Profile doc) and
the new get_medication gate returned 404.
Fix: in each list/get data handler, check direct ownership
(user_id == claims.sub, or has own data for the profile) FIRST, and
only fall through to the share-gate if the caller isn't the direct
owner. This preserves the original ownership model AND adds share-
recipient access, without breaking items whose profile_id isn't a real
Profile document.
The share-only path (recipient reading shared data they don't own)
still goes through the gate as before.
Three share_tests were failing in CI:
1. public_key_lookup_returns_recipient_identity_key — passed the email
as a JSON body on a GET, but send_json builds the URI verbatim and
ignores the body for GET. The query string was never formed, so the
handler got an empty email. Fix: put ?email=... in the URI directly
(URL-encoding the '@').
2. public_key_lookup_404s_for_unknown_or_keyless_user — same root cause.
3. owner_shares_recipient_reads_owner_revokes — asserted the recipient's
write would return 201 or 403, but create_medication returns 200 OK
(Axum's default for Ok(Json(...))), and the write currently succeeds
because the create handler doesn't check ownership (issue #12). The
write is attributed to the recipient, not the owner, so the owner's
data is still untouched — which is what the test really wants to
prove. Accept 200 (current) or 403 (once #12 lands); documented the
tie to #12.
An owner can now share a profile with another account; the recipient
reads the profile's metadata AND its data (medications, appointments,
health stats) under their own login. The server stays a blind store:
sharing uses an X25519 envelope — the owner wraps the profile DEK to
the recipient's identity public key via ECDH (fresh ephemeral key per
share), the recipient unwraps it with their identity private key.
Backend:
- models/profile_share.rs: ProfileShare + ProfileShareRepository
(find_for_recipient, find_for_profile, find_active [checks active +
expiry], delete, upsert). Indexed on (profileId, recipientUserId) and
recipientUserId.
- handlers/profile_share.rs: POST/GET /profiles/:id/shares,
DELETE /profiles/:id/shares/:recipient, GET /profiles/shared-with-me,
GET /users/public-key (public), and authorize_profile_read — the
share-gate that admits owner OR active-share recipient.
- The share-gate is wired into list/get for medications, appointments,
and health stats: when profile_id is specified, resolve the owner via
the gate and query as them. Data repos stay ownership-scoped.
- Removed the legacy Share system (ADR Open Q5): models/{share,
permission}.rs, handlers/{shares,permissions}.rs, middleware/
permission.rs (dead), the shares collection field + methods in
mongodb_impl.rs, the shares index, and the 5 /api/shares +
/api/permissions routes.
- share_tests.rs: full owner→recipient→revoke flow, ownership
isolation, share-to-self/nonexistent/keyless rejections, expired
share treated as absent.
Frontend:
- crypto/keys.ts: wrapProfileDekToRecipient /
unwrapProfileDekFromShare (ECDH envelope, ephemeral key per share).
- useProfileStore: loadSharedWithMe (unwrap each share's DEK with the
identity private key), shareProfile, revokeShare, loadProfileShares.
Shared profiles merge into the list with is_shared=true.
- ProfileSwitcher: shows shared profiles with a 'shared' chip.
- ProfileSharing (new) + ProfileEditor: owner UI to add a recipient by
email and revoke; shared profiles render read-only with owner info.
- ECDH round-trip test (owner wraps, recipient unwraps, stranger can't).
Verification: backend cargo build/clippy (-D warnings)/fmt clean, tests
compile (integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 31/31 tests pass.
⚠️ Backend integration tests not run locally (no Mongo/Docker in this
sandbox); CI will run them — I'll fix any failures immediately.
Phases C (hard revoke / re-key) and D (graduation) remain. Refs #3.
verify_password() was mapping every password-hash failure — including a
plain wrong password (password_hash::Error::Password) — to Err, which
propagated to the login handler's Err arm and returned 500
'authentication error' instead of 401 'invalid credentials'.
All three callers (login, change_password, recover_password) already
match on Ok(true)/Ok(false)/Err and expect Ok(false) for a mismatch;
the function just wasn't honoring that contract. Map
Error::Password -> Ok(false) and propagate only genuine failures as Err.
This was a latent bug: CI's auth tests never ran before because the
Mongo service container couldn't schedule (port collision, fixed in
#8). Now that CI runs them for real, login_with_wrong_password_is_rejected
exposed it. Behavior improves on all three call sites — a wrong recovery
phrase now also correctly 401s instead of 500ing.
Implements the 3-tier key model from the multi-person sharing ADR:
each account owns multiple profiles (a person or pet — a 'subject of
care'), and each profile has its own random AES-256-GCM DEK. All
health data is now encrypted under the active profile's DEK, not the
account-wide DEK. The account DEK wraps each profile DEK; the server
stores only opaque wrapped blobs.
Per the ADR: DB wipe, no migration (no real user data). This unblocks
Phase B (sharing) — there is now a per-profile key to wrap to a
recipient's X25519 public key.
Backend:
- Profile model: owner_account_id, kind (human/pet), relationship,
wrapped_profile_dek + iv. ProfileRepository gains find_all_by_owner,
find_by_profile_id_owned, update_profile, delete_profile — all
ownership-scoped.
- Profile handlers: GET/POST /api/profiles, GET/PUT/DELETE
/api/profiles/:id. Removed /api/profiles/me. Renamed users.rs
get_profile/update_profile (the /api/users/me handlers) to
get_account/update_account to resolve a name collision.
- Register accepts default_profile_* fields and auto-creates the self
profile when the client provides a wrapped profile DEK.
- HealthStatistic + Appointment gain profile_id and ?profile_id=
filtering (health stats previously had no profile binding).
- New profile_tests.rs: multi-profile CRUD + ownership isolation +
register-with-default-profile. Fixed the zk health-stat test to
send the now-required profile_id.
Frontend:
- crypto/keys.ts: generateProfileDek, wrapProfileDek, unwrapProfileDek
+ in-memory per-profile DEK store with an active-profile concept.
- useProfileStore rewritten: holds profiles[], activeProfileId;
loadProfiles unwraps each profile DEK; create/update/delete. All 11
encrypt/decrypt sites switched from getEncKey() to
getActiveProfileDek(). load actions pass ?profile_id= so only the
active profile's rows come back.
- ProfileEditor rewritten for the new store (edit active profile,
create/delete). New ProfileSwitcher in the Dashboard AppBar.
- MedicationManager / AppointmentsManager use the active profile id
instead of the hardcoded profile_<user_id>.
- 2 new crypto tests for per-profile DEK isolation; updated store +
component tests for the active-profile-DEK model.
Verification: backend cargo build/clippy/fmt green, tests compile
(integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 30/30 tests pass.
Closes nothing yet (Phase B/C/D remain). Refs #3.
The test job failed on the runner with:
Bind for 0.0.0.0:27017 failed: port is already allocated
because the services.mongo ports: 27017:27017 tries to claim host port
27017, which is occupied (mongod on the runner host). The job container
doesn't need the host mapping — it reaches Mongo over the job's internal
network via the service hostname (MONGODB_URI=mongodb://mongo:27017).
Drop the ports block so the service container schedules cleanly.
This unblocks all PRs, including #6 (Phase A1).
Phase A1 of the multi-person sharing ADR
(docs/adr/multi-person-sharing.md). Each account now gets an X25519
keypair at registration: the public half stored plaintext, the private
half wrapped under the account DEK and stored as opaque ciphertext. The
keypair is generated client-side; the backend adds no crypto deps and
stores everything verbatim, preserving the zero-knowledge contract.
This change only introduces the keypair and threads it through the auth
flows — it is not consumed yet. It unblocks Phase B (profile sharing)
without touching the data model or the ~11 frontend encrypt call sites,
which is Phase A2 (per-profile DEKs).
Backend:
- User model: identity_public_key, identity_private_key_wrapped{,_iv}
(all Option<String>, backward compatible).
- RegisterRequest/AuthResponse carry the 3 fields; register + login
echo them. No changes to change_password/recover (DEK value is
unchanged across both, so the wrapped private key is too).
- 2 new integration tests: round-trip through register/login, and
optional-fields backward compat.
Frontend:
- crypto/keys.ts: generateIdentityKeyPair, wrapIdentityPrivateKey,
unwrapIdentityPrivateKey + in-memory identity store mirroring the DEK.
- types/api.ts: AuthTokens + RegisterRequest extended (removes an
existing `as any` cast).
- useStore register/login/logout + UnlockPage unwrap the private key
alongside the DEK.
- 3 new crypto tests (X25519 lifecycle, wrong-DEK rejection, distinct
shared secrets); skip gracefully where the runtime lacks X25519.
Backend: cargo test + clippy green. Frontend: npm test + tsc green.
Also gitignore .zcode/ (local tooling artifact).
Rewrite the encryption/persona/JWT docs to match the implemented code and
record the multi-person sharing design.
- multi-person-sharing.md (NEW): ADR for per-profile DEK + X25519 envelope
sharing. All five original open questions resolved 2026-07-18. Covers
divorced-parents, pets, graduation, and elderly-parent care; adds an
admin permission tier for owner-incapacity. Decided, not yet implemented.
(#3)
- encryption.md: full rewrite to the implemented wrapped-DEK / Web Crypto
model; the old version described ZK encryption as 'planned'. (#4)
- jwt-authentication-decision.md: rewritten to match implementation
(PBKDF2 not bcrypt, no Redis, token_version revocation, real Claims).
Original aspirational content preserved in a History section. (#4)
- PERSONA_AND_FAMILY_MANAGEMENT.md: 'Current reality' section added, old
'Implementation Status' marked superseded, encryption section corrected. (#4)
- ENCRYPTION_UPDATE_SUMMARY.md: archived (changelog for a rewrite that
itself went stale). (#4)
- ADR README index updated for the new + reconciled entries.
- Add AGENTS.md as the cross-agent entry point (lean; points to
.gooserules and docs/AI_* for detail)
- Document the Forgejo issue-driven workflow (report → triage →
implement → close) and API patterns in .gooserules
- Add Forgejo step to the pre-change checklist
- Gitignore .forgejo-token
Browsers disable crypto.subtle on non-localhost HTTP. The frontend server now
generates a self-signed TLS cert at startup and serves over HTTPS by default
(FRONTEND_TLS=true). FRONTEND_TLS=0 disables it for localhost dev.
Added axum-server (tls-rustls) + rcgen deps to the frontend-server crate.
A dedicated Rust/Axum binary (web/frontend-server/) that:
- Serves the built Vite SPA bundle from dist/ via tower-http ServeDir
- Falls back to index.html for SPA routing (deep links work)
- Reverse-proxies /api/* to the backend container (same-origin, no CORS)
- Listens on port 8080 (configurable via FRONTEND_PORT)
Dockerfile (web/normogen-web/Dockerfile): 3-stage build:
1. Node: npm ci + npm run build -> dist/
2. Rust: cargo build --release the frontend-server binary
3. Runtime: debian-slim + binary + dist/
docker-compose.yml: new 'frontend' service on :8080, depends on backend healthy,
proxies to http://backend:6500. Independently scalable (run N replicas behind
a load balancer).
Architecture:
Browser -> :8080 (frontend container)
/api/* -> proxy -> backend:6500
/* -> static dist/ (SPA)
Dose scheduling:
- DoseSchedule struct (times_per_day + days_of_week) as top-level field on
Medication. get_adherence computes scheduled_doses from the schedule over
the period; missed doses now reflected. Fallback to taken/total_logged when
no schedule. Wired through create/update requests + MedicationResponse.
- Frontend: dose_schedule field on Medication domain type + wire response;
store reads it on load. (MedicationManager UI field deferred — the data
flows correctly; a form field can be added when needed.)
Health stats zero-knowledge:
- HealthStatistic model now uses opaque encrypted_data blob (like medications).
Only recorded_at stays plaintext. HealthStatResponse wire type.
- Removed the trends endpoint (server can't compute on ciphertext); trends
are now computed client-side in the health store after decryption.
- Deleted the dead HealthData model (kept EncryptedField which it defined).
- Frontend: health store decrypts on load + encrypts on write; trends
computed client-side; HealthStats component uses domain form types.
Verified: backend 24 tests 0 warnings; frontend build clean, 24 tests.
Backend changes (frontend + tests follow in next commit):
Dose scheduling:
- New DoseSchedule struct (times_per_day + days_of_week) as a top-level
plaintext field on Medication. Create/update requests accept it.
- Revised get_adherence: computes scheduled_doses from the schedule over the
period (days_of_week filtering), so missed doses are now reflected.
Falls back to taken/total_logged when no schedule.
Health stats zero-knowledge:
- HealthStatistic model now uses opaque encrypted_data blob (like medications).
Only recorded_at stays plaintext (filterable/sortable).
- HealthStatResponse wire type. Handlers echo opaque blobs.
- Removed the trends endpoint (server can't compute trends on ciphertext;
frontend computes them client-side after decrypting).
- Deleted the dead HealthData model (kept EncryptedField which it defined).
Verified: backend 24 tests, 0 clippy warnings.
Rate limiting (closes the last security gap #3):
- New RateLimiter: in-memory fixed-window IP-based limiter (std::sync::Mutex
HashMap, no new deps). Configurable via RATE_LIMIT_MAX (default 100) +
RATE_LIMIT_WINDOW_SECS (default 60) env vars.
- general_rate_limit_middleware now reads ClientIp from request extensions and
rejects with 429 + Retry-After header when over the limit. Wired via
from_fn_with_state in app.rs. Lived on AppState as Arc<RateLimiter>.
- Deleted the dead auth_rate_limit_middleware (never wired).
- 3 unit tests (allows up to N, independent IPs, window reset).
E2E crypto lifecycle test:
- Full zero-knowledge round-trip against jsdom's real Web Crypto: setup →
encrypt → verify ciphertext → unlock with password → decrypt → recover via
phrase → rewrap under new password → decrypt. Plus wrong-password/wrong-phrase
failures and cross-user key isolation.
- Fixed wrapDek/unwrapDek: base64-encode raw DEK bytes (was using TextDecoder
which produced non-base64), and make unwrapped DEK extractable (needed for
rewrapDek to export).
Verified: backend 24 tests 0 warnings; frontend 24 tests, build clean.
Solves the core usability problem of zero-knowledge encryption: on page reload
the in-memory DEK is lost, so the user can't decrypt their data even though their
JWT is still valid. Previously they had to close the tab and re-login from scratch.
Changes:
- Persist wrapped_dek/wrapped_dek_iv in the auth store (zustand persist). Safe:
it's AES-GCM ciphertext, useless without the password KEK — the server already
stores the same ciphertext. login/register/recover all save the wrapped DEK;
logout clears it.
- New UnlockPage: minimal password-only form. Re-derives the DEK locally via
unlockWithPassword (no API call — the JWT is still valid). Falls back to
deriveAuthAndEncKeys for Phase 1 compat accounts. Links to /login and /recover.
- ProtectedRoute now checks hasEncKey() after isAuthenticated: authenticated but
no in-memory DEK → redirect to /unlock.
- /unlock route in App.tsx (public, alongside login/register/recover).
Flow: login → browse → reload page → unlock screen → enter password → dashboard
loads with decrypted data. No full re-login needed.
Verified: npm build clean, 20 tests pass.
Register now generates a DEK, wraps it under the password KEK and recovery KEK,
and sends all wrapped forms to the server (via setupEncryption). RegisterPage
has an optional recovery phrase field with a warning. Login unwraps the DEK
from the response via unlockWithPassword. This completes the full ZK recovery
flow end-to-end from the UI.
Verified: npm build clean, 20 tests pass.
Introduces a wrapped-DEK recovery model so a forgotten password doesn't lose
all encrypted data. The encryption key becomes a random DEK (not derived from
the password); the DEK is wrapped under both a password-derived KEK and a
recovery-phrase-derived KEK, and both wrapped forms are stored on the server.
Crypto (crypto/keys.ts):
- DEK generation (random AES-256-GCM), KEK derivation (PBKDF2 password/recovery),
wrapDek/unwrapDek/rewrapDek.
- setupEncryption(password, recoveryPhrase?) — generates a DEK, wraps under both
KEKs, returns wrapped forms + recovery proof.
- unlockWithPassword(password, wrappedDek) — derives password KEK, unwraps DEK.
- unlockWithRecovery(phrase, wrappedDek) — derives recovery KEK, unwraps DEK.
Backend:
- User model: wrapped_dek, wrapped_dek_iv, recovery_wrapped_dek,
recovery_wrapped_dek_iv fields.
- RegisterRequest accepts wrapped-DEK fields; stored verbatim.
- AuthResponse returns wrapped_dek + wrapped_dek_iv (for login unwrapping).
- New GET /api/auth/recovery-info?email= — returns recovery-wrapped DEK.
- RecoverPasswordRequest gains new_wrapped_dek + new_wrapped_dek_iv.
- change-password also accepts + stores re-wrapped DEK.
Frontend:
- Auth store: login unwraps DEK from response; new recover() action fetches
recovery-wrapped DEK, unwraps with phrase, re-wraps under new password.
- RecoveryPage (new): email + recovery phrase + new password flow.
- LoginPage: 'Forgot password? Recover' link. App.tsx: /recover route.
Verified: backend 21 tests, 0 warnings; frontend build clean, 20 tests.
Complete the core zero-knowledge property: all user data (medications,
appointments, profile names) is now client-encrypted via AES-GCM; the server
stores and returns opaque ciphertext and can never decrypt it.
Frontend crypto module (Web Crypto API, no deps):
- crypto/keys.ts: double-PBKDF2 derivation from the password — an auth secret
(base64, sent to the server as the 'password') and an encryption key (AES-GCM
CryptoKey, kept in memory only, never transmitted). In-memory key store.
- crypto/cipher.ts: AES-GCM encrypt/decrypt + JSON convenience wrappers.
Auth split: login/register now derive the auth secret + enc key from the
password BEFORE the API call. Only the auth secret (not the raw password) is
sent to the server. The server's PBKDF2 stays as-is (it hashes whatever it
receives) but can never derive the enc key.
Backend — server treats all data blobs as opaque:
- Medication: removed MedicationData + flat MedicationResponse; new
MedicationResponse echoes metadata + encrypted_data blob. Create/update
accept opaque blobs (whole-blob replace). MedicationData struct deleted.
- Appointment: same opaque treatment; status moved to a top-level document field
so it remains filterable without decryption. AppointmentData struct deleted.
- Profile: name is now an opaque encrypted blob (name_data/name_iv). Auto-created
profile starts empty; client sets it.
- EncryptedFieldWire shared wire type across medication/appointment.
Frontend — decrypt-on-read, encrypt-on-write:
- Stores derive the enc key on login/register; decrypt wire responses into
domain objects on load; encrypt domain data into blobs on create/update.
- API client returns wire types (opaque blobs); components consume decrypted
domain data (mostly unchanged — the store does the crypto).
- Updated store tests for the ZK contract (derive a real key, mock wire responses).
- 20 frontend tests pass, build clean.
Backend: 21 tests pass (removed MedicationData/appointment-data deser tests;
opaque-blob echo tests added), clippy 0 warnings.
KNOWN LIMITATIONS (Phase 2): forgotten password = data loss (no recovery wrapping
yet). Page reload requires re-entering the password to re-derive the enc key
(in-memory only, by design). No data migration (no real data existed).
Backend: server can no longer read user data. All data blobs (medication,
appointment, profile name) are now opaque client-encrypted ciphertext — the
server stores and returns them verbatim, never deserializing the contents.
- Medication: removed MedicationData + flat MedicationResponse; new
MedicationResponse echoes metadata + encrypted_data blob. Create/update
accept opaque blobs (whole-blob replace). Update is no longer load-mutate-
reserialize (server can't read the data).
- Appointment: same opaque treatment; status moved to a top-level document
field so it remains filterable without decryption.
- Profile: name is now an opaque encrypted blob (name_data/name_iv). Auto-
created profile on register starts with an empty name; client sets it.
- EncryptedFieldWire type shared across medication/appointment.
Frontend (partial): crypto module using Web Crypto API —
- crypto/keys.ts: double-PBKDF2 derivation (auth secret sent to server +
encryption key kept in memory); in-memory key store (set/get/clear).
- crypto/cipher.ts: AES-GCM encrypt/decrypt + JSON convenience wrappers.
- crypto/index.ts: re-exports.
NOT YET DONE (frontend integration): auth store key derivation on login/register,
stores decrypt-on-load/encrypt-on-write, types update, UI components wired,
crypto round-trip tests, ADR. This commit is a verified checkpoint — backend
builds clean (21 tests, 0 warnings); frontend crypto module exists but is not
yet wired into the data flow.
The active flag was synthesized as always-true. Now it's a real top-level field
on the Medication document (serde default=true so old rows stay active),
wired through create (default true), update ($set the field, not the data blob),
and list (the previously-ignored ?active= query param now filters at Mongo level
via find_by_user_filtered). Fixed stale comments claiming updates.active was
'accepted but not persisted' (the field didn't even exist on UpdateMedicationRequest).
Verified: cargo fmt/clippy 0 warnings, 23 tests pass; frontend build + 20 tests.
Flatten medication serialization (MedicationResponse) + fix update/get/delete to
use medication_id (UUID) instead of Mongo _id. Full CRUD now works end-to-end.
