How BatChat Encryption Works Explained | BatChatHub

TL;DR

BatChat (蝙蝠聊天) encrypts messages using three cryptographic layers stacked together: RSA handles initial key exchange, SRP (Secure Remote Password) authenticates users without exposing credentials, and the Double Ratchet algorithm provides forward secrecy by generating a unique encryption key for every message. All encryption happens on your device before any data reaches the server. The server performs zero data storage (零数据存储) — it relays encrypted packets but cannot read them. This architecture is comparable in concept to the Signal Protocol but differs in its specific implementation choices.

Why BatChat Encryption Matters

Most people use encrypted messaging apps without understanding how the encryption actually works. This matters because trust in encryption should be based on how it works, not just marketing claims (加密原理).

BatChat claims to protect “tens of millions” (数千万) of users’ conversations. The official website states that messages and files are encrypted on the device before transmission (消息安全防护后传输) and that the server stores zero data (服务器零数据存储). These are strong claims that deserve technical scrutiny.

This article breaks down each layer of BatChat’s encryption, explains how the pieces fit together, and compares the architecture to widely analyzed alternatives like the Signal Protocol.

The Three-Layer Encryption Model

BatChat’s encryption is not a single algorithm — it is a system composed of three layers, each handling a different security requirement.

Layer 1: RSA — Key Exchange
Layer 2: SRP — Authentication
Layer 3: Double Ratchet — Forward Secrecy

Each layer addresses a distinct problem:

• Key Exchange: How do two parties agree on a shared secret without anyone else knowing it?
• Authentication: How do you prove you are who you say you are without revealing your password?
• Forward Secrecy: How do you ensure that compromising one key does not expose all past (or future) messages?

Understanding each layer separately makes the overall system comprehensible.

Layer 1: RSA Key Exchange

What RSA Does in BatChat

RSA (Rivest-Shamir-Adleman) is the first layer that runs when two BatChat users begin communicating. It solves the key distribution problem — how to establish a shared secret between two parties who have never communicated before, over an insecure channel where an eavesdropper might be listening.

The process works as follows:

1. Each user generates an RSA key pair — a public key (shared openly) and a private key (kept secret on the device)
2. Public keys are exchanged through BatChat’s server during initial connection
3. The sender encrypts a session key using the recipient’s RSA public key
4. Only the recipient can decrypt the session key using their private key
5. Both parties now share a session key that can be used for symmetric encryption of messages

How RSA Works (Simplified)

RSA’s security relies on a mathematical asymmetry: multiplying two large prime numbers is easy, but factoring their product back into the original primes is computationally infeasible.

• Key generation: Pick two large random primes (p and q). Compute n = p × q. The public key is (n, e) and the private key is (n, d), where e and d are related through a mathematical property of modular arithmetic.
• Encryption: ciphertext = plaintext^e mod n (using the public key)
• Decryption: plaintext = ciphertext^d mod n (using the private key)

An eavesdropper who intercepts the public key (n, e) cannot derive the private key without factoring n — which, for properly sized keys, would take billions of years with current computing technology.

Strengths and Weaknesses of RSA in BatChat

Strengths:

• RSA is one of the most thoroughly studied public-key cryptosystems in history, withstanding decades of cryptanalysis
• The mathematical foundations are well-understood and implementations are widely available
• Key exchange via RSA provides confidentiality of the session key during the initial handshake

Weaknesses:

• RSA does not provide forward secrecy. If your private key is ever compromised, every past conversation encrypted with that key could be decrypted. This is a significant limitation.
• Key size is critical. NIST recommends at least 3072-bit RSA keys for security through 2030. BatChat does not publicly document its key size.
• RSA key generation and encryption are computationally more expensive than elliptic curve alternatives, which is one reason newer protocols (like Signal’s X3DH) use ECC instead.

BatChat mitigates the forward secrecy weakness through Layer 3 (Double Ratchet), which we will cover later. But it is important to understand that RSA alone would leave past conversations vulnerable.

Comparison with Signal’s Key Exchange

Signal uses X3DH (Extended Triple Diffie-Hellman) instead of RSA for key agreement. X3DH uses elliptic curve cryptography, which is more efficient and provides forward secrecy by design. Signal has also added PQXDH (Post-Quantum Extended Diffie-Hellman) since 2023 for protection against future quantum computing attacks.

