OWL Encryption

Proveably Secure

This article will discuss the methods implemented by the OWL method to ensure your data is secure, the security guarantees made when using the OWL sharing method, and details of the method itself from a security point of view.

OWL Key Encryption

All encryption performed below uses the industry standard AES-128 or AES-256.

Symmetric encryption: The same key is used for both encryption and decryption; confidentiality depends entirely on how the OWL link is shared and saved.
Strong confidentiality: brute-force attacks on a AES key are computationally impossible with current or near-future technology.
No known practical attacks: There are no effective attacks against AES-128 or AES-256 in real-world settings. Known theoretical attacks require assumptions that are not applicable to OWL.

Cypher Block Chaining

CBC (Cipher Block Chaining) is a method used with AES encryption to make the data even more secure. CBC adds a layer of protection by mixing each part with the one before it. This means that even if two pieces of information are the same, their encrypted versions will look completely different, helping to hide patterns and keep your data safe from attackers

OWL Link Creation

There are many settings that can be used to generate an OWL link. The ones relevant to this article involve choosing server-side decryption (SSD) or client-side decryption (CSD). This is covered more in depth later in the article. Regardless of the permissions selected, the OWL link generation process remains the same.

1) Content Encrypted

Project content is encrypted by owner who holds the only key that can be used decrypt the data (Content Key AES-256). This data is sent to the server without the Content Key, meaning the server does not have the ability to decrypt the content.

2) Content Key Encrypted

The Content Key is then encrypted by the content owner with a second Link Key (AES-128) that is unique to each OWL link. The encrypted Content Key is sent to the server without the Link Key along with permission data (What capabilities should someone with the Link Key have) along with the information for whether to use SSD or CSD.

3) OWL Link

The Link Key and permissions along with the address of the data is then encoded OWL Link by the client. The link can be shared with anyone, and by doing so, will grant them the permissions.

Link Creation Security Guarantees

– Permission can be granted or revoked independently of the content uploaded.

– The server never gets access to the content throughout the OWL Link generation process

– The owner always has rights to the content and ownership to any links to the content, meaning permission can be removed at any time by the owner.

Server Holds

Encrypted Content

Encrypted Content Key

Owner Holds

Content Key, which can be used to generate additional OWL Links, or new versions of the content.

OWL Link (Which can be shared)

Reading OWL Link

When an active OWL Link is shared, recipients are ensured access to the data with the permissions granted by the owner.

1) OWL Link

The OWL Link is read in by the indented recipient. The link contains the URL to the correct OWL server along with the Link Key needed to decrypt the Content Key. The server and the client will verify their records independently and confirm a match in permissions and settings.

2) Key Decryption

Key decryption behavior depends on whether the owner opted to use server-side decryption (SSD) or client-side decryption (CSD) when creating the OWL link.

To prevent repeated attacks, the server will block repeated attempts to access data with an incorrect Link Key.

SSD

The client will send the Link Key to the server and the server will validate the key’s authenticity, unlock the Content Key and move to the next step

CSD

The server will validate that the user is holding the Link Key via a hash validation, and if so, send the Encrypted Content Key to the client. At this point the client will decrypt the Content Key and move to the next step.

3) Content Decrypted

SSD

The server will use the Content Key to decrypt the data and, send the data in a way that ensures the recipient permissions. All unencrypted data is purged from the server after sending the data.

CSD

The server will validate that the user is holding the Content Key via a hash validation, and if so, send the Encrypted Content to the client. The client will then decrypt the content and permissions will be enforced client-side.

Link Access Security Guarantees

Owner of content retains full control of the data
For CSD, the OWL Server never has the ability to decode the data contents.
For SSD, the client never has the ability to decode the data contents and can only access the data with permissions granted to them.
OWL Links can be revoked at any time without the need to delete the original data.

