NDEVR OWL · Security
OWL Encryption.
Security, clearly scoped.
OWL encrypts content and shares its keys with authorized recipients. For private links, client-side decryption (CSD) keeps decryption on the recipient’s device; server-side decryption (SSD) gives the server the key needed to deliver plaintext. End-to-end confidentiality also depends on how keys reach the recipient, the recovery method, and the software running on each device.
Separate access and decryption
The private CSD retrieval API receives an Access Key and returns encrypted data. The recipient uses a separate Link Key to unlock it locally.
Recovery you control
Current recovery uses a recovery key you save yourself. The server stores an encrypted account-key envelope, not your recovery key.
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
OWL’s content and key-encryption formats use AES-128 and AES-256 ciphers, combined with elliptic-curve key exchange for sharing.
Symmetric encryption. The same key encrypts and decrypts. Protecting that key, the devices holding it, and the way it is shared is as important as the cipher.
Separate authorization from decryption. The Access Key authorizes server delivery. The Link Key decrypts the wrapped Content Key. These are different secrets with different jobs.
Encryption and integrity. AES-GCM detects ciphertext tampering using an authentication tag. AES-CBC alone does not; key size cannot substitute for authenticated encryption.
Recipient-specific key sharing. New recipient key wraps use ECIES over P-256, HKDF-SHA256 and AES-256-GCM. Password-protected account private keys use PBKDF2-HMAC-SHA256 with 600,000 iterations and AES-256-GCM. Older compatible envelopes remain readable.
Current formats and compatibility
OWL supports whole-file and segmented AES-256-GCM resource formats as well as older AES-256-CBC files. The stored file version determines its format; opening an older file does not automatically re-encrypt it. Private-link Content Keys are currently wrapped with AES-128-CBC. Chat also retains CBC message bodies, so authenticated key wrapping does not mean every payload is already GCM. Read about CBC and GCM.
The complete path
OWL Link overview
Follow the private-link CSD API flow, assuming the recipient already has the link locally and no usable decryption key has been disclosed to the provider. See the browser-link and recovery boundaries below. Use Play all for the complete sequence, or move through it one step at a time.
Step by step
Creating an OWL link
A private OWL link carries two secrets: an Access Key for authorization and a Link Key for decryption. A separate Content Key encrypts the file. During private-link creation, the server receives the Access Key, encrypted key material and permission metadata. When the link is read, CSD unlocks content locally; 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. The client encrypts the file before upload. Confidentiality from the provider requires keeping usable decryption keys on authorized devices, including during sharing and recovery.
🔑 Content encrypted on the client
Content Key encrypted
The Content Key is itself encrypted with a unique Link Key (AES-128). For private-link creation, the encrypted Content Key, Access Key and permission settings go to the server. The client retains the Link Key; owner and recipient copies can be stored in encrypted ECIES envelopes.
📦 Server holds encrypted key
OWL link minted
The client encodes the Access Key, Link Key, server address and permission identifier into an OWL Link. The server stores the permission rules. Treat the complete link as a secret: a holder can request the access that its current rules allow.
🔗 Link Key travels in the linkAfter creation, who holds what?
📦 Server holds
- Encrypted content
- Encrypted Content Key
- Access Key verifier, permission rules and encrypted recipient key copies
🔑 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.
Private-link creation does not require the plaintext Link Key or Content Key. The server does receive the Access Key and sharing metadata.
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’s client reads the server address, permission identifier, Access Key and Link Key. The server checks the Access Key and current permission rules before authorizing delivery.
Key decryption
The SSD or CSD path determines where the Content Key is unlocked. The Access Key is checked against its stored bcrypt verifier; it is not the key that decrypts the content.
Content decrypted
The content is decrypted on the server (SSD) or on the client (CSD). Server permissions govern delivery; restrictions in a viewer cannot prevent an authorized recipient from retaining plaintext.
SSD vs CSD: how steps 2 & 3 differ
Key decryption. After authorization, the client supplies decryption key material to the server so it can unlock the requested content. Choosing SSD therefore trusts the provider with the requested content.
Content decryption. The server decrypts with the Content Key, delivers the plaintext over HTTPS. 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 Access Key against its bcrypt verifier and returns the encrypted Content Key. The client uses the separate Link Key to unlock it locally.
Content decryption. The server authorizes the request using the link’s access credentials and permissions, then returns the encrypted content. The client decrypts it locally; this retrieval API does not need the plaintext Content Key.
Security guarantees
The owner controls future server delivery and sharing policy.
The private CSD retrieval API does not require a usable decryption key. Keeping that key private also depends on link delivery, recovery and endpoint security.
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
Compare the configuration, not just the brand. Client-side encryption, recovery, sharing and provider access vary by product, plan and settings. Reviewed ; the linked vendor documentation describes each service’s own claims.
| Service | Content encryption option | What to check |
|---|---|---|
| NDEVR OWL | Client-side encryption and private CSD retrieval; SSD is a separate provider-trust path. | Link delivery, recovery method, recipient devices and the file’s encryption format. See OWL’s trust boundaries. |
| Dropbox | Offers end-to-end encrypted team folders on supported plans. | Selected folders and supported clients; collaboration features differ from ordinary folders. Dropbox documentation. |
| Google Drive | Eligible Google Workspace organizations can enable client-side encryption. | Administrator setup, key-service access and supported workflows; this is distinct from ordinary Drive encryption. Google documentation. |
| iCloud Drive | Advanced Data Protection adds end-to-end encryption for iCloud Drive where available. | Enablement, recovery arrangements, sharing participants and metadata that remains provider-readable. Apple documentation. |
| Tresorit | Describes its file service as end-to-end encrypted with client-held keys. | Review the chosen sharing and account-management workflow. Tresorit security overview. |
| Sync.com | Offers end-to-end encrypted storage and sharing. | Check server-side processing settings. Its terms say email-based password recovery uses escrow and is not strictly zero-knowledge when enabled. Sync terms. |
| Email attachments | Protection depends on the mail system and any separate message or file encryption. | HTTPS or mail transport encryption alone does not keep attachment contents from mailbox providers or recipients. |
Encryption alone does not establish suitability for a particular sensitive-data workflow. Consider key custody, access controls, device security and recovery together.
Additional information
Server-side vs client-side decryption
These modes describe where content is decrypted. CSD decrypts on the recipient’s device; SSD lets the provider decrypt the requested content. CSD can support end-to-end confidentiality when usable keys stay with authorized endpoints. It does not, by itself, establish that every way of delivering a link or recovering an account keeps those keys private.
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. Provider confidentiality also requires private key delivery and user-held recovery keys. |
| What if the server is hacked? | Stored files remain encrypted, but an attacker present during a request could observe SSD keys or plaintext. | A stolen ciphertext store alone does not reveal content without usable keys. A compromised service can also target browser-delivered software or key-bearing link requests; see the boundaries below. |
| 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 | When the workflow needs server-side decryption and you accept the provider handling plaintext. | When you want decryption on authorized devices and can protect those devices and the key-delivery path. |
| Secure during download? | Yes — decrypted on the server, then re-encrypted in transit to the client (HTTPS). | Content stays encrypted until the client decrypts it. HTTPS also protects requests and metadata 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. |
| Provider trust | The provider handles usable keys and plaintext during delivery. | The content-retrieval API can operate without decryption keys. Link delivery, client software and recovery still matter. |
Names and metadata. Private storage encrypts file and folder names, types, descriptions, categories, exact original sizes, source timestamps, folder structure and version manifests on your device. Authorized devices decrypt the catalog to browse and organize files. Account records, access grants, billed storage, ciphertext lengths and network activity remain separate service data. Older files receive the current protection when moved to private storage. See the privacy policy for the scope.
Account access
Recovery with a key you keep
Current recovery encrypts your account private key on your device under a separate, randomly generated recovery key. You save that recovery key; the server stores only the encrypted envelope.
Recover locally
An emailed reset code authorizes retrieval of the recovery envelope. Your saved recovery key unlocks it on your device, where the private key is protected again with your new password. The email code alone cannot decrypt that envelope.
Keep zero-knowledge recovery
Enabling recovery does not give NDEVR a usable account key. Only your saved recovery key can open the recovery envelope; the email reset code alone cannot decrypt it.
Keep a separate copy
Save your recovery key outside the account it unlocks. If you lose the password, recovery key and all usable signed-in access, the provider cannot use the current recovery envelope to reconstruct your private key.
Sign-in and content encryption are separate layers. The web sign-in flow supports OPAQUE. Password-derived encryption still protects the account’s private-key envelope on the client.
Private-link trust boundaries
Follow the key all the way to the recipient
Opening a browser link. Current OWL URLs carry both link secrets in the ?a= query parameter. Navigating to that URL sends the token to the HTTPS endpoint, even when subsequent content decryption happens in the browser. HTTPS protects it in transit, but does not hide it from that endpoint. This browser-link path therefore needs provider trust and is not a strict provider-blind delivery path.
Client software and devices. A client that already holds the link can request encrypted content using only the Access Key. That separation depends on trusted client software and secure devices. A compromised web service can alter the JavaScript it delivers; CSD does not remove that risk.
Retention and revocation. Revoking a link blocks later authorized server delivery. It cannot erase copies or keys already saved, and removing a viewer’s export button cannot make readable content impossible to copy.
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.
The 16-byte Link Key wraps the file’s Content Key with AES-128-CBC. A separate 16-byte Access Key authorizes retrieval. Server access checks can stop future delivery, but cannot stop offline attempts against ciphertext someone already possesses. CBC wrapping does not add an authentication tag.
File Content Keys are 32 bytes. OWL supports authenticated AES-256-GCM formats, including segmented formats for streaming. The release target is authenticated encryption throughout; integration across all writers is still in progress. The mode and correct key handling matter as well as key size; a larger key does not make an unauthenticated format tamper-proof.
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 — hashing, access verifiers and password-derived encryption keys. →
End-to-End & Zero-Knowledge
What it means to keep content keys on endpoints, and why the whole key-delivery path matters. →
Choose where your keys are trusted.
For private content, use client-side decryption, protect the complete link and recipient devices, and keep your recovery key somewhere you control. Use SSD when you intentionally trust the provider to handle plaintext.