Large files can be too expensive to process as one giant in-memory encryption operation. CipherDrive™ therefore supports a chunked encryption architecture in which a file is divided into smaller ordered pieces and each piece is encrypted locally.
Chunking allows a client to:
process large files without holding the entire file in memory;
encrypt and upload data incrementally;
track progress at a smaller granularity;
support multipart or resumable upload architecture;
download and decrypt large objects incrementally.
A file receives a random per-file key. Multiple chunks of that file can be encrypted using the same file key only if each encryption operation uses a unique IV.
The CipherDrive whitepaper describes the chunk IV conceptually as:
Chunk IV = 64-bit random file nonce + 32-bit chunk number
Each file receives a random 64-bit base nonce. Each chunk receives a unique 32-bit chunk number. Together they form a 96-bit AES-GCM IV.
For chunks encrypted under the same file key, the changing chunk number helps ensure that each AES-GCM operation uses a distinct IV.
IV uniqueness is essential because AES-GCM security can be seriously weakened if an IV is reused with the same key.
Each AES-GCM encrypted chunk includes authentication information. When CipherDrive decrypts the file, each chunk must authenticate correctly.
If a chunk is corrupted, altered, or associated with the wrong cryptographic context, the client should fail the affected decryption instead of silently accepting modified data.
Where used, AAD can bind a chunk to context such as its chunk number, file identifier, object type, or protocol version. This makes it harder to treat valid ciphertext from one context as though it belonged to another.
During download:
the file key is unwrapped locally;
encrypted chunks are retrieved;
each chunk is authenticated and decrypted;
the plaintext chunks are placed back in the correct order;
the client reconstructs the original file.
No. Chunking provides an architecture that can support resumable or multipart workflows, but actual resume behavior depends on the current client implementation and service configuration.