Cryptography
OWL encrypts CSD resource and chat content on authorized devices. The provider stores ciphertext and wrapped keys without a usable content key. Account recovery preserves this boundary: the recovery key stays with the user. SSD deliberately gives the server a usable key for a requested delivery.
1. Symmetric encryption
- Content: per-resource keys are 256 bits. File contents are encrypted on the client before upload; CSD decrypts them on an authorized endpoint.
- Authenticated encryption: AES-256-GCM protects recipient key envelopes and password/recovery private-key envelopes. Authenticated content formats also use GCM, including segmented formats for streaming. A recipient verifies the applicable authentication tag before accepting the protected plaintext.
- Release requirement: authenticated content and key wrapping must be used throughout the supported release writers and readers. Existing GCM support alone does not prove every upload, chat, or sharing path meets that requirement.
Content encryption and content integrity are different properties. OWL does not claim that every encrypted payload carries an HMAC-SHA-256 tag. GCM provides its own authentication tag; SHA-256 digests and uses of HMAC elsewhere do not supply a missing content authentication tag.
2. Public-key cryptography
- Account keys: randomly generated NIST P-256 key pairs; ECDH establishes shared secrets and ECDSA supports signatures.
- Recipient delivery: ECIES wraps resource and conversation keys to authorized recipients' public keys, using authenticated encryption.
- Password protection: the account private key is wrapped locally under a password-derived key. Changing a password replaces that envelope; it does not require deriving all file keys again.
- Chat history: conversation keys are wrapped to each member's account key so history opens on every signed-in device. Chat therefore does not provide forward secrecy: anyone who obtains a member's account private key can read that member's past messages. Removing a member rotates the conversation key, so they cannot read anything sent afterwards. A member added with "only new messages" receives a fresh key and cannot read anything sent before they joined.
3. Trust modes
- CSD: usable content keys and plaintext stay on authorized endpoints, including when user-held recovery is enabled.
- Recovery: the device generates a 160-bit random recovery key and encrypts the account private key under a key derived from it. The server stores only the authenticated OWRK envelope. An emailed reset code authorizes retrieval; the saved recovery key is needed to decrypt it locally.
- SSD: the server receives a usable delivery key and processes plaintext for the requested delivery. It is an explicit provider-trust mode.
- Optional plaintext processing: a selected processor can read the content deliberately supplied to it, such as an AI prompt or a server-side preview request.
Protect the recovery key independently of your account. If the password, recovery key and all usable signed-in access are lost, NDEVR cannot reconstruct the private key from the stored envelopes.
4. Hashing & key derivation
The web private-key envelope uses PBKDF2-HMAC-SHA-256 with 600,000 iterations and AES-256-GCM. Its recovery envelope uses PBKDF2-HMAC-SHA-256 with 100,000 iterations over the random recovery key and AES-256-GCM. These formats have separate purposes and must not be confused with login authentication.
The web sign-in flow supports OPAQUE. SHA-256 is also used for digests and integrity checks; a digest alone does not authenticate content against an attacker who can replace it. HMAC and HKDF serve specific keyed hashing and derivation roles, rather than implying a universal content-tag format.
5. Names and operational metadata
Private storage encrypts file and folder names, extensions, descriptions, categories, source timestamps, exact original sizes, directory membership and version manifests on the client. Authenticated AES-256-GCM catalog pages hold the private directory and version records. Authorized devices decrypt those pages to browse and organize files; the server does not receive the page keys.
Account identities, access grants, account/object associations, billed storage, ciphertext lengths, server operation times and network requests remain service records. Payload and catalog-page padding reduce size precision according to the selected settings. Public content is deliberately readable. Earlier plaintext or partial-metadata records require migration; they do not describe the current private catalog.
6. In transit
Connections use TLS/HTTPS. TLS protects a request in transit; it does not hide request data or URL query parameters from the receiving HTTPS endpoint. Current OWL private share links keep the capability in the URL fragment, which browsers omit from HTTP requests. The client sends a derived lookup identifier and decrypts the returned capsule locally. The retired two-password query-token format is no longer supported. See the link-delivery boundary.
7. Standards posture
OWL uses established algorithm families including AES, SHA-256 and P-256. OWL does not currently use a FIPS 140-validated cryptographic module and does not claim FIPS 140 validation. For requirements, contact security@ndevr.org.
8. Verification
Release verification must cover compatible encryption and decryption across supported clients, rejection of modified ciphertext and tags, recovery using a saved key, rejection of a wrong recovery key, and confirmation that neither plaintext private Drive names nor usable decryption keys reach ordinary CSD storage APIs. Primitive tests do not replace verification of the upload, listing, sharing and recovery flows that use them.