PikPak Vault Is Coming Soon: Protect Your Private Files with End-to-End Encryption

We are excited to share that PikPak’s new security feature, Vault, has entered system testing and will gradually begin a phased gray rollout starting with the mobile app.

This is more than a folder with a lock on it. Unlike vaults, private spaces, or similar features found in many cloud drive products, PikPak Vault combines local protections such as Auto-Lock and Biometrics with a newly designed End-to-End Encryption mechanism, also commonly known as a Zero-Knowledge Encrypted Storage architecture.

This means your encryption keys remain under your own control. Even PikPak cannot directly read, decrypt, or view the files you store in Vault. For users who want to keep highly private data, important documents, or personal collections, this is one of the highest levels of security protection we can currently provide.

To make this feature possible, we have spent months studying and balancing End-to-End Encryption, key management, multi-device synchronization, and user experience. We carefully considered each technical choice and completed the design and development work around security, reliability, and ease of use. For a cloud drive, the real challenge is not only encrypting files, but also keeping synchronization, sharing, save-to-drive, playback, and resumable transfer usable after encryption.

Next, let’s unpack the design from the engineering side. We will start with the most important question: once a file enters Vault, where does plaintext stop, and what can the cloud actually see? Once that boundary is clear, the key derivation, file encryption, sharing, save-to-drive, and streaming playback designs become much easier to follow.

1. End-to-End Encryption Boundary

Vault’s first job is to keep the ability to “understand” a file on your device. File content, file attributes, and key materials are encrypted locally before they are handed to the cloud for storage, sync, or transfer. From the product flow, it still feels like a familiar cloud drive: application entry -> user space -> Vault or shared space. The difference is that the ability to turn ciphertext back into plaintext stays with authorized clients.

The server remains responsible for file storage, sync state, sharing indexes, and transfer orchestration. The main data it can see and store includes:

• Encrypted file content, represented as ciphertext chunks.
• Encrypted metadata, such as encrypted file attributes, encrypted file keys, and encrypted chunk descriptors.
• Account or sharing related encrypted master key material, share identifiers, and required indexes.

The server does not need to directly hold:

• Plaintext file content.
• The plaintext master key.
• Plaintext File Keys.
• A complete key path that can directly decrypt user files.

This boundary is the starting point for the entire Vault design: the cloud keeps files stored, synchronized, and available, while plaintext recovery remains tightly limited to authorized clients.

2. Security Goals and Design Mapping

A security design should not read like a shopping list of algorithms. For Vault, the more important question is where each security goal lands in the system: which step protects confidentiality, which step rejects tampering, and which step keeps key exposure contained. The table below maps those goals to concrete engineering positions.

Security goal	Implementation detail
Confidentiality	File content uses AES-256-GCM; each file has an independent File Key; master key material is encrypted before cloud storage.
Integrity	GCM authentication tags are verified per encrypted chunk; decryption fails closed when verification fails.
Key isolation	Master keys, metadata keys, File Keys, and Share Keys are separated through layered derivation.
Minimal exposure	Sharing uses independent Share Keys; save-to-drive rewraps keys under the recipient account.
Identity and tamper resistance	Ed25519 signatures and verification can be used to authenticate relevant business messages.
Local access control	Local playback uses random access tokens to reduce the risk of arbitrary local plaintext stream access.
Evolvability	Key derivation labels and encryption suite metadata include versioning for future upgrades.

3. Layered Key Derivation

Using one master key for everything may look simple, but it would also enlarge the impact of any mistake. Vault uses a tree-like key derivation model instead, separating account-level, metadata-level, file-level, and sharing-level contexts so each key is tied to a specific job.

Conceptually, it works like a key tree with purpose and version labels:

User credential (Vault Passcode / 12-word mnemonic) + client-side random factor
  -> PBKDF2 or mnemonic recovery
  -> Master key
  -> HKDF with purpose and version labels
  -> File-domain root material
  -> Per-file metadata key derived by file identifier
  -> Encrypted file attributes, File Key, and chunk descriptors

Share Keys form a separate branch. They are derived from the sharing context, used only for sharing workflows, and kept isolated from the normal file encryption path.

This separation provides several practical engineering benefits:

