Cryptography

OWL is built around end-to-end, zero-knowledge encryption: your content is encrypted on your device, and our servers store only ciphertext they cannot read. This page documents the actual cryptographic primitives we use — including where we use authenticated encryption and where we don't — so you can evaluate the design rather than take a slogan on faith.

Part of NDEVR's compliance & conformity program · Background reading: our wiki on end-to-end encryption, AES, and ECIES.

Contents

  1. Symmetric encryption
  2. Public-key cryptography
  3. Hashing & key derivation
  4. In transit
  5. Standards posture
  6. Verification

1. Symmetric encryption

  • Content and stored key material: encrypted with AES-256. File contents are compressed and then sealed with AES-256 on your device before upload; per-resource keys and your wrapped private key are likewise AES-256 encrypted.
  • Authenticated encryption (AES-256-GCM): used where a malleable ciphertext would be a real risk — ECIES key wrapping, key escrow, and recipient key delivery. GCM detects tampering: any bit-flip in the ciphertext, IV, or tag makes it undecryptable. Layout is [IV(12)][tag(16)][ciphertext].
  • Integrity of content: content carries HMAC-SHA-256 keyed tags (the key is derived from your private scalar), so integrity can be verified without the server ever learning the underlying content.

We describe this precisely on purpose: bulk content uses AES-256, and authenticated GCM is applied to the key-wrapping, escrow, and ECIES paths. A legacy AES-256-CBC mode is retained in some paths for backward compatibility with older clients; new wrapping uses the authenticated GCM path.

2. Public-key cryptography

  • Key pairs: elliptic-curve NIST P-256 (ECDH for key agreement, ECDSA where signatures are needed).
  • ECIES: per-file and per-conversation keys are wrapped to each recipient's P-256 public key, so only the intended people can unwrap them. Your private key is itself wrapped with a key derived from your password before it is stored with us.

3. Hashing & key derivation

  • Passwords: a credential derived from your username and password on your device, then bcrypt (salted) server-side. Your actual password never leaves your device.
  • Hashing: SHA-256 (one-shot and streaming) for digests and download-integrity checks; HMAC-SHA-256 for keyed content tags.
  • Tokens: session, verification, and reset tokens are stored only as SHA-256 hashes; authentication and reset comparisons are constant-time.

4. In transit

All connections use TLS/HTTPS. The desktop and command-line clients pin the ISRG (Let's Encrypt) root chain; the desktop binary protocol runs over secure WebSocket (wss).

5. Standards posture

OWL uses FIPS-approved algorithm families — AES, SHA-2 (SHA-256), and ECDH/ECDSA over P-256. To be precise: these are FIPS-approved algorithms, but OWL does not currently use a FIPS 140-validated cryptographic module, and we do not claim FIPS 140 validation. If you have a FIPS 140 requirement, contact security@ndevr.org.

6. Verification

The cryptographic primitives are covered by an automated security test suite, and the same algorithms are used identically across our desktop, web, and command-line clients so that data sealed by one is readable by another.