ATSAM (Anchored Transient Stealth Authentication Mechanism) is Raven Messenger's open-design security protocol — on by default since v1.7. It is a layered protocol covering every Raven communication path — offline Bluetooth mesh, bridge handoff between mesh and internet, and online server-routed messages. ATSAM combines post-quantum hybrid pairing, private nearby discovery, live device confirmation, encrypted routing with rotating per-message tags, and optional Vault Mode for one-time-pad content protection. The result: message content and identity metadata are protected whether the conversation travels over nearby devices, through a bridge node, or across the public internet — with nothing for the user to switch on.
ATSAM (Anchored Transient Stealth Authentication Mechanism) is the open-design security protocol behind Raven Messenger. It is a five-layer stack that performs (1) post-quantum hybrid pairing using X25519 combined with ML-KEM-768 (NIST FIPS 203), (2) private peer discovery via bilateral beacon encryption, (3) live device confirmation through a fresh challenge-response, (4) encrypted routing with rotating per-message recipient tags, and (5) optional Vault Mode using one-time-pad content protection for sensitive text. ATSAM applies uniformly to Raven's three communication paths: offline Bluetooth mesh, bridge handoff between mesh and internet, and online server-routed delivery.
As of Raven v1.7, the ATSAM core layer ships enabled out of the box for every new install and every existing user. The first time you pair a contact, Raven's hybrid post-quantum pairing runs automatically — you do not have to flip any toggle, accept any prompt, or visit any settings screen.
Two additional content-layer add-ons (PROXIMA-VAULT for one-time-pad text and PV-Stealth for rotating envelope tags) ship off by default; they are optional and require explicit per-conversation opt-in.
Traditional messengers rely on cloud servers to route messages and mediate identity. Raven is different. It is designed to keep trusted users connected even when the internet is unavailable, using nearby devices as part of an offline mesh. This requires more than ordinary end-to-end encryption. Raven must also protect how devices discover each other, confirm nearby peers, and route messages without exposing stable identities.
ATSAM is not a single encryption algorithm. It is a layered security stack designed for Raven's online and offline architecture. Each layer has a precise job: pairing trusted devices, discovering nearby peers privately, confirming that a peer is live, routing messages, and protecting highly sensitive content through optional Vault Mode.
One protocol, every path. ATSAM applies to every way a Raven message travels: the offline Bluetooth mesh, the bridge that hands traffic between mesh and internet, and online server-routed messages. Pairing, identity, routing tags, and content encryption are derived from the same key tree regardless of which path the bytes take, so flipping between paths never weakens the protection.
Establishes a shared root secret using classical and post-quantum cryptography combined.
Paired devices recognize each other. Strangers see only random-looking radio noise.
A fresh challenge confirms a peer is actually present before the UI shows "nearby".
Mesh relays forward encrypted envelopes without learning the recipient's identity.
Optional one-time-pad protection for the most sensitive text messages.
When two users establish trust, Raven creates a shared root secret using a hybrid of classical elliptic-curve cryptography and post-quantum key establishment. This gives Raven a stronger foundation than relying on one cryptographic family alone.
Raven devices need to find trusted friends nearby without broadcasting names, phone numbers, public keys, or stable identifiers. ATSAM's discovery layer allows paired devices to recognize each other while making discovery beacons appear random to strangers.
A beacon match does not immediately prove that a peer is live. Raven confirms liveness in the next layer.
After a possible nearby peer is detected, Raven performs a fresh challenge-response confirmation. This prevents old recorded beacons from being replayed to falsely show that a friend is nearby.
When messages move through nearby devices, a bridge node, or an online inbox, no relay should learn who the final recipient is. ATSAM uses per-message routing tags so any forwarder — a Bluetooth mesh peer, a bridge handing traffic to the internet, or the online server itself — only sees an opaque envelope and a rotating 128-bit tag, never a username, phone number, or stable recipient identifier.
This reduces metadata leakage but does not fully hide timing or traffic volume from a global observer.
For selected high-sensitivity text messages, Raven can use Vault Mode. Vault Mode is based on one-time-pad content protection, which can provide information-theoretic secrecy when strict conditions are met: the pad must be random, secret, long enough, and never reused.
Vault Mode is for small text or structured messages, not media files.
Read the public overview of ATSAM, Raven's layered protocol for private discovery, encrypted mesh routing, and optional Vault Mode. The document covers design principles, the five-layer stack, the threat model, an design rationale, and a list of what ATSAM does not claim.
Different adversaries can do different things. The honest way to talk about security is to say who we defend against, and how.
A stranger nearby may see Bluetooth or Wi-Fi traffic. Raven is designed so discovery beacons do not expose names, phone numbers, or stable public identities.
An attacker may record an old beacon and replay it somewhere else. Raven uses live confirmation to prevent old discovery messages from being treated as verified presence.
A relay may forward messages without being part of the conversation. Raven's mesh routing is designed so relays do not see plaintext content or stable recipient identifiers.
ATSAM is designed with honest security claims. It does not make Raven unbreakable, does not fully hide global traffic patterns, and cannot protect a device that is already compromised. Its goal is layered protection: strong content encryption, private peer discovery, safer mesh routing, and transparent limits.
Raven is a different kind of system, and ATSAM is described on its own terms rather than measured against other products. The checklist below is what ATSAM aims to provide today, with clear limits stated alongside each item.
No. As of Raven v1.7, ATSAM is on by default for every install. The first time you pair a contact, post-quantum hybrid pairing runs automatically — there is no toggle to flip and no prompt to accept.
Open Raven → Settings → Security → ATSAM protocol → ATSAM settings. The "ATSAM hybrid pairing" toggle is enabled. You will also see two optional content-layer add-ons (PROXIMA-VAULT and PV-Stealth) that ship off by default.
Yes. The toggle in the ATSAM settings screen disables the core layer. New pair handshakes fall back to the pre-ATSAM Noise IK path. Existing paired sessions keep working unchanged. The toggle is there in case you ever want to interoperate with a peer running an older client.
No. No honest security system should claim that. Raven uses layered cryptography and states its limits clearly.
No. The public ATSAM document is a security overview. Internal specifications include wire formats, exact key schedules, and implementation requirements.
Raven is designed to support offline communication through nearby-device mesh routing when internet connectivity is unavailable.
Vault Mode is optional and intended for high-sensitivity text or structured messages. Large media files use standard encrypted transport.
ATSAM reduces identity and routing metadata exposure, but it does not fully hide timing, radio traffic volume, or global traffic patterns.
ATSAM is live as of Raven v1.7. The core pairing + key-tree layer is on by default; the two content-layer add-ons (PROXIMA-VAULT and PV-Stealth) ship off and stay opt-in per conversation.
The complete ATSAM Public Security Overview includes the design principles, threat model, design rationale, a list of what ATSAM does not claim, and the development roadmap.