NTK / TECHNOLOGY

The math
doesn't
lie.

AES-256-GCM encryption happens on your device. Your keys never leave. Our servers receive unintelligible bytes — and that is a mathematical guarantee, not a policy.

Scroll to read the architecture

Architecture

Four steps.
Zero access.

Every protected object passes through this exact sequence — across every product, every time.

  1. Key Distribution

    Your access keys are derived in the policy plane

    Before anything is encrypted, NTK's Policy Manager derives and authorizes the distributed attribute material used for dABAC access. Those attribute assignments are delivered to the client through the ConductorAgent over a PQC-protected channel, then stored in the local policy store for enforcement. The client does not invent its own long-lived master key from a passphrase.

    Authority: Policy Manager
    Delivery: distributed attribute assignments via ConductorAgent
    Transport: Kyber-768 negotiated secure channel
    What the client receives: 256-bit attribute keys, 128-bit attribute IDs, labels, expiration data

  2. Local Encryption

    Files are encrypted on the client before they leave the device

    For each protected object, NTK generates a fresh one-time MEDK. That MEDK is wrapped under the dABAC-derived KEK using AES-KWP, and the file content is encrypted chunk by chunk with AES-256-GCM. A structured TLV header is authenticated separately so policy-linked metadata and wrapped-key context cannot be silently altered.

    Per-chunk AEAD: AES-256-GCM
    Nonce: 96-bit per chunk
    Auth tag: 16 bytes per chunk
    Header integrity: HMAC-SHA256, truncated to 16 bytes
    Key wrap: AES-KWP (RFC 5649) for the MEDK under the dABAC KEK
    Key derivation: HKDF-SHA256

  3. Secure Transit

    Only protected data travels the network

    When NTK-protected content moves across the network, what travels is the authenticated header, the wrapped MEDK, and the encrypted chunks. The access material needed to unwrap the MEDK is controlled separately through the dABAC policy plane and distributed to authorized clients over the PQC-protected assignment channel. Storage and transit layers handle protected objects, not usable plaintext.

    What travels with the object: authenticated TLV header + wrapped MEDK + encrypted chunks
    What does not travel with the object: plaintext content, raw dABAC KEK, policy-derived attribute authority
    Separate secure distribution: attribute assignments delivered over the PQC policy channel

  4. Protected Storage

    We store protected objects we cannot directly use

    The protected object is written to storage as authenticated metadata plus encrypted content. Without the correct distributed attributes, the client cannot reconstruct the dABAC KEK, unwrap the MEDK, and authenticate and decrypt the chunks. That means storage can persist and deliver the protected object, but access still depends on valid policy-derived key material at the edge.

    Stored: TLV header, header MAC, wrapped MEDK, encrypted chunks, per-chunk GCM tags
    Not stored in usable form: plaintext file contents, raw KEK material, unwrapped MEDK
    Breach result: attacker gets protected objects that still require valid dABAC-derived key material for access
// Policy Plane Ownership

You control the policy plane. We never touch it.

The Policy Manager and ConductorAgent that govern your dABAC attribute assignments run under your authority — not ours. NTK has no administrative access to your policy store, no visibility into your attribute assignments, and no participation in the Kyber-768 key negotiation used to protect the distribution channel. The communication tunnels between your ConductorAgent and your clients are established end-to-end between parties you control. NTK is not in that channel and cannot be added to it.

This means we cannot grant access to your protected objects on your behalf, cannot revoke access without your instruction, and cannot be compelled to alter your policy configuration in a way that would expose key material. The architecture makes NTK structurally incapable of acting as a silent intermediary.

Policy Manager runs under your authority
ConductorAgent tunnels are end-to-end between your clients
NTK has zero access to key material or distribution channels
We cannot grant, revoke, or intercept access on your behalf

Specifications

Cryptographic primitives

The exact algorithms and parameters we use. No marketing language — just the spec.

v1.1 Per-chunk AES-GCM AEAD + header MAC over TLVs + MEDK wrapped with AES-KWP under dABAC KEK.
v1.2 v1.1 + PQC KEM integration (ML-KEM) and encryption modes.

// Encryption Modes

Mode Description Requirements at decrypt time
ClassicOnly v1.1 behavior: MEDK wrapped only under classical dABAC KEK via AES-KWP. dABAC KEK only.
DualRail MEDK available via classical unwrap or PQC KEM decapsulation (writer stores KEM ciphertexts). EITHER dABAC KEK OR ML-KEM private key for any listed recipient.
HybridAnd MEDK wrapped under a hybrid KEK derived from classical secret ∧ PQC shared secret(s). BOTH dABAC KEK AND at least one matching ML-KEM private key.

