A key dedicated to a file does not mean one-time viewing or recalling the recipient’s copy.
To protect an attachment, a messenger can encrypt the file on the sender’s device with a random key, upload the encrypted copy and deliver the file key to the recipient inside an end-to-end encrypted message. This pattern is sometimes called envelope encryption: the large file and the small amount of information needed to open it follow different but related paths.
This explanation concerns attachments in conversations with E2EE; sending a file in every app or every type of channel does not necessarily offer the same protection.
A private photo’s path from device to recipient
- The sender’s device generates a content key for the file.
- The file is encrypted using authenticated encryption; the recipient must be able to detect unauthorized changes to the data.
- The encrypted copy is placed on a file-storage service.
- The file’s address or identifier and the required key are sent to the recipient in a protected message.
- The recipient’s device downloads the file, validates it and then opens it.
Livara’s security documentation describes a random, file-specific key for attachments and its delivery within the messaging session. This article explains that stated architecture, not the results of an implementation audit.
A “file-specific key” is not the same as “the file can only be opened once”
A key generated for one file may be needed to read that same file multiple times. A dedicated key does not mean immediately discarding it after the first viewing, automatically deleting the file or preventing the recipient from saving it.
Likewise, a one-time message key and the use of a content key for an attachment are two different concepts. Features such as View Once or disappearing messages should not be inferred merely from an algorithm’s name.
Why do both the key and the nonce matter?
AES-GCM provides data-authenticity checks as well as confidentiality, but using it correctly is essential. The NIST SP 800-38D standard explains GCM’s rules. Reusing a key-and-nonce combination for different data can compromise security.
For users, the practical conclusion is that “AES-256” alone is not enough. Key-management specifications, random generation, file validation and error handling must also be considered. Changing a byte should cause an invalid file to be rejected, not manipulated content to be displayed as a valid file.
What do the recipient, server and gallery app see?
| Location | Security question |
|---|---|
| File-storage service | Does it hold only encrypted bytes, or can it also access the key? |
| Message containing the key | Are the key, filename and caption protected in the E2EE conversation? |
| Recipient’s device | After opening, where does the file remain—in memory, cache or the gallery? |
| Cloud backup | Does the saved copy enter photo backups, and what protection does that backup have? |
Encryption in transit does not control a copy that the recipient saves to their gallery. Before sending a sensitive document, also check unnecessary parts of the image, writing in the background and the file’s location information.
What changes for a file in a private group?
More people are authorized to hold the key. Livara describes attachment coverage for compatible private groups in E2EE mode under LGS1; this claim should not be extended to public channels. Any member who received the file may keep a copy. Removing a member or rotating future keys does not take back their earlier copy.
Checklist for sending a sensitive file
- Double-check the conversation space and its audience.
- If the contact’s identity matters, verify the key fingerprint through a trusted route.
- Send only necessary information; a complete photo of a document is not always needed.
- Agree with the recipient about gallery storage, automatic downloads and cloud backups.
- Do not leave the decrypted file on a shared or unlocked device.
Frequently asked questions
Does a file-specific key guarantee secure sending?
No. Healthy devices, recipient authentication and correct implementation are also necessary. Read Livara’s threat model alongside its encryption specifications.
Does an image in a public channel have the same protection?
Under Livara’s stated boundary, channels are public and readable; private-attachment confidentiality is not promised for them.
Is a file link alone enough?
It depends on the service’s design. Consider the link, key and access authorization separately; a URL being long or random is not proof of E2EE.
