Question 1

What data does Rhea itself collect and store about me?

Accepted Answer

Rhea's own backend holds the minimum needed to operate the service: your Rhea Key account reference, organization membership, and limited security and audit logs. It does not hold the objects you protect with RED, the encryption keys, or the plaintext of anything you store — those live on your device and in the infrastructure you connect. See Privacy & Data Protection and the Rhea Key Privacy Policy for the full list.

Question 2

What is Bring Your Own Storage (BYOS)?

Accepted Answer

BYOS means the encrypted bytes are written to a storage bucket that you own and control, not to a Rhea-hosted store. You connect the bucket to RED, RED encrypts each object on the client with AES-256-GCM, then uploads the ciphertext. Rhea never receives a copy. Today RED supports AWS S3; Azure Blob, Google Cloud Storage, Oracle Object Storage, on-premise and S3-compatible endpoints are planned.

Question 3

What is Bring Your Own Database (BYOD)?

Accepted Answer

BYOD is the same principle applied to the metadata layer: the database that indexes your protected records lives in infrastructure you own. Rhea does not centralize your records or pointers on its own database. BYOD is planned — the initial target is customer-owned Postgres and compatible databases.

Question 4

Which storage and database providers are supported today?

Accepted Answer

Storage — AWS S3 is available now; Azure Blob, Google Cloud Storage, Oracle Object Storage, on-premise and S3-compatible endpoints are planned. Database — BYOD is planned. The Architecture page tracks provider status.

Question 5

What does the storage provider actually see in the bucket?

Accepted Answer

Opaque ciphertext blobs and the object keys you configure. Because encryption happens client-side before upload, the provider — AWS, Azure, GCP, Oracle, or your own datacenter — cannot read the contents of any object, cannot see file names it wasn't told, and cannot reconstruct plaintext from what is stored.

Question 6

What does the database provider see under BYOD?

Accepted Answer

References and structural metadata needed to look records up: opaque identifiers, timestamps, and pointers to the ciphertext in your bucket. Sensitive fields are not stored in the database in the clear. Because BYOD is planned, the exact schema will be documented alongside its release.

Question 7

How is my data encrypted?

Accepted Answer

RED encrypts every object on your device with AES-256-GCM before it is transmitted. The ciphertext, an authentication tag, and a per-object initialization vector are what leave the device. Neither Rhea nor your storage or database provider ever receives the plaintext.

Question 8

Where are the encryption keys stored?

Accepted Answer

Keys are held under your control through Rhea Key — the desktop/web client and, where used, the mobile app. Approvals for sensitive operations happen locally and are gated by the operating system's biometric or device unlock. Rhea's servers do not hold a copy of your keys and have no path to decrypt your data.

Question 9

What does "keep it readable under your control" mean in practice?

Accepted Answer

It means the boundary between infrastructure and readable data sits at your device. The cloud (or your on-premise storage) holds the bytes and, under BYOD, the metadata index. Turning those bytes back into readable content requires a key that only Rhea Key on your device can release. Cloud becomes storage, not trust.

Question 10

What encryption model does RED use?

Accepted Answer

RED uses client-side AES-256-GCM encryption before protected content is sent to storage. Rhea's services have no independent ability to decrypt protected customer content. Access is authorized cryptographically through Rhea Key or a supported Trezor workflow, and permitted decryption material is made available only to an authorized client according to RED's access controls. Private signing keys remain under the authorized user's control and are not stored by Rhea. Rhea still processes limited operational metadata—such as organization and role information, document identifiers, storage references, usage records, authorization events, and audit metadata—needed to provide the service. The complete model is described on the Architecture and RED Info pages.

Question 11

Can Rhea read my data?

Accepted Answer

No. Rhea does not receive plaintext and does not hold the keys needed to decrypt it. This is a structural property of the system, not a policy promise.

Question 12

Can my cloud provider read my data?

Accepted Answer

No. Under BYOS the provider stores encrypted objects and cannot derive plaintext from them. If the provider is compromised or subpoenaed, the bytes they can hand over remain ciphertext.

Question 13

Can third parties or advertisers access my data through Rhea?

Accepted Answer

Rhea has no advertising surface, no data-broker relationships, and no product that sells or shares your protected content. Access to a specific record is only possible through an explicit authorization performed with Rhea Key.

Question 14

How do I share access to a record with a colleague?

Accepted Answer

In RED you grant a team member access using their public address, and Rhea Key on their device negotiates the material needed to decrypt what you have authorized. The plaintext is only reconstructed on their device. The How to page walks through the flow from your key to your team.

Question 15

How do I revoke access?

Accepted Answer

