Encrypted storage separates file bytes from decryption authority, but recipients, metadata and local copies remain part of the threat model.
An end-to-end encrypted attachment can be stored on a server without giving that server the plaintext file. A common design encrypts the file on the sender’s device with a fresh content key, uploads the ciphertext, and sends the key to intended recipients inside an authenticated encrypted message.
The separation is useful, but “zero-knowledge storage” is not a complete specification. You still need to ask how keys, file references, filenames, access controls and downloaded copies are handled.
The attachment lifecycle
- Prepare the file. The sender selects a photo, video or document. Any metadata removal or transcoding is a separate step; encryption alone does not strip EXIF or document properties.
- Create encryption material. A secure implementation generates the required key and nonce material according to its chosen scheme.
- Encrypt before upload. The storage service receives encrypted bytes rather than the original content.
- Deliver an authenticated reference. The encrypted chat message carries the information recipients need, such as a file locator, decryption key and relevant integrity metadata.
- Fetch and verify. The receiving client retrieves the blob and verifies authentication before treating the result as valid content.
- Manage local copies. Displaying, exporting, editing or saving to a gallery can create copies outside the original encrypted-storage boundary.
The key may travel through the same provider’s infrastructure in an encrypted envelope. Calling that “out of band” can mislead: it is logically separated from blob storage, not necessarily delivered by an independent communication channel.
What authenticated encryption adds
An authenticated-encryption scheme protects confidentiality and detects unauthorized changes within its authenticated scope. NIST’s GCM specification defines one such construction and its requirements. Correct key/nonce handling and checking the authentication result are essential; a recognized algorithm name does not make every implementation safe.
The application also needs to bind the file to the correct message and conversation. A valid encrypted blob is not, by itself, proof that it belongs in this particular chat. File identifiers, expected size, chunk order and attachment metadata need an appropriate authenticated design.
What the storage service may still learn
| Information | Does content encryption alone hide it? |
|---|---|
| Original file bytes | It is designed to, from parties without the key |
| Approximate encrypted size | Usually not |
| Upload and download timing | Usually not |
| Which account requests a file | Depends on routing and access-control design |
| Filename and caption | Only if the protocol protects them too |
| A copy saved by a recipient | No; the recipient already has plaintext access |
Access controls still matter even when blobs are encrypted. They can limit unwanted downloading, abuse and exposure of identifiers. Encryption is not a substitute for authorization, retention policies or availability.
Large files require more than one slogan
A large-file design may stream data or split it into authenticated chunks. That can reduce memory use, but chunk numbering, final length, retries and truncation handling must be defined. Do not invent performance figures or claim that placing a file in a message necessarily causes “ratchet state bloat”; those outcomes depend on the implementation.
A helpful test includes a valid file, a changed byte, a truncated download, a reordered chunk and an unauthorized retrieval attempt. Run such tests only in an authorized test environment with non-sensitive files. Record whether the client rejects invalid data before opening it.
What Livara documents
Livara’s security page describes encryption before upload, a per-file random key carried inside the protected session, and protection for filenames and captions in conversations where E2EE is active, including compatible private groups. Older incompatible groups are explicitly outside that coverage. It distinguishes protected conversations from public broadcast channels. These are documented product claims, not a fresh implementation audit in this article.
The threat model also recognizes that a recipient or compromised device can expose readable content. Encrypted storage therefore cannot promise that an image disappears from every device when its chat message is deleted.
Questions to ask before sharing sensitive files
Check whether the conversation type supports E2EE, whether all intended recipients are trusted, and whether the file itself contains identifying metadata. Review automatic gallery saving and cloud-photo backup separately. For a document, consider whether comments, revision history or embedded properties should be removed before sending.
Finally, understand deletion and recovery. Removing a server blob can stop a future download, but cannot retract a recipient’s existing copy. Losing the required key may make a remaining encrypted file unreadable. A good attachment design explains both outcomes plainly.