• Purpose separation: different derivation labels bind key material to different security contexts.
• Reduced blast radius: exposure of one File Key should not naturally derive other File Keys.
• Versioned evolution: derivation labels can include version metadata for future cryptographic suite upgrades.
• Account recovery support: the cloud stores encrypted master key material rather than a plaintext master key.
• Unified entry point: after a user sets up or unlocks Vault, upload, download, sharing, and save-to-drive can reuse the same derivation rules without reimplementing cryptographic details in each business flow.

We do not reinvent the cryptographic foundation from scratch. The implementation uses mature components such as OpenSSL primitives for PBKDF2, HKDF, AES-256-GCM, and Ed25519. In environments that are more sensitive to random source quality, additional entropy can be injected into the random number generator when needed.

4. File Encryption and Metadata Protection

File encryption is the core data path of Vault. When the client receives a file, it first creates a unique file identifier and a dedicated File Key for that file. The file metadata key then wraps the File Key, producing an encrypted file key that can be stored in the cloud. The client also writes chunk descriptor data, including plaintext length, encryption suite version, chunk size, and ciphertext offsets, before reading the local file chunk by chunk and emitting AES-GCM ciphertext with authentication tags.

That sequence sounds low-level, but the intention is straightforward: every file gets its own File Key, every chunk gets its own authentication result, and the cloud receives data it can store and sync but not read. Chunk size is selected adaptively, roughly between 64 KB and 4 MB depending on file size. Smaller files reduce metadata and scheduling overhead, while larger files reduce the number of cryptographic calls and improve throughput. Chunk descriptors can be serialized with a structured binary format such as Protocol Buffers, so layout semantics remain consistent across versions and platforms.

Vault protects more than the file body. File names, directory structure fields, product-level file attributes, wrapped File Keys, and chunk descriptor data can all be part of the protected metadata. This matters because metadata can reveal content type or usage patterns even when the file body is encrypted. For this reason, metadata encryption is treated as part of the End-to-End Encryption model rather than an optional layer.

Nonce uniqueness is another detail that has to be handled deliberately. Vault does not blindly reuse an external nonce; it derives each chunk nonce from both the file identifier and the chunk index. This separates encryption contexts across chunks and files and satisfies GCM’s uniqueness requirement for nonces.

5. Encrypted Share and Save-to-Drive

Encrypted Share needs to solve a narrower problem than ordinary cloud sharing: a recipient should be able to read authorized files without receiving the owner’s account master key. PikPak treats sharing as an independent encryption context. The owner creates a share and obtains a share identifier; the client derives a Share Key for that context and delivers it to the recipient through a separate secure channel. Required key material for shared files is then rewrapped with the Share Key, while the server stores only the share index, encrypted key material, and ciphertext files.

For the recipient, entering a shared space means decrypting authorized content locally, not asking the server for a general-purpose key that can recover the owner’s account. If the recipient saves the shared file into their own Vault, the client performs another rewrapping step: it resolves the required file key material inside the sharing context, re-encrypts the File Key and file attributes under the recipient account’s metadata key, and stores the new encrypted file key and encrypted attributes in the recipient’s cloud space. After that, the saved file belongs to the recipient’s own key hierarchy and no longer depends on the owner’s account key path.

6. Streaming Decryption and Range Access

For large files, videos, and audio, downloading the entire object before decryption is inefficient. Vault therefore maps plaintext ranges to ciphertext ranges. When an upper layer asks for a plaintext byte range, the client uses chunk descriptor data to calculate the corresponding ciphertext range, fetches only that range, and verifies and decrypts the chunks locally.

This range mapping is what makes resumable transfer and playback seeking practical under encryption. A download or upload can align with confirmed remote progress, a player seek becomes a new Range request instead of a full-file restart, and the client does not need to keep an entire large object in memory. For local playback, the client can start a lightweight HTTP decryption proxy on 127.0.0.1. The system player still sends standard HTTP Range requests, but ciphertext lookup, GCM verification, and decryption remain inside the local client. The playback URL carries a local access token so the plaintext stream is scoped to the current playback session.

The download path follows the same principle. The client requests only the ciphertext range required for the target plaintext range, verifies and decrypts data as it arrives, and releases temporary data when the task finishes or is canceled. During playback, session queues and send-buffer limits coordinate the decryption and output rate so memory does not grow without bound when decryption is faster than consumption.

