In regions where internet access is limited or monitored, secure communication tools play an important role. Mesh-network chat apps like BitChat, created by Twitter co-founder Jack Dorsey, and Bridgefy, which gained popularity during the Hong Kong protests, allow users to message over Bluetooth without relying on internet infrastructure. However, these apps lack convenient authentication, leaving users vulnerable to impersonation and man-in-the-middle attacks. Crosspass, developed by Entelecheia, is another tool in the end-to-end encryption space, offering a simple, PIN-based system for securely delivering messages without exposing long cryptographic keys. When combined with mesh apps like BitChat, Crosspass helps users verify each other’s identity—solving a key problem in mesh networks where anyone can pretend to be someone else.

Benefit for Crosspass: Proximity Filtering

Crosspass is built around a simple concept: a sender writes a note and secures it with a 4-digit PIN. After registering the note with a relay server, the sender receives a 4-letter lookup ID. The recipient uses this lookup ID and the PIN to retrieve the note via a peer-to-peer connection. To enhance security—especially when the PIN is shared over insecure channels like SMS or email—a proximity-based filter can be implemented using Bluetooth mesh networking, similar to technologies such as BitChat.

This proximity filtering would mean that even if an attacker intercepted the PIN, he would have to be physically near the sender (on the same mesh) and act before the note expires. This would make interception nearly useless and could give Crosspass stronger security guarantees than telecom or internet alone.

Benefit for BitChat: Authentication

Bluetooth mesh networks like BitChat have no native way to verify who you’re talking to—unless users are face-to-face. Crosspass could fill that gap. By delivering cryptographic keys over a proximity-filtered retrieval, it would allow users to authenticate each other remotely, using the mesh itself to prove physical context. This could turn an otherwise anonymous mesh into a trusted peer network.

Current Bitchat protocol

Below is the peer-to-peer key exchange protocol, as illustrated in the BitChat whitepaper:

sequenceDiagram
    participant Alice
    participant Bob
    Alice->>Bob: Announce (includes public key)
    Note over Bob: Stores Alice's public key
    Bob->>Alice: Key Exchange Request (Bob's public key)
    Note over Alice: Derives shared secret using X25519
    Alice->>Bob: Key Exchange Response (Encrypted with shared secret)
    Note over Bob: Derives shared secret, verifies response
    Alice->>Bob: Encrypted Message (AES-256-GCM)
    Bob->>Alice: Encrypted Response (AES-256-GCM)
    Note over Alice,Bob: Forward Secrecy Achieved

As can be observed in the protocol above, the lack of authentication means that although keys are exchanged, any device can claim any identity. This leaves the protocol open to impersonation and man-in-the-middle attacks.

Authentication protocol (BitChat + Crosspass)

This protocol enables Alice and Bob to authenticate each other on the BitChat mesh network.

It relies on an out-of-band channel between Alice and Bob—such as email or an instant messenger like iMessage, WhatsApp, or Signal—which may be trusted based on prior communication history, but cannot be assumed to provide reliable end-to-end encryption (E2EE). (Note: E2EE in apps like WhatsApp and Signal is only trustworthy if users verify each other’s public keys—a step that’s difficult to perform remotely and typically requires a face-to-face meeting. In practice, few users are aware of this requirement, and even fewer actually follow through.)

This protocol allows Alice and Bob to transfer trust from an existing authenticated internet channel to the local BitChat mesh network. As a result, it enables secure, authenticated communication even when offline—so long as the initial introduction is protected from impersonation.

The key advantage of Crosspass over other authentication methods is its use of a short, 4-digit PIN—a user-friendly, non-technical way to exchange authentication data. This is far more practical than sharing long public keys or 60-digit verification codes (as used in WhatsApp). It also avoids the security risks of using web links to transmit authentication codes, which introduces an attack surface for JavaScript-based backdoors or Phishing attacks.

The security model assumes that even if a MITM attacker (Eve) intercepts the communication, she won’t be able to join the same BitChat mesh network as Alice and Bob quickly enough (within the 5-minute expiry window, in this example).

sequenceDiagram
    participant Alice
    participant Bob
    Note over Alice: Creates Crosspass note with her <br/> cryptographic info and BitChat mesh address, <br/>note expires in 5 min.
    Alice->>Bob: Out-of-band channel (email, WhatsApp)<br/> [BitChat mesh address, Crosspass ID & PIN]
    Bob->>Alice: BitChat mesh<br/>Request Crosspass note by ID & PIN
    Note over Alice: Verifies request is from BitChat mesh
    Alice->>Bob: Releases note by Crosspass E2EE
    Note over Bob: Uses note's content to authenticate Alice in BitChat mesh
    Bob->>Alice: BitChat mesh<br/>Cryptographically proves to Alice he accessed the contents of the note
    Note over Alice: Authenticates Bob on BitChat mesh.

1. Alice uses Crosspass to create a secure note containing her cryptographic identity (e.g., a public key) and her BitChat mesh address.
2. Crosspass sets:
   • A lookup ID (to help the Crosspass server direct the request to Alice’s device),
   • A PIN (required to decrypt and release the note),
   • An expiry time (e.g., 5 minutes).
3. Alice sends her BitChat mesh address, lookup ID, and PIN to Bob over their existing authenticated channel (e.g., WhatsApp, email).
4. Bob’s device connects to the local BitChat mesh network, looks for Alice’s BitChat mesh address, and tries to retrieve the note using the lookup ID and PIN via the BitChat mesh.
5. Alice’s device validates:
   • The correct PIN and lookup ID,
   • That the request is coming via the BitChat mesh, not from the internet,
   • That the request was received within the expiry window.
6. If all conditions pass, Alice’s device authorizes the release of the note through the BitChat mesh, and Bob’s device receives it in E2EE fashion (via internet or mesh).
7. Bob’s device confirms that the BitChat mesh address in the note matches the one he received out-of-band, authenticating Alice’s BitChat identity.
8. Bob’s device cryptographically proves to Alice that he accessed the contents of the note, allowing Alice to authenticate Bob’s BitChat identity.

WiFi Support and Local Network Security

BitChat is also planning to add support for WiFi, which—like Bluetooth—provides a local network guarantee. When devices communicate over a local WiFi network (LAN), the same proximity-based security arguments apply: only devices physically present on the same network segment can participate in the exchange. For Crosspass, this means that secure note retrieval and authentication could be extended to WiFi LANs, not just Bluetooth mesh. The key is to verify that packets do not originate from the internet, but from another device on the local network. This would allow the same proximity and context-based security guarantees to apply, whether users are connected via Bluetooth or WiFi.

Other Uses for Crosspass and BitChat

Imagine two separate BitChat mesh networks: one in Building A in America, and another in Building B in Britain. To create a reliable bridge between these networks, Crosspass can be used to securely exchange BitChat cryptographic identities between pairs of people from both locations. This process establishes a verified, end-to-end encrypted (E2EE) bridge, enabling secure packet relay between the two buildings using the Internet.

Together, Crosspass and BitChat could form a flexible, secure communication fabric—one that would work whether users are nearby, offline, or across the globe.