End-to-end encryption secures a message in transit, but out of band key verification mathematically guarantees who holds the device at the other end.
End-to-end encryption secures messages in transit, but cannot prove who holds the receiving device. Safety numbers v3 provide a cryptographic fingerprint, enabling users to perform out of band key verification. Through secure messenger fingerprint comparison over a secondary channel, communicators guarantee contact identity, detect cryptographic key changes and block machine-in-the-middle attacks.
Key takeaways
- Safety numbers represent the cryptographic keys securing a private conversation.
- Out of band key verification uses a separate, trusted channel to confirm identities and defeat interception.
- Users can detect cryptographic key changes immediately when a contact reinstalls an application or switches devices.
- Secure messenger fingerprint comparison ensures that a post-quantum encryption wrapper reaches the intended recipient.
- Public broadcast channels are deliberately unencrypted and do not utilise safety numbers.
What is a machine-in-the-middle attack in encrypted messaging?
A machine-in-the-middle (MITM) attack occurs when an interceptor secretly relays and alters communications between parties who believe they are conversing directly. In an unauthenticated key exchange, a network adversary intercepts the initial mathematical handshake, establishing one secure connection with the sender and another with the receiver. The adversary decrypts, reads and re-encrypts every message, whilst victims remain unaware.
Modern cryptography prevents this through identity verification. Without it, standard mathematical primitives like ECDH P-256 establish a robust shared secret, but cannot prove the true identity of the parties holding the private keys. Understanding how end-to-end encryption works requires distinguishing between data confidentiality (keeping the message secret) and authentication (knowing exactly who is reading it).
How does out of band key verification prevent identity fraud?
Out of band key verification prevents identity fraud by requiring users to confirm their cryptographic fingerprints over a separate channel. As TechTarget defines it, out-of-band authentication requires a secondary verification method through a separate communication channel alongside the primary exchange. In secure messaging, this means taking the public key fingerprint from the messenger app and confirming it elsewhere.
If an attacker successfully executes a MITM attack on a messaging network, the cryptographic keys issued to the sender will inevitably differ from the receiver's actual keys. When the sender and receiver read their safety numbers aloud over a telephone call, or scan a QR code in person, the numbers will not match. This out of band channel—one the attacker does not control—exposes the interception instantly.
How do safety numbers v3 integrate with post-quantum encryption?
Safety numbers v3 in Livara summarise the hybrid post-quantum cryptographic keys protecting the LVR1 direct messaging protocol. Livara Chat operates a hybrid post-quantum double ratchet: a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet operate concurrently. Every message key stems from both, granting forward secrecy and post-compromise security.
The underlying key encapsulation mechanism, ML-KEM-768, adheres to America's NIST FIPS 203 standard. Because Livara derives its safety numbers from both the traditional elliptic curve and the post-quantum keys, confirming a safety number validates the entire hybrid stack. If an adversary attempts to strip away the post-quantum encryption in messaging and force a downgrade to classical encryption alone, the safety number shifts, alerting both parties to the tampering.
This verification extends to Livara's LGS1 private group protocol. Although group membership remains server-controlled, full sender-key end-to-end encryption operates by sealing each sender key inside pairwise LVR1 envelopes. Thus, confirming a contact’s safety number secures both your direct messages and shared private group communications. Attachments, which utilise a fresh 32-byte content key inside the LVR1 or LGS1 envelope, rely on this authenticated identity.
How can you detect cryptographic key changes effectively?
You detect cryptographic key changes when your messaging application warns you that a contact's safety number has updated. Keys change for benign reasons: a user replaces a lost phone, reinstalls their application or restores their encrypted identity using a recovery key. However, a key change is also the exact symptom of an active network attack attempting to insert a rogue device into the conversation.
When this warning appears, you must perform a chat verification routine. This secure messenger fingerprint comparison requires contacting the person through another medium. You ask them to confirm their new safety number matches the digits displayed on your screen. Until this concludes, you should pause sensitive communications. Assuming a key change is benign defeats the cryptographic warning system's purpose.
Why are public broadcast channels excluded from key verification?
Livara channels are public broadcast streams by design; they lack end-to-end encryption and have no safety numbers. A channel is a broadcast surface—one author publishing to an unbounded audience—rather than a private conversation.
It is deliberately public and unencrypted so Livara can act on reports, remove abusive material and ban violating channels. Never confuse a broadcast channel with an LGS1 private group. Private conversations are fully sealed and encrypted with AES-256-GCM. Public broadcast channels remain server-readable by design, rendering safety number verification mathematically impossible and conceptually irrelevant in that context.
Frequently asked questions
Do safety numbers hide messaging metadata?
No. Standard routing metadata—such as sender identity, destination and delivery timestamps—is stored for real-time device synchronisation. Safety numbers authenticate the message payload and keys, but do not alter what messaging metadata still reveals about network routing.
Can someone spoof a safety number to match an intercepted key?
No. A safety number represents a cryptographic hash of the underlying public keys, bound by ECDSA P-256 signatures with SHA-256. Generating a fraudulent cryptographic key pair that intentionally produces a matching safety number collision is computationally infeasible.
Does out of band verification protect voice and video calls?
Yes. In Livara, call media (voice and video in direct and Android group rooms of 2–6 people) is encrypted with standard WebRTC DTLS-SRTP, which is not post-quantum. However, the call signalling (LCS1) is carried as an ordinary pairwise-sealed message, meaning it relies on the exact same authenticated LVR1 safety numbers.
Are my passwords protected by safety numbers?
No, passwords operate on a different robust security architecture. Livara uses Secure Remote Password (SRP) for zero-knowledge authentication. This authenticates password knowledge without ever transmitting the password over the wire, protecting it from interception independently of safety numbers.
