Source-available client-side encryption engine for CipherDrive™.

CipherDrive™ exists because digital privacy should not depend on corporate promises, private infrastructure diagrams, or marketing language that users cannot verify.

Clouds you cannot audit are just someone else's computer scanning your life.

This repository is our answer to that problem.

The CipherDrive™ Cryptographic Engine™ is the browser-side cryptographic engine that powers CipherDrive's zero-knowledge file storage model. It is responsible for master key generation, file key wrapping, encrypted metadata, chunk encryption, browser-side key persistence, and public share key handling.

Its purpose is simple and non-negotiable:

to make it mathematically impossible for Ackaia Corp. to read, index, profile, or leak the plaintext contents and sensitive names of user files from our servers.

Ackaia servers receive encrypted blobs, encrypted key material, operational metadata, and nothing that should be sufficient to reconstruct a user's private files. The trust boundary is intentionally pushed to the client, where encryption happens before upload and decryption happens after download.

This repository exists so developers, security researchers, customers, and privacy-conscious users can inspect the engine directly instead of trusting a black box.

It is not a decorative transparency artifact. It is part of our engineering contract with the people who use CipherDrive™.

CipherDrive™ encrypts sensitive file material in the client before upload:

• file contents are encrypted in the browser;
• file names are encrypted in the browser;
• file keys are generated in the browser;
• the user's vault secret is never sent to Ackaia servers;
• Ackaia servers store encrypted blobs and encrypted key material only.

The engine is designed around the principle that server-side compromise should not automatically become user-data compromise. A database leak, object storage exposure, internal operator mistake, or backend application failure should not grant access to plaintext user files.

That is the practical meaning of zero-knowledge in CipherDrive™:

Ackaia can store the vault. Ackaia can synchronize the vault. Ackaia can enforce quotas and transfer limits. Ackaia cannot open the vault.

Want to see this engine running in real time?

Open a free 5GB Sovereign Vault on CipherDrive™ and inspect the cryptographic calls in your browser console.

CipherDrive™ is the production environment powered by this engine. The repository is source-available so the implementation can be reviewed, questioned, tested, and compared against what the product claims publicly.

Our privacy page should never ask for blind trust. This code is where that trust is earned.

Zero-knowledge does not mean the local device is magically safe. If the browser, page runtime, extension environment, or operating system is compromised, local key material can be exposed. CipherDrive™ may persist the master key in IndexedDB for usability. That keeps Ackaia servers zero-knowledge, but it makes the user's browser a trusted local key store until the local key is cleared.

git clone https://github.com/ackaiacorp/ackaia-one-crypto-engine.git
cd ackaia-one-crypto-engine
npm test

The package is ESM-only and has no runtime dependencies for the core engine. Vue is only needed if you use the optional compatibility adapter.

import { createAckaiaOneCryptoEngine } from '@ackaia/one-crypto-engine';

const crypto = createAckaiaOneCryptoEngine();

const { key: masterKey, exportedKey } = await crypto.generateMasterKey();
const wrapped = await crypto.wrapMasterKey(masterKey, 'correct horse battery staple');

const fileKey = await crypto.generateFileKey();
const wrappedFileKey = await crypto.wrapFileKey(fileKey, masterKey);

const encryptedName = await crypto.encryptMetadata('contract.pdf', fileKey);
const decryptedName = await crypto.decryptMetadata(encryptedName, fileKey);

For the existing Laravel + Vue/Inertia application, import the adapter:

import { useStorageCrypto } from '@ackaia/one-crypto-engine/vue';

const {
  generateMasterKey,
  encryptMetadata,
  encryptChunk,
  decryptChunk,
  saveKeyToDevice,
} = useStorageCrypto();

The adapter preserves the established composable-style API used by the production Laravel + Vue/Inertia application while delegating cryptographic operations to the engine's audited core classes.

