NDEVR OWL · Security
OWL Encryption.
Security, clearly scoped.
With provider-held recovery disabled, OWL gives encrypted resource and chat content a zero-knowledge, end-to-end path with client-side decryption (CSD). Server-side decryption (SSD) and recovery are explicit provider-trust options. Here's exactly how those boundaries work.
Zero-knowledge in CSD
For CSD resource and chat content with provider-held recovery disabled, the server stores ciphertext and receives no usable content key.
End-to-end in recovery-disabled CSD
Files are sealed on your device before upload and stay sealed until an authorized recipient unlocks them locally.
Stop future access
Revocation stops later server delivery and key fanout. It cannot erase plaintext, keys or ciphertext a recipient already retained.
The building blocks
OWL key encryption
All encryption in OWL uses the industry-standard AES-128 and AES-256 ciphers, combined with elliptic-curve key exchange for sharing.
Symmetric encryption. The same key encrypts and decrypts; confidentiality depends entirely on how the OWL link is shared and saved.
Strong confidentiality. Brute-forcing an AES key is computationally infeasible with current or foreseeable technology.
No known practical attacks. There are no effective real-world attacks on AES-128 or AES-256; known theoretical attacks rely on assumptions that don't apply to OWL.
Recipient-specific key sharing. Keys for specific recipients are wrapped with ECIES over P-256 and sealed with AES-256-GCM (HKDF-SHA256); password keys use PBKDF2-HMAC-SHA256. In CSD with provider-held recovery disabled, the server has no usable recipient or content key.
Cipher Block Chaining (CBC)
CBC turns AES into a multi-block encryption mode by mixing each block with the one before it. With a fresh, unpredictable IV, identical content encrypts differently. CBC does not authenticate ciphertext by itself, so integrity requires separate protocol checks.
The complete path
OWL Link overview
See the recovery-disabled client-side decryption path from local key creation to the recipient’s locally decrypted content. Use Play all for the complete sequence, or move through it one step at a time.
Step by step
Creating an OWL link
When you share content, OWL builds a link through a two-key encryption process. At creation, the server receives ciphertext and an encrypted Content Key, not the usable keys. When the link is read, client-side decryption (CSD) preserves that boundary; server-side decryption (SSD) intentionally gives the provider the key needed for delivery.
Content encrypted
Your content is encrypted with a Content Key (AES-256) held by authorized endpoints. On the CSD path, ciphertext is sent without a usable key, so the server cannot decrypt it. Optional recovery changes that boundary by letting the operator recover account-wrapped keys.
🔑 CSD key stays on authorized endpoints
Content Key encrypted
The Content Key is itself encrypted with a unique Link Key (AES-128). The encrypted Content Key, the permissions, and the SSD/CSD choice go to the server — the Link Key does not.
📦 Server holds encrypted key
OWL link minted
The client encodes the Link Key, the permissions, and the data address into an OWL Link. Share the link with anyone, and you grant them exactly those permissions.
🔗 Link Key travels in the linkAfter creation, who holds what?
📦 Server holds
- Encrypted content
- Encrypted Content Key
🔑 Owner holds
- The Content Key — used to mint additional links or new versions
- The OWL Link, which can be shared
Security guarantees
Future server delivery can be granted or revoked independently of the uploaded content.
During link generation, the server receives only encrypted content and an encrypted Content Key.
The owner controls future link authorization; recipients may still retain content or keys already delivered to them.
On the other side
Reading an OWL link
When an OWL link is active, the server delivers it according to the owner's current permissions. Once content reaches an authorized endpoint, no sharing system can make that recipient forget plaintext or keys they retained.
Link read
The recipient opens the OWL Link, which carries the server URL and the Link Key needed to decrypt the Content Key. Client and server independently verify their records and confirm matching permissions.
Key decryption
Behavior depends on the owner's SSD or CSD choice (see toggle below). To stop brute-force attempts, the server blocks repeated tries with an incorrect Link Key.
Content decrypted
The content is decrypted — on the server (SSD) or on the client (CSD) — and delivered with the granted permissions enforced.
SSD vs CSD: how steps 2 & 3 differ
Key decryption. The client sends the Link Key to the server; the server validates it and unlocks the Content Key. Choosing SSD therefore trusts the provider with the requested content.
Content decryption. The server decrypts with the Content Key, delivers the plaintext over HTTPS and discards its transient plaintext after the response. SSD is encrypted at rest and in transit, but is not zero-knowledge or end-to-end against the provider.
Key decryption. The server validates the Link Key via a hash check and returns the encrypted Content Key. The client decrypts the Content Key locally.
Content decryption. The server validates the client holds the Content Key via a hash check, then returns the encrypted content. The client decrypts it and enforces permissions client-side.
Security guarantees
The owner controls future server delivery and sharing policy.
For CSD with provider-held recovery disabled, the OWL Server receives no usable key with which to decode the protected payload.
For SSD, the provider can decode each requested delivery and must be trusted with that plaintext.
Revocation blocks later retrieval and key delivery; it cannot retract plaintext, keys or ciphertext already received.
How it stacks up
Comparing against other storage options
Most consumer cloud storage keeps provider-readable keys. OWL's CSD path, with provider-held recovery disabled, is designed so the provider cannot read encrypted resource content; SSD and recovery deliberately trade that property for provider access.
| Feature | NDEVR OWL | Dropbox | Google Drive | Tresorit | Sync.com | iCloud Drive | Email Attachments |
|---|---|---|---|---|---|---|---|
| Zero-Knowledge Encryption | ✅ Recovery-disabled CSD content | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Client-Side Encryption | ✅ AES-256 + ECIES | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ⚠️ Limited | ❌ No |
| Granular Key-Based Permissions | ✅ Per file + user | ⚠️ Basic | ⚠️ Basic | ✅ Folder-level | ✅ File-level | ⚠️ Limited | ❌ No |
| End-to-End Encryption | ✅ Recovery-disabled CSD content | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Offline Decryption | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ⚠️ Limited | ✅ Yes |
| Metadata Protection | ⚠️ Content only | ❌ No | ❌ No | ⚠️ Partial | ✅ Yes | ❌ No | ❌ No |
| No File Content Scanning | ⚠️ CSD content unreadable | ❌ Scanned | ❌ Scanned | ✅ Never | ✅ Never | ❌ Scanned | ❌ Scanned |
| Open-Standard Cryptography | ✅ AES · ECIES · SHA-2 | ❌ No | ❌ No | ⚠️ Proprietary | ⚠️ Proprietary | ❌ No | ❌ No |
| Third-Party Key Sharing | ✅ ECIES (P-256) | ❌ No | ❌ No | ⚠️ None native | ⚠️ None native | ❌ No | ❌ No |
| Suitable for Sensitive Data | ✅ Yes | ⚠️ Limited | ⚠️ Limited | ✅ Yes | ✅ Yes | ⚠️ Limited | ❌ Discouraged |
Additional information
Server-side vs client-side decryption
Data is stored encrypted, but it must be decrypted to view or edit. CSD with provider-held recovery disabled decrypts on the recipient's device and is the basis for OWL's end-to-end and zero-knowledge content claims. SSD sends the key to the OWL server for decryption, and recovery gives the operator an account-key recovery path; both are provider-trust modes outside the zero-knowledge path.
Benefits of each model
| Server-Side Decryption (SSD) | Client-Side Decryption (CSD) | |
|---|---|---|
| Who can read my data? | The OWL provider (server) decrypts the data when a key is sent via client request. | Authorized endpoints holding the key. With recovery disabled, the provider has no usable key; provider-held recovery changes that boundary. |
| What if the server is hacked? | Stored files remain encrypted, but an attacker present during a request could observe SSD keys or plaintext. | With provider-held recovery disabled, the server has ciphertext but no usable Content Key, so a server-only compromise cannot decrypt the protected payload. |
| What if the client is hacked? | The endpoint receives plaintext. Revocation stops later server responses, but cannot erase plaintext already retained. | The endpoint receives the Content Key and plaintext. Revocation cannot erase a retained key, ciphertext or plaintext. |
| When to use | You trust the OWL provider over collaborators / clients. The NDEVR OWL server is a hardened solution, but third-party servers may be less secure. | You trust the collaborators / clients over the OWL provider. |
| Secure during download? | Yes — decrypted on the server, then re-encrypted in transit to the client (HTTPS). | Yes — data isn't decrypted before reaching the client, so it's secure in transit. |
| Secure during upload? | Yes — encrypted in transit, and the OWL key is encrypted to your account. | Yes — data is encrypted before it leaves your device, so it's secure in transit. |
| Private by default? | Access-controlled and encrypted at rest; the provider is trusted during delivery. | Access-controlled, with encrypted content unreadable to the provider. |
Content boundary. These confidentiality claims cover encrypted resource and chat payloads in CSD. OWL still processes account, routing, sharing and resource metadata. Public authored Sites are intentionally served as plaintext web pages. Neither metadata nor public Site content is covered by the zero-knowledge claim.
Why two key sizes
AES-128 vs AES-256
OWL deliberately uses different key sizes for links and for files — optimizing each for its job.
Links carry authorization the server validates before any sensitive file data is sent, so their cryptographic exposure is limited. 128-bit keys resist brute force in this context while keeping payloads small — critical for reasonable URL and token sizes.
Files are meant to stay secure for the long term — potentially years or decades. The larger key provides stronger future-proofing against cryptographic advances and higher entropy per key, prioritizing maximum confidentiality and durability for stored data.
Go deeper
Learn how each piece works
Plain-language explainers for the cryptography behind OWL — each one referenced to the underlying standards (NIST, IETF and the original research).
What is AES?
The symmetric cipher that seals your files — AES-128 vs 256, and CBC vs GCM modes. →
Public-Key Cryptography
Public/private key pairs and the elliptic-curve P-256 keys every OWL account uses. →
What is ECIES?
How a file's key is sealed for exactly one recipient, using only their public key. →
Hashing & Key Derivation
SHA-256, bcrypt and PBKDF2 — how passwords and keys are protected one-way. →
End-to-End & Zero-Knowledge
What it means for a server to store covered CSD payloads without a usable key, and which OWL modes sit outside that boundary. →
Secure sharing, without the trust fall.
With provider-held recovery disabled, OWL gives CSD resource and chat content an end-to-end path where usable keys stay on authorized devices. Choose SSD or recovery only when you intentionally accept the provider-trust boundary.