Credential-derived key custody — spike (local/LDAP only) #30

New issue

Closed

opened 2026-07-25 17:44:01 +00:00 by Cordy · 1 comment

Cordy commented

2026-07-25 17:44:01 +00:00

Owner

Manuel's passwordHash + user-PIN → key model: derive the encryption key from user credentials so it lives only in RAM (zeroed after use) and the backend holds no standing key — a stronger data-processor posture.

Hard constraint (the crux): this works only where the server sees the password —

✅ local auth, LDAP search-then-bind
❌ OIDC (server never sees the IdP password) and WebDAV app-passwords (random per-device secrets); also breaks share links, admin visibility, background access.

It's the E2E trade-off relocated to key derivation: "server never holds a usable key" XOR "transparent decryption for all clients." OpenBao does not solve this (orthogonal). Spike in local/LDAP mode, measure the UX/threat trade honestly, write it into ENCRYPTION-COMPARISON.md. This is the risky half of the weekend prototype.

Manuel's `passwordHash + user-PIN → key` model: derive the encryption key from user credentials so it lives **only in RAM** (zeroed after use) and the backend holds no standing key — a stronger data-processor posture. **Hard constraint (the crux):** this works only where the server sees the password — - ✅ local auth, LDAP search-then-bind - ❌ **OIDC** (server never sees the IdP password) and WebDAV **app-passwords** (random per-device secrets); also breaks share links, admin visibility, background access. It's the E2E trade-off relocated to key derivation: *"server never holds a usable key"* XOR *"transparent decryption for all clients."* OpenBao does **not** solve this (orthogonal). Spike in local/LDAP mode, measure the UX/threat trade honestly, write it into `ENCRYPTION-COMPARISON.md`. This is the risky half of the weekend prototype.

Cordy added this to the v0.4 — Real competitor (parity + hardening) milestone

2026-07-25 17:44:01 +00:00

Cordy commented

2026-08-03 19:02:24 +00:00

Author

Owner

Decision — rejected (Manuel's review, relayed by Nikola 2026-07-31):

"No, because unique keys should be used for every user and/or group."

Closing as won't-do. Credential-derived custody would tie key material to passwords rather than giving each user/group its own independent identity, which contradicts the per-user/per-group unique-key principle. The spike will not be pursued; custody work continues in #29 (OpenBao backend, approved) and #31 (domain separation, approved with amended scope).

**Decision — rejected (Manuel's review, relayed by Nikola 2026-07-31):** > "No, because unique keys should be used for every user and/or group." Closing as won't-do. Credential-derived custody would tie key material to passwords rather than giving each user/group its own independent identity, which contradicts the per-user/per-group unique-key principle. The spike will not be pursued; custody work continues in #29 (OpenBao backend, approved) and #31 (domain separation, approved with amended scope).

Cordy referenced this issue

2026-08-03 19:03:03 +00:00

OpenBao key-custody backend (uniform AD + Keycloak) #29

Cordy closed this issue

2026-08-03 19:03:13 +00:00