CipherDrive™ uses AES-GCM as a documented authenticated-encryption primitive for file contents, metadata, and key material.
AES is a widely used symmetric encryption algorithm. GCM, or Galois/Counter Mode, is a mode of operation that adds authentication to encryption.
In practical terms, AES-GCM is designed to provide:
confidentiality: plaintext is hidden without the required key;
integrity/authentication: modified ciphertext should fail verification rather than being silently accepted.
Encryption alone is not enough if an attacker can alter ciphertext and the application cannot reliably detect that change.
With authenticated encryption, the client verifies an authentication tag during decryption. If the key, IV, ciphertext, or authenticated context is wrong, decryption should fail.
AES-GCM requires an initialization vector, or IV. The IV is not a password and does not need to be secret, but it has a critical requirement: the same IV must not be reused with the same key.
The CipherDrive whitepaper uses 96-bit IVs in its documented chunk construction, consistent with the common AES-GCM recommendation.
Reusing an IV with the same AES-GCM key can seriously compromise confidentiality and integrity. For that reason, CipherDrive's protocol must carefully generate or construct unique IVs for encryption operations under a given key.
CipherDrive may use Additional Authenticated Data, or AAD, to bind encrypted content to its intended context.
AAD can include non-secret information such as:
protocol version;
object type;
chunk number;
file identifier.
AAD is not encrypted, but it is authenticated. If the expected AAD does not match during decryption, authentication fails.
Using a strong cipher does not automatically make a storage system secure. CipherDrive must also correctly manage:
key generation;
key derivation;
key wrapping;
IV uniqueness;
randomness;
metadata authentication;
protocol versioning;
error handling;
endpoint security.
Security comes from the protocol, not merely the algorithm name.