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 file you store passes through this exact sequence — on every product, every time.

  1. Key Generation

    Your key is derived on your device

    Before anything is encrypted, a symmetric key is derived from your passphrase using PBKDF2 (310,000 iterations, SHA-256) or Argon2id where supported. The key lives in memory on your device and is never transmitted — not during setup, not during use, not ever.

    Algorithm: PBKDF2-HMAC-SHA256 · 310,000 iterations
    Output: 256-bit AES key
    Salt: Cryptographically random, 128-bit, stored alongside ciphertext

  2. Local Encryption

    Files are encrypted before they leave your device

    The file is encrypted with AES-256-GCM. A unique, randomly generated 96-bit IV is used per file — reusing IVs is a known attack vector, so we generate them fresh every time. GCM mode provides authenticated encryption: tampering with the ciphertext will be detected on decryption.

    Algorithm: AES-256-GCM
    IV: 96-bit, cryptographically random per file
    Auth tag: 128-bit (GCM) — detects any byte-level tampering

  3. Secure Transit

    Only ciphertext travels the network

    The encrypted blob is transmitted over TLS 1.3. Our servers receive a stream of bytes that is mathematically indistinguishable from random noise. No metadata about the file's content is derivable from what we receive. We do not log content fingerprints or attempt to analyze upload patterns.

    Transport: TLS 1.3 (TLS 1.2 disabled)
    What we receive: IV + ciphertext + auth tag — no plaintext, no key material
    What we see: file size, timestamp, vault ID

  4. Blind Storage

    We store bytes we cannot read

    The ciphertext is written to disk. Without your key, these bytes are permanently and mathematically unreadable — to our infrastructure, our staff, law enforcement under subpoena, and any attacker who breaches our servers. We are not a trusted custodian. We are a dumb byte conduit.

    Stored: IV + ciphertext + auth tag
    Not stored: key, passphrase, plaintext, or any derivation of the above
    Breach result: attacker gets encrypted bytes — computationally useless without your key

Specifications

Cryptographic primitives

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

Component Algorithm Parameters Note
Symmetric encryption AES-256-GCM 256-bit key · 96-bit IV · 128-bit tag AEAD — provides both confidentiality and integrity
Key derivation PBKDF2-HMAC-SHA256 310,000 iterations · 128-bit salt OWASP minimum 2024; Argon2id used where available
Key derivation (mobile) Argon2id m=65536 · t=3 · p=4 Memory-hard; resists GPU/ASIC brute-force
Transport TLS 1.3 ECDHE + AES-256-GCM / ChaCha20 TLS 1.0–1.2 disabled on all endpoints
IV generation CSPRNG 96-bit · unique per file OS-provided entropy (WebCrypto / SecureRandom / CryptoKit)
MAC / integrity GCM auth tag 128-bit · per ciphertext Decryption fails if any byte is tampered
Key storage (device) Keychain / KeyStore Platform secure enclave iOS Keychain / Android Keystore / OS Credential Manager

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.

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