Threat model
Assume the attacker wins somewhere. What then?
A security architecture is only meaningful in terms of what survives a compromise. These are the outcomes as they stand today, including the ones that do not flatter us.
Compromise scenarios
If this is compromised, this is the outcome.
| Scenario | Exposed | Still protected | Outcome |
|---|---|---|---|
| Your storage provider is compromised | Ciphertext, object sizes, object counts | File contents, document keys | An attacker with full bucket access obtains ciphertext and object layout. Files do not open: the data keys are not in the bucket, and tampering with chunks or the manifest fails authentication rather than producing wrong plaintext. |
| Rhea's database is compromised | Filenames, sizes, timestamps, audit records, wrapped keys as ciphertext | File contents, document keys, recovery shares | An attacker reads operational metadata — including filenames and folder names — plus wrapped key material they cannot unwrap. No document key can be recovered, because the unwrapping key is derived on your device from a wallet signature that is never stored. |
| Rhea's backend is compromised | Storage credentials, all metadata, the ability to serve client code | Existing protected file contents, document keys | An attacker gains the database plus Rhea's server-held secrets, which include the key protecting your storage credentials. They can therefore reach your bucket and take ciphertext, and they can serve a modified client application to future users. They still cannot decrypt existing protected content, because no server-side path to a document key exists. |
| A user's device is compromised | Files that user is authorized to decrypt | Documents for which that user holds no wrapped key | Everything that user is authorized to open can be read, because decryption legitimately happens on their device. Their authority can be revoked, and their actions remain in the audit record. This is the strongest reason to scope authority narrowly. |
| An organization administrator is compromised | Organization configuration, membership, metadata | Contents of documents not wrapped to that administrator | The attacker can perform administration — membership, policy and configuration changes — and those changes are recorded. They cannot decrypt documents for which the administrator holds no wrapped key, because administration does not confer readability. |
| A guardian is compromised | One recovery share, if the passphrase is also obtained | The organization key, below the guardian threshold | A single guardian's Recovery Kit is not sufficient. Recovery requires the configured threshold of guardians, each providing a signed, single-use consent, with reconstruction happening only in the initiating administrator's browser. |
Outcomes describe the architecture as verified in the product code. They are not a guarantee against every attack.
Residual assumptions
What you are still trusting.
- Rhea serves the client application that performs encryption and decryption. This is the standard web-delivery trust boundary and it is real.
- Rhea holds a server-side key that decrypts customers' storage provider credentials — not file contents.
- Filenames, folder names and MIME types are stored as plaintext metadata today.
- No independent third-party audit of the implementation has been completed yet.
- An authorized endpoint that is compromised can read what that endpoint is authorized to read.
Test the claims instead of accepting them.
The verification lab lists concrete checks you can run against your own environment.