Message Integrity: Can the Server Alter an Encrypted Chat?

A messenger can offer editing or deletion, but in a system using authenticated encryption, the server should not be able to silently alter ciphertext and still deliver a valid message. Message integrity in a messenger means the recipient can detect data changed after encryption; it is not the same as retaining a complete history or legally proving a conversation.

Key points

• Authenticated encryption detects ciphertext tampering, but does not necessarily retain edit and deletion history.
• According to Livara’s technical documentation, AES-256-GCM protects private messages with an authentication tag; a tampered packet should not decrypt as valid.
• An authorized edit should be a new, end-to-end encrypted event, not a secret server-side rewrite of the previous packet.
• Safety numbers help verify the other party’s key, not their honesty or a screenshot’s legal validity.
• For sensitive disputes, retain original files, times, edit status and independent evidence outside the conversation thread as well.

What exactly is message integrity in a messenger?

Message integrity means the recipient can detect unauthorized changes to encrypted data. Confidentiality asks “Who can read the text?”; integrity asks “Did the same data arrive that the sender encrypted?” The explanation of end-to-end encryption and its boundaries explores this distinction further.

This is a conceptual illustration with illustrative labels, not Livara’s actual interface or the result of a test rejecting a tampered message.

According to Livara’s technical documentation, direct messages use LVR1 and compatible private groups use LGS1 for end-to-end encryption. The Livara security page says incompatible legacy groups explicitly remain outside E2EE, and a new group is not created with an encrypted label until all members are ready. Check the status of the actual conversation. These documents say LVR1 uses ECDH P-256 and ML-KEM-768 to derive message keys. A standardized component is not independent approval of the entire combination or product. Livara then uses AES-256-GCM to protect content.

According to the product documentation, this protection covers text, edits and attachments in private conversations. Livara channels, however, are not end-to-end encrypted: the server can intentionally read their content to remove, among other things, abusive content. Group membership is also server-controlled. Call security and recording mode must be assessed separately from text messaging.

Detecting encrypted-message tampering and messenger AES-256-GCM encryption

Besides encrypting content, AES-GCM creates an authentication tag. If the ciphertext or authenticated data changes, tag verification should fail. NIST SP 800-38D defines GCM and warns that reusing a nonce with the same key can severely undermine security.

Livara’s technical specifications say private messages use AES-256-GCM. If the server changes part of a protected packet, it cannot create a new authentication tag without the message key; the recipient therefore should not accept the packet as intact. The short answer to “Can the server alter a message?” is: it can delete, withhold, block or delay data, but should not be able to make tampered content appear valid.

This guarantee is not unlimited. Cryptography cannot neutralize device malware, an attacker’s access to an unlocked screen or an authorized user edit. Content integrity does not necessarily hide metadata either. The guide to messenger metadata and what it reveals explains this boundary.

Can the server change a message, or is editing something else?

The server should not be able to secretly rewrite the previous encrypted packet, but it can deliver an edit event created by the sender. Message-editing security depends on authenticating and end-to-end encrypting the edit just like the original message, rather than the server directly changing stored text.

Livara’s documentation says edits are protected under LVR1 in direct chats and LGS1 in compatible private groups. To assess the interface, check whether the app shows an “edited” status; cryptography alone, however, does not retain the previous version forever on every device.

“Delete for everyone” is also a request to discard content, not proof that every copy has been destroyed. A recipient may have seen the message, read its notification, saved the file or taken a screenshot. Disappearing messages reduce persistence, but do not guarantee deletion of every copy.

What does chat-message authentication prove?

Chat-message authentication shows that a message was created with the session keys and was not tampered with in transit. It does not prove that the account owner personally held the device, that the text is true or that the recipient can later prove it conclusively to a third party.

Livara’s technical documentation presents safety numbers as a way to detect key changes. Two people can compare key fingerprints through an independent channel; the guide to verifying chats with safety numbers explains the practical steps. This check reduces the risk of an attacker’s key replacing the contact’s key, but does not secure an infected device.

Account authentication is a separate issue too. No login mechanism, however strong, replaces message integrity, contact-key verification or device security.

Content integrity is not message ordering or freshness

An old packet may have a valid authentication tag. Preventing its acceptance again requires protocol design, counters, session identifiers and retained recipient state; AES-GCM alone is not a log of the entire conversation’s order. This distinction matters when assessing replay, delayed messages and multi-device synchronization.

It must also be clear which data actually falls under the authentication tag. If a conversation identifier or event type sits outside the authenticated context, protecting the body alone does not answer the whole problem. Code review and testing of that specific version must clarify this binding.

If a message’s text or status is unexpected

Record the app version, observation time, devices involved and presence of an edit label. Check with the contact through an independent channel whether they made an authorized edit. Do not attribute a synchronization discrepancy to server tampering without evidence, but do not dismiss authentication errors or key changes without reason either.

Use nonsensitive test messages for technical reports, and do not put a contact’s private data in a public report. If a conversation will be used in a legal matter, cryptography or a screenshot alone does not determine legal validity; seek help from a qualified professional before altering evidence.

How can we assess a messenger’s integrity claims?

Do not settle for the word “encrypted”. Ask:

• Which conversations and files are end-to-end encrypted?
• Which AEAD algorithm does the service use?
• How are edits and deletions recorded and displayed?
• How can a user detect changes to a contact’s key?
• What metadata, content or membership does the server control?
• Do calls have the same guarantees as messages?
• Has the protocol been independently audited?

Livara publishes specifications and tools for checking some of its claims, and Android users can compare an APK file’s checksum using SHA-256 in the Proof Lab for offline app verification. This article, however, provides no evidence of an independent audit of the current version. Publishing specifications and test vectors helps scrutiny, but does not replace an independent audit.

For private conversations, Livara’s main claim is limited and clear: AES-256-GCM should detect packet tampering, and edits should also be encrypted. This does not mean an immutable log, guaranteed deletion of every copy or automatic legal evidence.

Frequently asked questions

Can a server administrator change an encrypted message’s text?

With a correct AES-256-GCM design, a server administrator without the message key cannot change ciphertext and create a valid authentication tag. They can still delete, block or delay the packet. This guarantee does not cover an infected device or an authorized edit by the sender.

Does an “edited” label prove what the previous version was?

No. The label only says that the displayed content changed after sending, unless the app also retains version history. Encryption can authenticate the edit event, but does not automatically preserve the old text.

Does a safety number guarantee every message’s authenticity?

No. A safety number helps verify that the encryption key belongs to the contact and detect changes to it. This check does not tell you who held the device when sending, whether the message is true or whether the device is free of malware.

Does deleting for everyone erase a message everywhere?

No. The feature may discard the in-app copy, but cannot take back a saved file, notification, screenshot or earlier recording. Deleting for everyone reduces persistence; it does not guarantee erasure from the recipient’s device or other systems.