Encrypt before storage
The client encrypts protected file bytes on your device and authenticates them so modified ciphertext is rejected during decryption. Protected names and new folder labels are encrypted too.
RonikCloud encrypts protected file content, file names, and new folder labels on your device before storage. You keep a practical workspace for uploads, backup, sharing, and recovery without treating privacy as an afterthought.
Founding beta: RonikCloud has not been independently audited. Use non-critical copies and keep another backup.
Encryption is part of the workspace flow, not a separate vault that you have to remember to use for a handful of sensitive files.
The client encrypts protected file bytes on your device and authenticates them so modified ciphertext is rejected during decryption. Protected names and new folder labels are encrypted too.
Workspace listings, selected backup paths, interrupted-transfer checkpoints, and supported offline files are kept in encrypted, account-scoped device storage.
Export the standard encryption key as an AES-256-GCM recovery kit protected by a separate passphrase. Store the kit and passphrase apart so one lost device does not become a lost archive.
Good protection also needs clear recovery choices, deliberate unlocks, and safe behavior when a network request is uncertain.
RonikCloud still needs limited operational information to store, route, authorize, and bill for the service. Saying what remains is part of making an informed security decision.
The service can retain object size, upload time, opaque file and folder references, parent-child and access relationships, encrypted-name fields, storage-routing data, subscription state, and limited security records. Connection timing, IP data, and traffic volume cannot be hidden from all service infrastructure.
Security status: This page describes the current implementation. It is not a claim of formal certification or an independent security audit. Keep an independent backup of irreplaceable data.
Read the full security whitepaper for exact cryptographic parameters, key flows, service-visible metadata, and implementation-specific limitations.
Compare the protection boundary in the client-side versus server-side encryption guide, or use the Google Drive and Dropbox evaluation guides.
Protected file content, file names, and new folder labels are encrypted on the device before storage. App and browser traffic also uses HTTPS.
No. Storage and account operations require limited metadata, including object sizes, upload times, opaque identifiers, access relationships, routing information, and subscription state. Network infrastructure can also observe connection data, timing, and traffic volume.
Account Security can export the standard encryption key in a recovery kit encrypted with a separate passphrase. RonikCloud does not upload the kit or its passphrase. Store them safely and separately because support cannot recreate either one.
Join the tester program to try protected storage, or review the product and current pricing first.
Founding beta: RonikCloud has not been independently audited. Use non-critical copies and keep another backup.