How Rhea works: data, access, and identity

What Rhea is

Rhea is data protection and management infrastructure. It is not a cloud drive, a password manager, a crypto wallet, a blockchain company, a file-sharing app, or a generic cybersecurity platform. The system is organized around a single principle: store data anywhere, keep it readable only under your control.

Three components make that principle concrete. RED handles the data itself. Rhea Key handles access and authorization. Rhea ID handles identity and attribute verification. Each has its own trust boundary and its own role in the system; content does not pass through Rhea Key or Rhea ID on the way to storage.

Accounts, without a stored password

A conventional web account is proven by an email-and-password credential that a server stores and checks. If that server is breached, the credential is exposed. Rhea does not rely on that model as the core cryptographic access authority. Instead, control is proven by a cryptographic account: a keypair whose private half stays with the user and whose public half can be shared freely.

RED still maintains the operational records required to run the service — organizations, roles, sessions, audit events, usage, and commercial metadata. That control plane is a hosted surface. But the authority to act on protected data is anchored to a signature that only the keyholder can produce.

Public keys, private keys, and signatures

A keypair has two halves. The public key can be shared: it identifies the account and lets anyone verify signatures made by the matching private key. The private key must remain secret; it produces signatures and, in some schemes, decrypts. A signature is a value that anyone with the public key can verify but only the private-key holder could have produced. Signing is not the same as encrypting, and signing a message is not the same as sending a blockchain transaction.

A public identifier derived from a public key — often called an address — can reference the account on public networks. That reference does not expose the private key, and Rhea's services never hold it.

How Rhea Key proves control

Rhea Key is the signing surface for a cryptographic account. Its job is to hold the private key on a device the user controls and to produce signatures for authorization requests, without ever exposing the key. It is not a cryptocurrency wallet product.

A typical session is established by pairing a signing surface with an application over the WalletConnect protocol — Rhea Key implements that protocol using Reown WalletKit. Pairing is usually initiated by a QR scan; from that point the two sides communicate over an encrypted channel. When an action requires authorization, the application sends a request; Rhea Key shows it to the user; if the user approves, Rhea Key signs and returns the signature. If the user declines or the device disconnects, no signature is produced and no action proceeds.

Trezor and hardware-held keys

A hardware signing device such as a Trezor holds the private key inside a dedicated device rather than on a general-purpose computer or phone. Signing happens on the device; the key never leaves. This narrows the attack surface for administrator-level authority in particular, because a compromise of the operating system does not translate into a compromise of the key.

Trezor is supported by RED as an alternative signing surface where the workflow calls for hardware-protected authorization. Physical possession of the device — plus the PIN and, where used, a passphrase — is what proves control. Loss of the device without a recovery seed means loss of the account it controls, exactly as it would with any other properly non-custodial signing surface.

How RED protects data before storage

RED encrypts every object on the user's device using AES-256-GCM. What leaves the device is ciphertext, an authentication tag, and a per-object initialization vector. The object is then written to storage that the customer owns and controls. Retrieval reverses the flow: the encrypted object is fetched, and — after the authorization checks below — decrypted on the device.

How an authorization becomes access

Reading a protected object is a sequence of steps, each of which can fail closed:

The signing surface can be Rhea Key on a mobile device, Rhea Key on the web, or a hardware device such as Trezor for workflows that require hardware-protected authorization. In every case the signature is what carries authority — a leaked server credential cannot substitute for it.

Where data actually lives: BYOS

Bring Your Own Storage means encrypted objects are written to a storage bucket the customer owns. RED supports AWS S3 today. Additional providers — Azure Blob, Google Cloud Storage, Oracle Object Storage, on-premise, and S3-compatible endpoints — are planned. A separate Rhea Managed Storage option is available for customers who prefer not to operate storage themselves.

Bring Your Own Database extends the same principle to the metadata that indexes protected records. BYOD is planned; it is not currently available.

The acronym BYOD is also commonly used to mean Bring Your Own Device in enterprise IT. Rhea uses BYOD in the database sense; when device policy is meant, the phrase personal device or user device is used instead.

What Rhea can see, and what Rhea cannot

Rhea does not claim to see nothing. It operates a hosted control plane, and that control plane has to hold certain information to function. The important distinction is between protected content, keys, operational metadata, audit events, and billing metadata.

• Protected content: the objects a user encrypts with RED. Rhea's services have no independent ability to decrypt protected customer content.
• Encryption keys and private keys: held under the user's control. Rhea's services do not hold user private keys.
• Operational metadata: organization structure, roles, memberships, sessions, document identifiers, storage references, and usage records needed to operate the service.
• Audit events: records of authorization requests and administrative actions, kept so an organization can review what happened. An audit event may be created for an action without exposing the content that action was applied to.
• Billing metadata: the commercial records required to run the account.
• Storage provider: sees ciphertext and object metadata such as sizes and access times. It does not see plaintext or encryption keys.

Available vs planned

The Rhea system is under active development. The status table below captures the components introduced above at the time this article was reviewed.

Where to go next

This article introduces the whole system at a high level. For product-specific detail, see RED, Rhea Key, and Rhea ID. For a vocabulary reference, see the Learn glossary.