SHARE THE PERSPECTIVE
A changed safety number can tell you that a key changed. Only an out-of-band comparison can tell you it is the right key.

A safety number verifies one thing: that the encryption keys your messenger displays for a contact are the same keys your contact actually holds.

Comparing it out of band — face to face, or over a channel that is not the encrypted chat itself — is what turns a string of digits into evidence that nobody in the middle has swapped a key. When you see a 'safety number changed' banner, that is your prompt to redo the key fingerprint comparison, not usually a sign of an attack. Every end-to-end encrypted identity check rests on this ritual; without it, you are trusting the server not to lie to you.

What does a safety number actually verify?

A safety number is a human-readable fingerprint of the public keys used for encryption in your conversation. Messengers that follow this model, such as Signal, derive it from the public key material each side holds — as Signal's own documentation describes — so the number depends on which keys are present, not on what anyone claims about them.

That last clause is the whole point. In a typical end-to-end encrypted messenger, the server delivers each user's public key bundle. If a compromised or coerced server serves you an attacker's key instead of your contact's, the encryption still 'works' — you are just encrypting to the wrong party. Privacy researchers call this a man-in-the-middle attack, and no amount of key size prevents it, because the substitute key is perfectly valid on its own. If you need the basics first, our guide to what end-to-end encryption does and does not protect covers this in plain terms.

The fingerprint collapses all of that key material into something a person can inspect. Compare it through a channel the attacker cannot rewrite, and a substitution becomes visible: the number you compute from the keys you received would not match the number your contact computes from the keys they actually hold.

Why did the safety number change?

Your safety number changes whenever the key material behind the conversation changes. The overwhelming majority of changes are innocent:

  • The contact reinstalled the app, generating fresh identity keys on the new installation.
  • They added or switched devices, so a second key set now exists and the fingerprint is computed over it.
  • The app was updated or the user performed a deliberate key reset, replacing identity material after, for example, losing a phone.

The uncomfortable truth is that a key change is also exactly what a man-in-the-middle attack looks like. The banner cannot tell you which scenario you are in — an innocent reinstall and a server-level key substitution produce the same visible signal. That is why a changed safety number is a reason to verify, not a verdict.

How do you verify an encrypted chat identity out of band?

Out-of-band verification means checking the fingerprint through a channel other than the encrypted chat itself, so the same attacker cannot alter the comparison. 'Out of band' is the industry term for a second path: in person, on a phone call or video call placed over a different service, or by reading the digits aloud on a channel nobody suspects has been tampered with.

The ritual takes about thirty seconds:

  1. Open the conversation and display the safety number on both devices.
  2. Read or show the number across the second channel — or scan the other person's QR code in person.
  3. Confirm every block matches. If they do, the keys you think you hold are the keys they hold.

Some messengers offer to scan a QR code shown in person, which compresses the comparison to a glance. What matters is not the format but the channel: if the channel you compare over passes through the same server you are verifying against, the comparison proves nothing.

What does a changed safety number not prove?

A matching safety number proves the keys match now. It does not prove anything about protection in the past or the future, and honest guidance says so plainly:

  • It does not tell you who introduced the current keys or why they changed.
  • It does not verify the identity behind the keys — confirming a fingerprint still depends on how confident you are that the person reading the number back is your contact.
  • It does not protect you from metadata exposure, which our guide on what messaging metadata still reveals covers separately: who you spoke to, when, and how often can be logged regardless of key encryption.
  • It is not a continuous guarantee. Keys can change again after a clean check, so re-verify after reinstalls, new devices, or any change banner you do not expect.

Can automatic key verification replace the manual comparison?

Partly — and it is worth understanding exactly where the boundary sits. In August 2026, Signal introduced Automatic Key Verification, a feature designed to detect server-level key substitution without requiring both users to compare strings manually, as reporting from BleepingComputer and CyberInsider described.

The mechanism, covered in detail by TechTimes, lets a client cross-check the key material another user has published against what the same user's own installation has attested, so a server quietly serving a swapped key no longer goes unnoticed. That closes a specific hole: the silent, long-lived server-side interception that no busy user would ever catch by hand.

It does not retire the out-of-band habit for every case. Automatic schemes verify that key publications are internally consistent; manually comparing fingerprints additionally ties the keys to a person you can physically identify. And not every messenger has an equivalent feature yet, so knowing how safety numbers work remains practical knowledge, not nostalgia.

How does this work in Livara Chat?

Livara Chat uses the same principle: safety numbers let two people compare key fingerprints out of band and detect key changes, as documented on Livara's security page. Underneath, direct messages run the LVR1 protocol — a hybrid post-quantum double ratchet combining ECDH P-256 with ML-KEM-768, the KEM defined in NIST's FIPS 203 — and private groups use LGS1, where each sender key is sealed inside pairwise LVR1 envelopes. If you want to understand why that design matters against adversaries who record ciphertext today to decrypt later, our guide to harvest now, decrypt later and hybrid post-quantum encryption walks through it.

Verification can only be as trustworthy as the app performing it, which is why Livara publishes machine-checkable protocol test vectors and release checksums, verifiable locally in the Proof Lab. Checksums and test vectors let you confirm that what you installed matches what was built — they are not an independent security audit, and we do not claim otherwise.

The practical takeaway applies to any messenger you use, ours or anyone else's: when the number changes and you did not cause it, take thirty seconds and compare it out of band.

Frequently asked questions

What does it mean when a safety number changes?

It means the public key material behind your conversation has changed — most often because a contact reinstalled the app, switched devices, or reset their keys. The same visual signal, however, is also what a key-substitution attack produces, so a change is a prompt to re-verify, not a confirmed incident or a confirmed false alarm.

Do I need to verify a safety number with every contact?

Only contacts whose conversations genuinely matter to you. Verifying turns encryption from 'the server says these keys are right' into 'we both compared the fingerprints ourselves'. For everyday acquaintances the default protection is usually adequate; for sensitive conversations, one out-of-band comparison at the start is the high-value step.

Is comparing safety numbers over the same app useless?

Weaker, at minimum. A server that can swap keys could also alter the comparison itself, so a second channel — in person, or another service — closes that loop. This practice is what the term out-of-band verification refers to.

Why is manual fingerprint comparison still recommended at all?

Because it ties key material to a person you can identify directly, something no automatic consistency check reproduces. Automatic key verification catches server-level substitution; a face-to-face comparison additionally binds the keys to the human in front of you.

Sources

Verify a chat with safety numbers
CONTINUE THE THREADEnd-to-end encryption ↗
YOU’VE REACHED THE ENDBack to the reading room ↗