CipherDrive™ is designed so that sharing a file does not require exposing your vault's master key to the recipient. Instead, the sharing protocol can use share-specific key material to grant access to an individual encrypted object.
Each CipherDrive file has its own random file key. That key encrypts the file contents.
Inside your normal vault, the file key is protected by higher-level vault key material such as the master key.
Giving another person your master key would potentially expose much more than the one file you intended to share.
CipherDrive's documented architecture allows file keys to be wrapped by the master key or by share-specific key material. This supports sharing a selected object without handing the recipient the vault's highest-value key.
A sharing protocol can work conceptually like this:
The source file already has a random file key.
The client creates or obtains share-specific cryptographic material.
The file key is wrapped for the sharing context.
Ackaia stores or serves the encrypted file and wrapped key material.
The recipient receives the client-side share key through the share context.
The recipient's browser uses that share key to recover the file key locally.
The file key decrypts the encrypted file locally.
The exact format can vary by protocol version and sharing feature.
One common encrypted-sharing pattern puts client-side decryption key material in the URL fragment after #.
Ordinary HTTP requests do not normally send the fragment to the server. This can allow:
Ackaia to receive the object identifier and authorize the download; while
the recipient's browser receives the key material required for local decryption.
No. The fragment is protected from ordinary transmission to the web server by browser URL behavior, but it still exists on the recipient's client.
It can be exposed by:
malicious browser extensions;
client-side scripts or tools with access to the full URL;
screenshots;
copy-and-paste into third-party services;
compromised devices;
the recipient intentionally forwarding the complete link.
Ackaia may still need server-visible information such as:
object identifier;
link status;
server-side access permission;
encrypted file-key material;
transfer usage;
request metadata;
rate-limit or security state.
Possessing an encrypted file key is not the same as possessing the plaintext file key.
Even if a recipient has seen the share key, CipherDrive can enforce server-side link status and stop serving the encrypted source object through the revoked link.
However, if the recipient already downloaded the encrypted data and retained everything necessary to decrypt it, or already exported the plaintext file, link revocation cannot guarantee destruction of that recipient-controlled copy.
The sharing model preserves the core zero-knowledge principle when Ackaia can coordinate access to encrypted data without ordinarily receiving the plaintext master key or plaintext file key required to decrypt the stored content itself.
The important separation is: the server controls whether it will serve the shared object; the recipient's client controls whether it has the cryptographic material needed to decrypt it.