DRK Security

The Data Root Key is the root secret a zero-knowledge application can use to derive or unwrap application data keys. DarkAuth stores the DRK only as ciphertext wrapped under client-derived material.

Wrapped storage

The client derives a wrapping key from OPAQUE output and uses it to encrypt the DRK. DarkAuth stores the wrapped value. During honest operation, the backend and database cannot unwrap it because they do not have the client-derived key.

Fragment delivery

For ZK-enabled clients, the app sends an ephemeral ECDH public key in the authorization request. Browser code encrypts the DRK to that key and delivers the JWE through the URL fragment.

The server stores only drk_hash, a hash of the fragment JWE. The token response returns zk_drk_hash so the app can verify that the fragment it received matches the authorization code.

Custody recommendations

Keep DRK custody memory-only by default. Clear it on logout. Remove the fragment from the URL after processing. Generate a fresh ephemeral key for each authorization request.

Persistent DRK storage can improve convenience, but it weakens the hosted-web custody story. If you enable it, describe the tradeoff clearly.

Threats to consider

The DRK can be exposed by malicious app code, malicious DarkAuth frontend code, XSS, browser extensions, device compromise, or application code that logs or uploads it. The ZK flow reduces server-side custody; it does not remove frontend trust.