NDEVR OWL · Security
OWL Encryption.
Security, clearly scoped.
OWL encrypts content and shares its keys with authorized recipients. Current private share links keep their capability in the URL fragment and decrypt on the recipient’s device. They have no server-side decryption fallback. 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 browser derives a lookup identifier from the fragment capability. The service returns an encrypted capsule; only the link holder can open it.
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. A signed grant authorizes encrypted delivery. The link holder’s client opens the sealed grant and uses its content key locally. The service does not receive that key.
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. Current link capsules use AES-256-GCM; signed catalog grants bind the encrypted file and its sealed key material. Chat also retains CBC message bodies, so authenticated key wrapping does not mean every payload is already GCM. Read about CBC and GCM.
Current private sharing
One link, local decryption
https://ndevr.org/s/<card>#<capability>
The path is public. The card identifier supports a limited crawler preview. It cannot unlock the file.
The fragment is secret. Browsers omit the part after # from HTTP requests. Treat the complete link as a credential: anyone receiving it may have access.
The grant controls delivery. The service checks expiry, revocation, audience and the grant chain before returning encrypted data.
The recipient decrypts. The client verifies the capsule commitment and signed grant before unlocking content locally.
Creating a link
OWL Files creates a signed catalog grant for a file version or a shared folder. The owner chooses the audience, expiry and supported access rights.
- The owner’s client prepares a delegate key and seals the grant’s private view.
- It encrypts a descriptor in an AES-256-GCM capsule. A fresh random salt contributes to the capability commitment.
- It uploads the signed grant, encrypted capsule and derived lookup identifier. The capability and capsule key stay local.
- The client returns the complete fragment-bearing URL to share with the recipient.
The old binary OWL… tokens, ?a= and #a= links, and binary .owl shortcuts are retired. Their owners must create new links after moving files into private storage. Installers use the public product catalog instead.
Opening a link
- The browser reads the capability from the fragment and derives the lookup identifier and capsule key locally.
- The service returns the encrypted capsule for a live grant. Account-only links require sign-in.
- The client decrypts the capsule, recomputes its commitment, and verifies the owner-rooted signed grant chain.
- The delegate signs authorized payload requests. The client checks ciphertext integrity and decrypts the file on the device.
File links identify a version; folder grants can provide live access. Revocation blocks later delivery. It cannot erase a recipient’s retained plaintext, keys or ciphertext.
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 local decryption of private catalog share links. Public product downloads are deliberately public. | 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.
Private sharing and public downloads
Private catalog links decrypt on the recipient’s device. Public installers, product images and IT documents are intentionally published as public bytes through /software/…. Product downloads do not mint or depend on private share links.
QUAIL and other chosen processors receive content deliberately supplied to them. Public publishing and explicit processing have different trust boundaries from private sharing.
Names and metadata. Private catalogs encrypt names, types, descriptions, exact original sizes, timestamps, folder structure and version manifests. The service still observes account and grant identifiers, billed storage, ciphertext lengths and request activity.
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 private links keep their capability after #. Browsers do not send that fragment in the HTTP request. The application sends only a derived lookup identifier and decrypts the returned capsule locally. Retired query-token links are rejected.
Client software and devices. Protecting fragment capabilities depends on trusted client software and secure devices. Anyone you give the full link to can redistribute it. A compromised web service can alter the JavaScript it delivers; Local decryption 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.
Authenticated encryption and signed grants
Current link capsules use AES-256-GCM. Private file content uses authenticated encryption; signed grants and verified catalog metadata bind the encrypted payload to its expected identity.
Recipient wrapping supports the account’s current classical or hybrid format. A short link protects its descriptor with an independent capability, while the signed grant remains the authorization boundary. The retired two-password AES-CBC link format is no longer a delivery option.
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).
Read Post-Quantum Encryption in OWL for ML-KEM-768, the difference between hybrid HTTPS and stored-key protection, and the dated application rollout status.
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. Publish through the product catalog when the download is intentionally public.