CipherDrive™ encrypts supported file contents on your device before they are stored by Ackaia. This means uploading a file involves more than simply sending plaintext data to a storage server.
From your CipherDrive drive, choose the upload action and select the file or files you want to store. Depending on the current interface, you may also be able to upload into a specific folder or start an upload by dragging files into the drive.
The exact controls can change as CipherDrive evolves, but the underlying security model remains the same for supported encrypted-storage workflows.
A typical CipherDrive upload follows this process:
You select a file on your device.
Where applicable, CipherDrive's Risk Assessment Engine performs pre-encryption safety checks.
Your browser or client generates a random file-specific encryption key.
Supported metadata, such as the filename where available, may be encrypted locally.
The file is divided into chunks when needed.
Each chunk is encrypted locally using authenticated encryption.
The file key is wrapped using higher-level vault key material.
The encrypted chunks and encrypted key material are uploaded.
Ackaia stores the encrypted object and operational metadata needed to run the service.
After client-side encryption has completed, Ackaia does not ordinarily need plaintext file contents to store the file.
For supported encrypted-storage workflows, the normal storage design is for file contents to be encrypted in the browser or client before the encrypted data is uploaded to Ackaia's storage infrastructure.
However, CipherDrive may run disclosed safety and abuse-prevention checks before encryption. Those checks can generate technical signals such as cryptographic hashes, perceptual hashes, file signatures, similarity indicators, risk scores, or other safety metadata.
This pre-encryption safety boundary does not create a general server-side key that can later decrypt the stored file.
Encryption happens on your device. Large uploads can therefore use:
CPU for cryptographic operations;
memory for buffering and chunk processing;
network bandwidth for transferring encrypted chunks;
local browser or application resources while the upload is active.
This is expected behavior for client-side encrypted storage.
Zero-knowledge storage does not mean zero metadata. Depending on the active client and feature set, Ackaia may process operational information such as:
the account associated with an object;
object type, such as file or folder;
encrypted file size or storage usage;
upload and update timestamps;
folder relationships;
MIME category or generalized media category where required;
sharing status;
transfer usage;
security, session, and device information;
risk signals or blocked-upload records generated before encryption.
Where filename encryption is enabled for a given object, Ackaia is not expected to see the plaintext filename after encryption. Exact protection depends on the active client version, feature support, and migration state.
Your CipherDrive plan or current service configuration may apply limits involving storage capacity, file size, transfer usage, rate limits, bandwidth, fair use, or available features.
These limits can change by plan, region, client, or product configuration, so CipherDrive will show the relevant current limit or error when one applies. Do not rely on an old support article or screenshot as the authoritative source for a numeric quota.
Because encryption and upload processing occur in the client, closing the browser tab, terminating the application, losing network access, clearing site data, or putting the device into a state that interrupts the client can stop an in-progress upload.
Some workflows may support multipart or resumable behavior, but availability can vary. If an upload is interrupted, follow the current CipherDrive interface to resume or restart it.
Confirm that the file appears in the expected folder and, for important data, test that you can access or download it from a trusted device.
For irreplaceable files, maintain an independent backup. CipherDrive's encryption model can prevent Ackaia from recovering a file if the cryptographic material needed to decrypt it is permanently lost.