BatChat’s use of RSA is a deliberate choice. RSA is simpler to implement correctly and has a longer track record. However, it is less efficient and does not provide native forward secrecy.

Layer 2: SRP Authentication

What SRP Solves

After two parties have established a shared secret via RSA, they need to authenticate each other. The problem: how do you prove your identity without revealing your password?

Traditional authentication sends passwords to the server, which checks them against a stored hash. This has vulnerabilities:

• The server sees your password (even hashed), so a compromised server exposes credentials
• A man-in-the-middle could intercept the password during transmission
• The server must store something password-related, creating a target for attackers

SRP (Secure Remote Password) eliminates these problems by allowing password-based authentication without ever transmitting the password or a password-equivalent value.

How SRP Works in BatChat

The SRP protocol involves these steps:

1. Registration: The user chooses a password. The client computes a “verifier” from the password and a random salt, and sends the verifier (not the password) to the server.
2. Authentication request: The client contacts the server and receives the stored salt.
3. Shared secret derivation: Both the client and server independently derive the same shared secret — the client using the actual password, the server using the stored verifier. A passive eavesdropper cannot derive the shared secret.
4. Proof exchange: Both sides send each other cryptographic proofs that they derived the correct shared secret. Only someone who knows the password (or the verifier) can produce a valid proof.
5. Session key: The shared secret becomes a session key for encrypting further communication.

The critical property: the server never sees the password, and an eavesdropper learns nothing useful. Even if the server database is completely compromised, the attacker gets verifiers, not passwords. Verifiers are resistant to offline dictionary attacks because the computation required to test each candidate password is intentionally expensive.

What SRP Provides

• Password security: The password never leaves the client device
• Mutual authentication: Both the client and server prove their identities, preventing man-in-the-middle attacks
• Resistance to server compromise: Stolen verifiers cannot be directly reversed into passwords
• Session key derivation: Authentication and key establishment happen in one step

Limitations

SRP’s security depends on implementation quality. Known vulnerabilities in SRP implementations include:

• Side-channel attacks: Timing variations in the computation can leak information about the password
• Parameter selection: The size of the prime modulus and generator affect security strength
• State management: Improper handling of session state can open attack vectors

Without access to BatChat’s source code, these implementation details cannot be independently verified. This is a transparency gap.

Layer 3: Double Ratchet Forward Secrecy

What Is Forward Secrecy?

Forward secrecy (also called perfect forward secrecy, PFS) ensures that compromising one encryption key does not allow decryption of past messages. Without forward secrecy, an attacker who records your encrypted traffic and later obtains your private key (through theft, court order, or future quantum computing) could decrypt everything you have ever said.

The Double Ratchet algorithm solves this by generating a new encryption key for every single message. Keys are derived sequentially, and each key is mathematically dependent on all previous keys but cannot be reversed.

How the Double Ratchet Works

The Double Ratchet runs two ratcheting mechanisms in parallel:

1. DH (Diffie-Hellman) Ratchet:

• Each party generates a new DH key pair for every message round trip
• These new DH keys are mixed into a “root key” using a Key Derivation Function (KDF)
• The root key evolves with every exchange, ensuring that knowledge of old DH keys does not help compute new ones
• If a session key is compromised, the next DH exchange creates new keys that the attacker cannot predict

2. Symmetric-Key Ratchet:

• Within each DH round, a chain of symmetric keys is derived using a KDF
• Each message in the chain uses a unique key, and that key is discarded after use
• This ensures that compromising one message key does not expose adjacent messages

The combination means:

• Forward secrecy: Compromising your current keys does not expose past messages (the DH ratchet prevents backward computation)
• Post-compromise security (future secrecy): After your keys are compromised, the next DH exchange “heals” the session — the attacker loses access to future messages

The Double Ratchet in Context

The Double Ratchet was originally developed by Trevor Perrin and Moxie Marlinspike as part of the Signal Protocol (formerly called the Axolotl Ratchet). It has been formally analyzed by researchers at Oxford, Queensland University of Technology, and McMaster University, who concluded the protocol is cryptographically sound.

The Double Ratchet is now used by:

• Signal (with additional PQXDH and Triple Ratchet extensions)
• WhatsApp
• Google Messages (for RCS conversations)
• Facebook Messenger (Secret Conversations)
• Matrix/Olm
• Wire
• And others