Compatibility is kept at the application boundary. Cryptographic behavior, protocol constants, key derivation, wrapping, metadata encryption, and chunk operations remain centralized in the engine.

That means existing product surfaces can remain stable while the underlying security model continues to evolve with production-grade discipline.

src/
  core/                  encoding, canonical JSON, errors
  crypto/                WebCrypto provider and crypto primitives
  storage/               browser key persistence
  adapters/vue.js        optional Vue compatibility layer
  engine.js              public facade
  protocol.js            public protocol constants

Core classes:

• WebCryptoProvider — runtime boundary for crypto.subtle and random bytes.
• AesGcmCipher — AES-GCM operations with protocol-bound AAD and compatibility support for historical ciphertext formats.
• VaultKdf — PBKDF2-HMAC-SHA256 key derivation.
• MasterKeyVault — master key generation, wrap, and unwrap.
• MetadataCrypto — encrypted file/folder names.
• FileKeyCrypto — per-file key generation and wrapping.
• ChunkCrypto — chunk IV derivation and encrypted chunk operations.
• IndexedDbKeyStore — local browser persistence for UX.
• AckaiaOneCryptoEngine — stable public facade.

The engine is intentionally small, explicit, and dependency-light. The core cryptographic boundary is built on WebCrypto primitives exposed by the browser, not on opaque runtime dependencies.

The public facade is stable by design. Internal classes keep responsibilities separated so the protocol can be reviewed without navigating a large application codebase.

• AES-GCM-256.
• 96-bit IVs.
• 128-bit authentication tags.
• PBKDF2-HMAC-SHA256 with 600,000 iterations for new vault wraps.
• Compatibility unwrap support for vaults created with the earlier 100,000-iteration PBKDF2 policy.
• Chunk IV format: 64-bit random file nonce + 32-bit big-endian part number.
• New ciphertexts use Additional Authenticated Data (AAD).
• Compatibility support is retained so existing user data remains readable.

The protocol favors conservative, well-understood primitives over novelty. CipherDrive™ does not rely on proprietary encryption, invented ciphers, or security through obscurity.

New vault wraps use the stronger 600,000-iteration PBKDF2 policy. Historical vault compatibility exists to ensure that user data created under earlier production settings remains perfectly legible without weakening the security posture of newly wrapped material.

In other words: the engine treats user data durability as a security requirement, not as technical debt.

See docs/protocol.md for more details.

Client-side encryption does not hide all metadata. Ackaia servers may still see account identity, object IDs, object type, encrypted object size, upload/download times, transfer usage, folder relationship IDs, sharing status, and operational security events. See docs/metadata-leakage.md.

This engine is built to support a specific claim:

CipherDrive™ should be able to operate the storage platform without possessing the information required to decrypt user files.

That claim depends on several concrete engineering choices:

• key material is generated in the browser;
• file encryption happens before upload;
• metadata encryption happens before upload;
• vault secrets are not transmitted to Ackaia servers;
• per-file keys are wrapped instead of stored in plaintext;
• chunk encryption uses deterministic protocol structure without reusing the full AES-GCM IV for different chunks;
• authenticated encryption is used so ciphertext integrity is verified during decryption;
• compatibility behavior is explicit rather than hidden.

This is the foundation of digital sovereignty in CipherDrive™.

Users should not need permission from a platform to keep private things private. Developers should not need to reverse-engineer a product to know whether its privacy claims are real. Security researchers should not be asked to audit a slogan.

The code should be inspectable.

This repository is published for transparency, inspection, and technical trust. It allows the community to understand how the CipherDrive™ cryptographic model is implemented and to evaluate whether the product behaves consistently with its privacy promises.

It is not published as an open-source package for unrestricted reuse.

Ackaia Corp. believes that privacy infrastructure should be auditable, but also that production security components deserve clear ownership, version control, and responsible distribution.

See LICENSE.md.

This repository is source-available, not open source. See LICENSE.md.