RonikCloud

Client-side vs server-side encryption: where does protection begin?

Both approaches can protect stored data, but they place trust and key handling at different boundaries. The useful question is which system sees readable file content, when encryption occurs, how recovery works, and what operational metadata remains.

Test the encryption workflow See product and pricing

Founding beta: RonikCloud has not been independently audited. Use non-critical copies and keep another backup.

Location mattersIdentify the first component that sees plaintext
Keys define capabilityAsk who can derive, wrap, recover, or rotate them
Metadata is separateEncryption does not erase every operational record
Recovery is a tradeoffStronger user control increases user responsibility

Use the data path to understand the difference.

Marketing terms become clearer when you follow a file from the local device to the service, storage provider, another device, and an outside recipient.

Before upload

Client-side encryption transforms protected plaintext on the user’s device. With server-side encryption, the service application receives readable content before its storage layer protects it.

During transport

HTTPS can protect either model in transit. It prevents ordinary network observers from reading the request but does not decide which endpoint handles plaintext.

While stored

Both models may store ciphertext. The difference is whether the service application possesses the key or receives the readable file during normal processing.

During recovery and sharing

Recovery, previews, search, collaboration, and public sharing may introduce different key paths. Each feature needs its own documented boundary.

The service protects data within infrastructure it controls.

In a typical server-side model, the client sends data over a protected connection and the service encrypts it for storage. This can reduce storage-media exposure and centralize key rotation, recovery, indexing, and policy enforcement.

  • Operational simplicityThe service can usually perform previews, search, processing, recovery, and sharing without asking the user to manage separate content keys.
  • Central key authorityService-controlled key systems can rotate or revoke storage keys, but the service application remains inside the plaintext trust boundary.
  • Infrastructure protectionEncryption at the storage layer helps protect lost media or unauthorized raw storage access when keys are controlled separately.
  • Threat-model limitIt does not prevent the authorized service application—or a compromise with equivalent authority—from accessing readable content during normal processing.

Protected content reaches the service already encrypted.

In a client-side model, the device encrypts supported plaintext before upload. The service can store and route ciphertext without requiring the ordinary storage path to receive the content key.

A narrower plaintext boundary

The storage service can operate on protected ciphertext, while decryption occurs in an authorized client that has or derives the necessary key.

More client responsibility

The client must handle key derivation, device state, recovery artifacts, failures, and safe collaboration paths. Lost secrets can mean lost access.

Feature-specific exceptions matter

Thumbnails, search indexes, comments, shares, recovery, and team access need separate scrutiny. One protected upload path does not prove every feature has the same boundary.

Client-side protection with documented limits.

RonikCloud encrypts protected file content, file names, and new folder labels on the device before storage. It uses separate protected paths for recovery, Business member keys, password shares, file requests, comments, and local private state.

RonikCloud does not make a global zero-knowledge or universal end-to-end-encryption claim. The server cannot prove that arbitrary uploaded bytes are semantically encrypted, and service metadata remains necessary.

Important: Operational metadata includes object sizes, timestamps, opaque identifiers, access relationships, storage routing, subscription state, and limited security records. Network infrastructure can observe connection data, timing, and traffic volume.

Read the evidence behind the workflow.

Use the related RonikCloud guides to inspect protection, recovery, sharing, collection, and team access in more detail.

Team keys and membership

See how Business folder keys are wrapped for members and how access changes affect local state.

Cloud encryption explained FAQ

Is client-side encryption the same as HTTPS?

No. HTTPS protects traffic between endpoints while it is in transit. Client-side encryption protects selected content before the upload reaches the service application boundary, so the two controls address different parts of the data path.

Does server-side encryption mean data is stored as plaintext?

Not necessarily. Server-side encryption can store data as ciphertext and protect storage media. The distinction is that the service application receives readable data or controls the encryption path before the storage layer protects it.

Does client-side encryption hide all metadata?

No. File sizes, timestamps, opaque identifiers, access relationships, routing, account state, limits, and network observations may remain visible even when file content and private labels are protected.

Which encryption model does RonikCloud use?

RonikCloud uses client-side protection for supported file content, protected file names, and new folder labels before storage. Other features have their own documented key and metadata boundaries, so RonikCloud does not make a universal zero-knowledge or end-to-end-encryption claim.

Test where protection begins and how recovery works.

Join the tester program and exercise upload, recovery, sharing, and team behavior, or review the product and current pricing first.

Founding beta: RonikCloud has not been independently audited. Use non-critical copies and keep another backup.

Test the encryption workflow See product and pricing