BatChat’s adoption of the Double Ratchet means it benefits from the same cryptographic guarantees that underpin these widely deployed systems — assuming the implementation is correct.

What Double Ratchet Fixes in BatChat’s Architecture

Recall that RSA (Layer 1) does not provide forward secrecy. The Double Ratchet (Layer 3) compensates for this:

• Without Double Ratchet: If your RSA private key is compromised, all past conversations are exposed
• With Double Ratchet: Even if your RSA private key is compromised, past messages remain protected because they were encrypted with ephemeral DH-derived keys that the RSA key never had access to

The layers work together: RSA establishes the initial connection, SRP authenticates the users, and the Double Ratchet takes over for ongoing message encryption with full forward secrecy.

Zero Server Storage: What Does It Actually Mean?

BatChat’s claim of zero server data storage (零数据存储) is central to its privacy positioning. Here is what it means technically:

The Relay Model

In BatChat’s architecture, the server’s role is limited to message relay:

1. The sender’s device encrypts the message using the recipient’s public key
2. The encrypted message is sent to BatChat’s server
3. The server forwards (relays) the encrypted message to the recipient
4. The server does not store the encrypted message after delivery

This is similar to how Signal operates. The key difference is that Signal’s server code is open source and has been reviewed, while BatChat’s server implementation is closed.

What “Zero Storage” Actually Covers

Based on BatChat’s public statements, the zero-storage policy applies to:

• Message content: Text messages are not stored on the server after delivery
• File content: Photos, videos, documents, and other files are not persisted on the server
• Media metadata: File names, sizes, and types are not retained

What May Still Be Stored

Even with zero message storage, some operational data typically exists on any server:

• Routing information: The server needs to know where to deliver messages (which device to send to)
• Public keys: For encryption to work, public keys must be available for lookup
• Connection state: The server tracks which users are currently online to enable push notifications
• Account information: User registration data (at minimum, the phone number used to register)

BatChat does not publicly document exactly what non-message data, if any, is retained on the server. This is another transparency gap compared to apps like Signal, which publishes detailed privacy policies about what metadata is retained and for how long.

Comparison with Other Zero-Storage Claims

App	Server Message Storage	Server Code Open Source	Independent Audit
BatChat	Claims zero	No	No
Signal	Deletes after delivery	Yes (AGPL-3.0)	Yes
Threema	Deletes after delivery	Client only (AGPL-3.0)	Yes
Session	Zero (decentralized)	Yes (GPL-3.0)	Partial

Key Generation and Storage on Device

Understanding how keys are managed on your device is essential to evaluating the full security picture.

Key Generation

When you first install and register BatChat, the app generates cryptographic keys on your device:

• RSA key pair: Used for the initial key exchange with other users
• SRP verifier: Derived from your authentication password
• Double Ratchet state: Initialized when you begin your first conversation

These keys are generated using the device’s cryptographic random number generator. The quality of this randomness is critical — predictable keys are breakable keys. Modern mobile operating systems (iOS and Android) provide cryptographically secure random number generators, but the specific implementation matters.

Key Storage

Keys are stored locally on the device. On Android, local data is typically encrypted using the device’s hardware-backed keystore. On iOS, the Secure Enclave provides hardware-level key protection.

BatChat supports an app lock feature that requires face ID, fingerprint, or PIN before opening the app. This provides an additional layer of protection against physical access to the device.

Key Compromise Scenarios

If your device is lost, stolen, or seized:

• Local encryption (device lock): Provides the first line of defense
• BatChat app lock: Adds a second authentication layer
• Double Ratchet: Limits the damage if session keys are extracted — past messages remain protected if the ratchet state has advanced sufficiently

There is no evidence that BatChat supports remote key wiping or self-destructing key material, which means physical device compromise remains the primary attack vector.

How BatChat Compares to the Signal Protocol

The Signal Protocol is the industry benchmark for encrypted messaging. Here is how BatChat’s architecture compares:

Signal Protocol Components

• X3DH (Extended Triple Diffie-Hellman) — key agreement using elliptic curve cryptography
• Double Ratchet — forward secrecy for every message
• PQXDH (Post-Quantum Extended Diffie-Hellman) — quantum-resistant key agreement (added 2023)
• Triple Ratchet / SPQR — sparse post-quantum ratchet layered on classical Double Ratchet (added 2025)
• Sealed Sender — metadata protection that conceals sender identity from servers