Comparing Against Other Storage Options

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+RSA	❌ No	❌ No	✅ Yes	✅ Yes	⚠️ Limited	❌ No (unless manually encrypted)
Granular Key-Based Permissions	✅ Per file + user	⚠️ Basic sharing	⚠️ Basic sharing	✅ Folder-level	✅ File-level	⚠️ Limited	❌ No
End-to-End Encryption (E2EE)	✅ Fully E2EE	❌ No	❌ No	✅ Yes	✅ Yes	❌ No	❌ No
Offline Decryption Possible	✅ Yes	❌ No	❌ No	✅ Yes	✅ Yes	⚠️ Limited	✅ Yes (if manually decrypted)
Metadata Protection	✅ Optional	❌ No	❌ No	⚠️ Partial	✅ Yes	❌ No	❌ No
File Content Scanning	❌ No	✅ Yes	✅ Yes	❌ No	❌ No	✅ Yes	✅ Yes (spam/virus scans)
Open Source Cryptography	✅ Yes	❌ No	❌ No	⚠️ Proprietary	⚠️ Proprietary	❌ No	❌ No
Third-Party Key Sharing	✅ RSA delegation	❌ No	❌ No	⚠️ No native support	⚠️ No native support	❌ No	❌ No
Suitable for Sensitive Data	✅ Yes	⚠️ Limited	⚠️ Limited	✅ Yes	✅ Yes	⚠️ Limited	❌ Strongly discouraged

Additional Information

Server-Side Decryption Vs Client-Side Decryption

When it comes to sharing encrypted data, there are two ways to share OWL Files, each with specific security guarantees. While data is always stored securely, at some point it must be decrypted using the decryption key. In this instant, the content decryption key is exposed to decrypt the content for viewing or editing. The ability to perform this decryption can either happen directly on the OWL server, or client side, ensuring that the other side never has access to the original decryption key. By default, we try to select the right model depending on how the data is shared (read-only vs editing permissions) but allow the user to select the model that best fits their needs.

Benefits of Each Model

	Server-Side Decryption (SSD)	Client-Side Decryption (CSD)
Who can read my data?	The OWL service provider (server) decrypts the data when a decryption key is sent via client request.	Only you (or people you share keys with) can read your data — the OWL provider could not.
What if the server is hacked?	Hackers would only get encrypted files that are useless without your OWL key. However, when a client requests for the file, hackers could potentially monitor the server decryption process.	Hackers would only get encrypted files that are useless without your OWL key. Since the password to decrypt is not sent, there is never any ability to read data.
What if the client is hacked?	No risk after revoking their permission. The ability to decrypt the data is never shared with the client.	The client could use the shared OWL link to determine the data encryption key and gain client-only editing abilities for the data shared.
When to use	You trust the OWL Service Provider over the project collaborators / clients. The NDEVR OWL server can always be trusted as a hardened solution, but third-party servers may be less secure.	You trust the project collaborators / clients over the OWL Server Provider.
Is this secure during download?	Yes — decrypted on server but re-encrypted during transfer to client (e.g., HTTPS).	Yes — data is not decrypted before it arrives on the client device, so it’s secure even in transit.
Is this secure during upload?	Yes — encrypted during transfer and OWL encryption key encrypted to your account.	Yes — data is encrypted before it leaves your device, so it’s secure even in transit.
Is my data private by default?	Yes — the default is private and unreadable to anyone without the OWL Link.	Yes — the default is private and unreadable to anyone without the OWL Link.

AES128 vs AES256

We use AES-128-CBC for encrypting access links primarily because it offers a strong balance between security and efficiency, particularly for compact, server-validated tokens. These links contain authorization information that the server validates before any sensitive file data is sent, and thus their cryptographic exposure limited. The 128-bit key size is sufficient for resisting brute-force attacks within this context while allowing for smaller encrypted payloads, which is critical for maintaining reasonable URL or token sizes.

In contrast, we use AES-256-CBC for encrypting the files themselves, which are intended to remain secure for long periods — potentially years, decades, or millennia. The larger key size provides stronger future-proofing against cryptographic advances and offers higher entropy per key, which is especially important for long-term storage of sensitive data. This separation allows the system to optimize for speed and payload size in link-based access, while prioritizing maximum confidentiality and durability in stored file data.