New deployments should start with DualRail and migrate selected data to HybridAnd once PQC key provisioning is mature.

// Symmetric & MAC Primitives

Component Algorithm Parameters Note
Per-chunk AEAD AES-256-GCM 96-bit nonce · 16-byte tag AAD = full header (MAGIC ‖ HDR_LEN ‖ TLVs incl. HEADER_MAC) — ciphertext is bound to exact header and policy
Header MAC HMAC-SHA256 Truncated to 16 bytes Authenticates TLV header fields; prevents silent metadata tampering
Key derivation HKDF-SHA256 — Derives per-object and context-specific key material
Key wrap AES-KWP RFC 5649 Wraps MEDK under dABAC KEK; DualRail/HybridAnd also store ML-KEM ciphertexts
PQC KEM (v1.2) ML-KEM-768 ~1 KiB ciphertext per recipient NIST ML-KEM; aligns with future FIPS-validated modules
Randomness SP 800-90A DRBG — Provided by the underlying crypto module
Transport mTLS 1.3 PQC + AES-256-GCM TLS 1.0–1.2 disabled on all endpoints

// Operational Notes

Chunk size 64–256 KiB recommended for AES-NI/ARMv8. Smaller chunks lower latency at some cost in overhead.
Header size ML-KEM-768 ciphertexts are ~1 KiB each. Budget header size accordingly and cap recipients per file.
Key rotation Use new ML-KEM keypairs per device and rotate periodically. Writers may include multiple recipients (old + new) during transition.
FIPS 140-3 posture Classical primitives (AES-GCM, AES-KWP, HMAC-SHA256, HKDF-SHA256, DRBG) are FIPS-approved algorithms. PQC aligns with NIST ML-KEM and future FIPS-validated modules. The AES-256-GCM data path is unchanged across all modes.

Threat Model

What we protect.
What we don't.

Honest security means being precise about what the design actually prevents.

Protected
Threats this architecture defeats
  • Server breach — attacker exfiltrates our database and gets your encrypted bytes. Without your key, the bytes are computationally useless.
  • Legal order / government compulsion — we cannot produce plaintext we do not have. Our technical architecture is our legal defense.
  • Insider threat — NTK employees cannot access your data. There is no privileged admin account that can read stored files.
  • Content scanning — we receive ciphertext, not plaintext. No automated or manual content analysis is possible.
  • Silent key rotation — GCM authentication tags ensure any byte-level tampering is detected on decryption.
Out of scope
Threats outside our threat model
  • Compromised device — if malware on your device intercepts your passphrase or key before encryption, we cannot help. Device security is your responsibility.
  • Weak passphrase — PBKDF2/Argon2id increases the cost of brute-force, but a very weak passphrase remains vulnerable. Use a strong one.
  • Traffic analysis — we see file size and upload frequency. An adversary with full network visibility could infer activity patterns.
  • Key loss — if you lose your passphrase and have no recovery mechanism configured, your data is permanently unrecoverable. This is intentional.
  • Availability — we do not provide uptime guarantees against DDoS or infrastructure failure. Zero-knowledge does not mean zero-downtime.

FAQ

Common questions

No. Your files are encrypted on your device before they are transmitted. We receive ciphertext. Without your key — which we never have — the bytes are permanently unreadable. This is not a policy we could change; it is how the cryptography works.
We can produce the encrypted bytes we store. We cannot produce plaintext because we do not have it. Our architecture is our legal answer: we are technically incapable of complying with a demand to produce readable data. We will always disclose the existence of legal requests we are permitted to disclose.
If you lose your passphrase and have not configured a recovery mechanism, your data is unrecoverable — permanently. We designed it this way deliberately. A backdoor for account recovery is a backdoor for everyone. You can optionally configure an encrypted recovery key at setup; this is the only recovery path.
We use standard, well-audited cryptographic primitives from platform-native implementations (WebCrypto API, Android Keystore, Apple CryptoKit). We do not implement our own cryptography. Third-party audit engagements are planned and will be disclosed publicly when completed.
We collect: encrypted file size, upload/download timestamps, vault identifiers, and your account email. We do not collect: file names (they are encrypted client-side), file types, content fingerprints, or browsing/usage analytics beyond what is necessary for billing and abuse prevention.
Both are strong authenticated encryption schemes. We defaulted to AES-256-GCM because it has hardware acceleration (AES-NI) on all modern desktops and mobile devices, making it faster in practice. On platforms where hardware AES is unavailable, our mobile clients fall back to ChaCha20-Poly1305 automatically. The choice of cipher does not affect the zero-knowledge property.

See it in practice.

Four products. One architecture. The math works the same in every one.