BatChat vs Signal Protocol

Component	BatChat	Signal Protocol
Key agreement	RSA	X3DH + PQXDH
Authentication	SRP	Not separate (integrated in X3DH)
Forward secrecy	Double Ratchet	Double Ratchet + SPQR
Post-quantum protection	Not documented	PQXDH + SPQR
Metadata protection	Not documented	Sealed Sender
Protocol specification	Not published	Published at signal.org/docs
Formal academic analysis	None	Multiple (2016, 2017)
Open source	No	Yes (AGPL-3.0, all components)

The structural difference: Signal Protocol is a single, integrated protocol where key agreement, authentication, and forward secrecy are designed to work together. BatChat combines three separate mechanisms (RSA, SRP, Double Ratchet) that were not originally designed as a unified protocol. This is not inherently weaker, but it introduces potential for integration errors that a unified protocol avoids.

The quantum computing gap: Signal has already deployed post-quantum protection (PQXDH + SPQR). BatChat has not documented any post-quantum measures. For most users today, this is not an immediate concern, but it will become increasingly relevant as quantum computing advances.

What We Know and What We Do Not

Verified Information (from official sources)

• BatChat encrypts messages client-side before transmission
• The app uses RSA, SRP, and Double Ratchet (documented in app materials and security reviews on batchathub.com)
• The server claims zero data storage
• The app supports screenshot blocking, screen recording protection, and preset passwords
• BatChat is developed by Chengdu Feifu Technology in Chengdu, China

Unverified Claims

• The actual security level of the RSA implementation (key size, padding scheme)
• Whether SRP is implemented without side-channel vulnerabilities
• Whether the Double Ratchet implementation matches the specification exactly
• What data, if any, the server retains beyond message content
• How metadata is handled

What Would Increase Trust

• Publishing protocol specifications on an independent site
• Open-sourcing the client code
• Submitting to an independent security audit by a reputable firm
• Documenting metadata retention policies in detail
• Implementing reproducible builds so users can verify the binary matches the source code

FAQ

What encryption does BatChat use?

BatChat uses a three-layer encryption system: RSA for key exchange, SRP (Secure Remote Password) for authentication, and the Double Ratchet algorithm for forward secrecy. All encryption happens client-side before data reaches the server.

What does “zero server storage” mean technically?

Zero server storage (零数据存储) means BatChat’s server acts only as a relay — it forwards encrypted messages between devices without persisting them. Once a message is delivered, it is not stored on the server. However, operational data like public keys and routing information likely still exists on the server.

Does BatChat have forward secrecy?

Yes. BatChat implements the Double Ratchet algorithm, which provides forward secrecy. Each message is encrypted with a unique key derived from previous keys. Compromising one session key does not expose past messages, and the session “heals” after a few message exchanges even if keys are compromised.

How does BatChat encryption compare to Signal?

Signal uses the Signal Protocol (X3DH + Double Ratchet + PQXDH), which is published, formally audited, and open source. BatChat uses RSA + SRP + Double Ratchet, which covers the same security properties but is not published, not audited, and not open source. Both provide end-to-end encryption and forward secrecy, but Signal’s implementation is more verifiable.

Is BatChat encryption safe from quantum computers?

There is no evidence that BatChat has implemented post-quantum cryptographic protection. RSA is vulnerable to quantum attacks via Shor’s algorithm. The Double Ratchet’s DH component also uses classical cryptography. Signal has already deployed post-quantum extensions (PQXDH and SPQR). BatChat has not documented any equivalent measures.

Can BatChat read my messages?

If the zero-server-storage claim is accurate, BatChat’s servers cannot read your messages because they only handle encrypted ciphertext without the decryption keys. The keys remain on your device. However, because the server code is not open source, this claim cannot be independently verified.

What is SRP and why does BatChat use it?

SRP (Secure Remote Password) is a protocol that allows password authentication without transmitting the password or a password-equivalent value. BatChat uses SRP so that even if the server is compromised, attackers cannot recover user passwords from stored data. SRP also provides mutual authentication, preventing man-in-the-middle attacks.