NDEVR OWL · Security
OWL Encryption.
Provably secure.
OWL is zero-knowledge and end-to-end encrypted. Your files are sealed on your device before they ever reach a server — and the server never holds the keys needed to read them. Here's exactly how it works, in plain language and in cryptographic detail.
Zero-knowledge server
The server stores only ciphertext and never holds the keys required to read your content.
End-to-end encrypted
Files are sealed on your device before upload and stay sealed until an authorized recipient unlocks them.
Revoke anytime
Access lives in shareable keys, not in the file. Revoke any link instantly — without deleting the original.
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.
Authenticated 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. Keys never reach the server.
Cipher Block Chaining (CBC)
CBC strengthens AES by mixing each block with the one before it. Even if two pieces of content are identical, their encrypted forms look completely different — hiding patterns so repeated content never reveals itself.
Step by step
Creating an OWL link
When you share content, OWL builds a link through a two-key encryption process. The server takes part in storage and delivery — but is never given the keys. Choose server-side (SSD) or client-side (CSD) decryption; the creation flow is identical either way.
Content encrypted
Your content is encrypted with a Content Key (AES-256) that only you hold. The ciphertext is sent to the server without the key — so the server can't decrypt it.
🔑 Content Key stays with you
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
Permission can be granted or revoked independently of the uploaded content.
The server never gets access to the content throughout link generation.
The owner always retains rights to the content and ownership of any links — so permission can be removed at any time.
On the other side
Reading an OWL link
When an active OWL link is shared, recipients are guaranteed access with exactly the permissions the owner granted.
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, unlocks the Content Key, and continues.
Content decryption. The server decrypts with the Content Key and delivers the data with recipient permissions enforced. All plaintext is purged from the server after sending.
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
How it stacks up
Comparing against other storage options
Most consumer cloud storage can read your files. OWL is built so it can't.
| Feature | NDEVR OWL | Dropbox | Google Drive | Tresorit | Sync.com | iCloud Drive | Email Attachments |
|---|---|---|---|---|---|---|---|
| Zero-Knowledge Encryption | ✅ Yes | ❌ 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 | ✅ Fully E2EE | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Offline Decryption | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ⚠️ Limited | ✅ Yes |
| Metadata Protection | ✅ Optional | ❌ No | ❌ No | ⚠️ Partial | ✅ Yes | ❌ No | ❌ No |
| No File Content Scanning | ✅ Never | ❌ 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 always stored encrypted, but at some point it must be decrypted to view or edit. That decryption can happen on the OWL server (SSD) or on the client (CSD) — and each side never gets the other's key. By default OWL picks the right model for how the data is shared (read-only vs editing), but you can choose the model that fits your needs.
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. | Only you (or people you share keys with) — the OWL provider cannot. |
| What if the server is hacked? | Attackers get only encrypted files, useless without your key. But while a client requests a file, attackers could potentially observe the server-side decryption. | Attackers get only encrypted files. Since the decryption key is never sent, there's never any ability to read data. |
| What if the client is hacked? | No risk after revoking permission — the ability to decrypt is never shared with the client. | The client could use the shared link to derive the data key and gain client-only editing of the shared data. |
| 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? | Yes — private and unreadable to anyone without the OWL Link. | Yes — private and unreadable to anyone without the OWL Link. |
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 your data but be unable to read it. →
Secure sharing, without the trust fall.
OWL gives you cloud convenience with end-to-end encryption and keys that never leave your control. Try the client or run your own server.