Revocation is performed from RED against the specific authorization. New requests from that identity for the affected records are no longer honored, and any subsequent decrypt path requires a fresh approval through Rhea Key.

Question 16

Can I audit who accessed what?

Accepted Answer

RED records authorization and access events tied to the identities involved. The audit surface is scoped to actions inside RED and to the security events Rhea's own backend records — it does not, and cannot, log activity that happens entirely inside your storage or database provider without RED.

Question 17

How do I sign in? Are passwords involved?

Accepted Answer

Sign-in uses Rhea Key. On the web that means the Rhea Key Web client; on mobile, the Android app (see Download). Authorizations are approved with your device's biometric or OS unlock — there is no shared password to phish or breach on Rhea's side.

Question 18

What is the QR approval flow?

Accepted Answer

When a session on one device needs a sensitive action approved, it presents a QR code that another Rhea Key instance scans and approves after a local biometric check. The approval releases only the material required for that specific action.

Question 19

Is iOS supported?

Accepted Answer

Not yet. Rhea Key is available today as the web client and the Android app. iOS is not listed as a supported platform.

Question 20

What is Rhea ID?

Accepted Answer

Rhea ID is the identity layer of the ecosystem, designed so identity attributes are held as on-chain references rather than plaintext records stored by Rhea. Rhea ID is coming soon; the Rhea ID Info page describes the model in more detail.

Question 21

Will Rhea store my identity documents or personal identifiers?

Accepted Answer

The model is explicitly designed to avoid that. Rhea Key holds a reference — a contract and asset identifier — pointing to your identity assertion; the underlying private data is not centralized on Rhea's servers.

Question 22

How do I delete data I stored through RED?

Accepted Answer

Because the ciphertext lives in your own bucket under BYOS, deletion happens against your own storage — RED issues the delete and the object is removed from your infrastructure. Under BYOD the corresponding metadata is removed from your database. Rhea holds no shadow copy to purge separately.

Question 23

What happens if I reset or lose my Rhea Key device?

Accepted Answer

Rhea Key is designed so that losing the device does not hand your data to anyone else, and reset flows re-establish access through the recovery mechanisms documented in the Rhea Key Privacy Policy. Data whose keys are only held on a lost device may become unrecoverable — that is the tradeoff of keys living under your control.

Question 24

What does Rhea retain about me long term?

Accepted Answer

Account references, organization membership, and limited security and audit logs necessary to operate the service and investigate abuse. See Privacy & Data Protection for retention specifics.

Question 25

Who is the data controller when I use RED with my own storage and database?

Accepted Answer

When you operate RED against your own bucket (BYOS) and, in the future, your own database (BYOD), you are the controller of the objects and records that live in your infrastructure. Rhea acts as the processor for the limited operational data it holds on its own backend.

Question 26

How do I exercise access, portability, or erasure rights?

Accepted Answer

For data inside your own bucket or database you have direct control — RED can enumerate, export, and delete against your infrastructure. For the operational data Rhea itself holds, email contact@rhea.llc. Security-sensitive requests can be sent to security@rhea.red.

Question 27

What does an attacker see if my cloud storage is breached?

Accepted Answer

Encrypted objects and their opaque keys. Without a valid decrypt approval from Rhea Key on a legitimate device, the ciphertext cannot be turned into readable content. This is the practical value of client-side encryption paired with BYOS.

Question 28

What if my database provider is breached under BYOD?

Accepted Answer

The database holds references and structural metadata, not the plaintext of your records. An attacker who reads the database can enumerate identifiers but still needs both the ciphertext in your bucket and a valid decrypt authorization to reconstruct any protected content.

Question 29

What if my Rhea Key device is stolen?

Accepted Answer

Approvals require the device's biometric or OS unlock, which the thief does not have. You can also reset the key from another trusted device; the reset invalidates the compromised instance for future authorizations.

Question 30

Which Rhea Key clients are available?

Accepted Answer

Rhea Key Web is available at rheakey.com. The Android app is available — see Download. iOS is not listed as a supported platform.

Question 31

Which storage integrations are available today?

Accepted Answer

AWS S3 is available now. Azure Blob Storage, Google Cloud Storage, Oracle Object Storage, on-premise deployments and S3-compatible endpoints are on the roadmap.

Question 32

Is Bring Your Own Database available today?

Accepted Answer

BYOD is planned, not shipped. The initial target is customer-owned Postgres and compatible databases so both the ciphertext and the metadata index live in infrastructure you control.

Frequently asked questions.

Data collection & storage.

Encryption & keys.

Who can see what.

Access & sharing.

Authentication.

Identity (Rhea ID).

Deletion, reset & retention.

Legal, GDPR & CCPA.

Breach & recovery.

Platforms & provider support.

Talk to us directly.