7. Upload-Side Chunk Encryption and Progress Synchronization

Upload does not introduce a completely separate model from download; it uses the same chunking idea in the opposite direction. The client first queries the remote received and confirmed byte counts, resumes ciphertext generation from the aligned offset, and uploads ciphertext chunks progressively. The server only needs to schedule transfer and confirm progress, so the state machine can connect query progress, continue upload, and confirm completion without understanding plaintext content.

This also makes upload a resumable flow rather than a single large request. It can be paused, resumed, canceled, and queried for progress. For users, this mirrors the streaming download experience; for the system, it avoids pushing the entire file into upload buffers at once.

8. Cross-Platform Implementation

Vault is built around a C++ core library with a C interface, which allows the same cryptographic logic and data format handling to be reused across clients instead of being reimplemented separately for every platform. The target environments include iOS, Android, macOS, Windows, Linux, and modern browsers. The value of this shared core is not only broader device coverage; it is behavioral consistency. The same encrypted data should follow the same key derivation, chunk descriptor parsing, nonce derivation, authentication verification, and decryption flow across devices.

9. Typical Lifecycle

From the user flow perspective, the lifecycle is straightforward. When a user sets up or unlocks Vault, the client receives the user credential or 12-word mnemonic, restores master key material through PBKDF2 or mnemonic recovery, decrypts the encrypted master key material stored in the cloud, and initializes derivation contexts for the file domain, sharing domain, and signing domain. From that point on, upload, download, sharing, and save-to-drive all reuse the same derivation model.

During upload, the client generates a file identifier and File Key, chooses a chunking strategy based on file size, and creates encrypted chunk descriptor data. File content is encrypted chunk by chunk, each chunk producing ciphertext and a GCM authentication tag. The client then uploads ciphertext chunks together with the encrypted file key, encrypted file attributes, and encrypted chunk descriptors, while the server confirms received and committed progress.

Download and playback run in the opposite direction. The client decrypts file attributes, the File Key, and chunk descriptor data. For full download, ciphertext chunks are fetched and decrypted in order. For Range playback, the plaintext range is first mapped to the ciphertext range, only the required ciphertext is fetched, and GCM tags are verified per chunk. Plaintext is emitted only after verification; verification failure fails closed.

Sharing and save-to-drive follow the same boundary. The owner creates a share, the client derives a Share Key and wraps the required file key material, and the recipient decrypts authorized content locally inside the shared space. If the recipient saves the file, the client rewraps the File Key and file attributes under the recipient’s own metadata key, making the saved file part of the recipient’s own key hierarchy.

10. Implementation Notes

In this type of design, risk often comes less from a single algorithm and more from broken boundaries. Nonces must not repeat, so chunk indexes, file identifiers, and suite versions need to preserve context uniqueness together. GCM verification failure must fail closed rather than degrade into a warning or tolerant read. Metadata encryption should cover more than file names; chunk descriptors and wrapped File Keys also need protection. Sharing must not expose the account master key, and save-to-drive should not reuse the owner’s wrapping result directly. The local HTTP decryption proxy should use short-lived, random access tokens bound to the file and space context. Derivation labels, encryption suites, and data formats should all be versioned to avoid conflicts with historical data. Cross-platform implementations should also share the same test vectors for key derivation, chunk descriptor parsing, nonce derivation, GCM verification, and Range mapping.

Summary

PikPak Vault is not a simple passcode layer on top of ordinary cloud files. It redesigns file storage, key management, sharing, save-to-drive behavior, and streaming access around End-to-End Encryption.

The core of the design is not to turn an algorithm into a marketing point, but to connect client-side encryption, key isolation, metadata protection, sharing and save-to-drive, Range playback, and cross-platform consistency into one engineering path. Files are encrypted on the client while the cloud handles ciphertext; master keys, metadata keys, File Keys, and Share Keys are isolated through layered derivation; file bodies and selected metadata are protected together; sharing and save-to-drive use key rewrapping to limit account key exposure; Range mapping and a local decryption proxy keep large-file playback and resumable transfers usable; and the shared core keeps behavior consistent across devices. For a cloud storage product, security and usability have to work together, and Vault is designed around that balance.