BatChat Security Review - Encryption Architecture and Risk Assessment | BatChatHub

TL;DR: BatChat uses a 3-layer encryption architecture (RSA + SRP + Double Ratchet) with zero server-side message storage. This review breaks down the technical details, evaluates real-world security, and compares it against industry standards like the Signal Protocol.

Introduction

BatChat (蝙蝠聊天) is a China-developed encrypted messaging application that has attracted users who want stronger privacy defaults than mainstream Chinese messaging apps offer. The developer, Chengdu Feifu Technology (成都飞蝠科技有限公司), makes bold claims: zero server data storage (服务器零数据存储), client-side encryption for all conversations, and OS-level screenshot and recording protection.

Security claims require verification. This review examines BatChat’s encryption architecture, evaluates its security posture against industry standards, identifies strengths and weaknesses, and provides an honest risk assessment for users considering BatChat as their primary messaging tool.

The central question: 蝙蝠聊天安全吗 (Is BatChat safe?) The answer, as with most security evaluations, depends on your threat model. This review provides the information to make that determination.

Encryption Architecture

BatChat’s encryption operates on a client-side-first principle: all message content is encrypted on the sender’s device before transmission, transmitted through BatChat’s server infrastructure, and decrypted only on the recipient’s device. The architecture involves three cryptographic layers.

Layer 1: Key Exchange — RSA

BatChat uses RSA for initial key establishment between communicating parties. RSA (Rivest-Shamir-Adleman) is one of the most widely studied public-key cryptosystems, relying on the computational difficulty of factoring large semiprimes.

In BatChat’s implementation, RSA is used to establish a shared secret between two parties. The typical flow:

1. Each party generates an RSA key pair (public + private)
2. Public keys are exchanged (through BatChat’s server)
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

Strengths: RSA is well-understood, has withstood decades of cryptanalysis, and key exchange via RSA provides confidentiality of the session key during establishment.

Weaknesses: RSA does not provide forward secrecy on its own. If a private key is compromised, all past sessions encrypted with that key can be decrypted. This is a significant limitation, which BatChat addresses (in part) through the Double Ratchet layer.

Key size matters. Modern recommendations from NIST and ECRYPT recommend RSA key sizes of at least 3072 bits for security through 2030 and beyond. BatChat does not publicly document its RSA key size, which is a transparency gap.

Layer 2: Authentication — SRP

BatChat uses the Secure Remote Password (SRP) protocol for authentication. SRP allows a client to authenticate to a server without ever transmitting the password (or a password-equivalent value) over the network.

The SRP flow:

1. The client registers by sending a password verifier (derived from the password and salt) to the server
2. During login, the client proves knowledge of the password without revealing it
3. Both sides derive a shared session key as a byproduct of the authentication

Strengths: SRP is resistant to offline dictionary attacks on the server (even if the server’s database is compromised, the attacker cannot directly recover passwords). SRP also provides mutual authentication — both the client and server prove their identities, preventing man-in-the-middle attacks during authentication.

Weaknesses: SRP’s security depends on proper implementation. Known vulnerabilities in SRP implementations include side-channel attacks (timing, cache) and issues with parameter selection (prime size, generator). Without access to BatChat’s source code, these implementation details cannot be verified.

Layer 3: Forward Secrecy — Double Ratchet

BatChat employs the Double Ratchet algorithm for message-level forward secrecy. The Double Ratchet was originally developed as part of the Signal Protocol (formerly the Axolotl Ratchet) and provides two critical properties:

1. Forward secrecy: Compromising a session key does not allow decryption of past messages
2. Post-compromise security (future secrecy): Compromising a session key does not allow decryption of future messages (after a certain number of message exchanges)

The Double Ratchet operates through two mechanisms running in parallel:

• DH Ratchet: Each party generates a new Diffie-Hellman key pair for every message round trip. The new DH keys are mixed into the root key, ensuring that knowledge of old keys does not help compute new keys.
• Symmetric-key Ratchet: Within each DH round, a chain of symmetric keys is derived using a KDF (Key Derivation Function). Each message uses a unique key, and keys are discarded after use.

Strengths: The Double Ratchet is cryptographically sound. It has been formally verified by academic researchers and is used by Signal, WhatsApp, Google Messages, Facebook Messenger (Secret Conversations), and others. If BatChat implements it correctly, it provides strong forward and future secrecy.

Weaknesses: Implementation correctness is critical. The Double Ratchet is complex — it involves managing DH state, chain state, message numbering, skipped message keys, and out-of-order delivery. Subtle implementation errors can undermine security. Without open-source code, BatChat’s implementation cannot be independently reviewed.

Encryption Flow Summary

Sender Device                    BatChat Server                   Recipient Device
     |                                |                                |
     |-- [1] RSA key exchange ------>|                                |
     |<--- [2] RSA key exchange -----|                                |
     |                                |                                |
     |-- [3] SRP authentication ---->|                                |
     |<--- [4] SRP authentication ---|                                |
     |                                |                                |
     |-- [5] Double Ratchet init --->|                                |
     |<--- [6] Double Ratchet init --|                                |
     |                                |                                |
     |-- [7] Encrypted message ------>|------ [7] Relay ------------->|
     |                                |   (no storage, no decryption) |
     |<-- [8] Encrypted message <----|<----- [8] Encrypted msg <-----|

Steps 1-6 occur once during session establishment. Steps 7-8 repeat for each message, with the Double Ratchet deriving new keys for every message exchange.

Server-Side Security

Zero Data Storage Claim

BatChat’s most significant security claim is zero server data storage (服务器零数据存储). The stated model:

• Messages are encrypted on the device before transmission
• Encrypted messages pass through the server as transient data
• After delivery to the recipient, no message data (encrypted or plaintext) remains on the server
• No chat history, media, or files are stored server-side

If accurate, this architecture provides strong protection against:

• Server compromise: An attacker who breaches the server finds no user data
• Government data requests: There is no data to hand over
• Insider threats: Server administrators cannot access user communications

Verification Challenges

The zero-storage claim cannot be independently verified because:

1. Closed source. BatChat’s server code is not publicly available. There is no way to audit whether the server actually discards data after delivery or retains it in some form.
2. No transparency reports. BatChat does not publish transparency reports detailing government data requests received and how they were handled.
3. No independent audits. No third-party security organization has publicly audited BatChat’s server infrastructure or data handling practices.
4. Jurisdiction. BatChat operates under Chinese law, including the National Security Law (2015), Cybersecurity Law (2017), Data Security Law (2021), and PIPL (2021). While PIPL restricts data collection, national security provisions can compel cooperation with authorities in certain circumstances.

Transport Security

BatChat uses HTTPS/TLS for data in transit between the client and server. This is standard practice. The specific TLS version and cipher suite configuration are not publicly documented.

Key questions that cannot be answered from outside:

• Does BatChat use TLS 1.3?
• Are certificate pinning measures implemented?
• How are TLS certificates managed and rotated?
• Does the client validate server certificates properly?

Infrastructure

BatChat’s infrastructure details are limited. The company is based in Chengdu, China (registered at 交子大道233号中海国际C座507). Server locations, hosting providers, CDN configuration, and DDoS protection measures are not publicly disclosed.

Privacy Features Analysis

Screenshot and Recording Protection

BatChat’s OS-level screenshot and screen recording blocking (截屏防护/录屏保护) is a genuine technical capability. The app hooks into the operating system’s screen capture APIs to prevent any application or system function from capturing the chat interface.

How it works (based on available documentation):

• On Android: The app uses the FLAG_SECURE window flag, which tells the Android system to block screenshots, screen recordings, and recent app previews for the protected window.
• On iOS: The app uses UITextField text input mode or UIScreen protections to prevent screen capture in the chat view.

Effectiveness:

• Protects against casual screen capture (physical buttons, system screenshot shortcuts)
• Protects against screen recording software
• Protects against recent app view exposure
• Does NOT protect against: photographing the screen with another camera, screen capture via root/jailbreak access, hardware-level capture tools, or compromised OS components

Assessment: Strong protection against the most common threat vectors. Not absolute — no software-level protection can defeat determined physical capture — but significantly raises the bar.

Preset Password (预设密信)

The preset password feature adds application-level authentication to individual conversations. Both parties must enter a shared secret to access the chat.

Security properties:

• Protects against casual device snooping (someone picks up your unlocked phone)
• Protects against shoulder surfing if the password is entered discreetly
• Does NOT protect against: keyloggers, screen capture (if the password entry screen is unprotected), forensic extraction of the app’s data

Assessment: Useful additional layer for low-threat scenarios. Not a substitute for device encryption or full-disk encryption.

Unlock Password (解锁密码)

BatChat requires face recognition, fingerprint, or numeric PIN verification before accessing the app. This operates independently of the system-level device lock.

Assessment: Standard app-lock functionality. Effective against casual unauthorized access to the device.

Risk Assessment

Threat Model Matrix

Threat	Likelihood	BatChat Mitigation	Residual Risk
Network eavesdropping	Medium	TLS in transit, client-side E2E	Low (if TLS properly configured)
Server breach	Low-Medium	Zero storage claim	Unknown (cannot verify)
Government data request	Low (average user)	Zero storage claim	Medium (closed source, Chinese jurisdiction)
Malware on device	Medium	App sandbox, no stated protection	Medium (depends on device security)
Physical device theft	Low	App lock, preset password	Low-Medium
Screenshot capture	Medium-High (China)	OS-level blocking	Low
Screen recording	Medium	OS-level blocking	Low
Man-in-the-middle	Low	RSA + SRP authentication	Low-Medium (depends on key verification)
Server-side MITM	Low	Client-side E2E encryption	Low
Quantum computing attack	Very Low (current)	Not addressed	High (future, if no migration path)
Supply chain attack	Low	Not documented	Unknown
Social engineering	Medium	No specific mitigation	Medium

Strengths

1. Default E2E encryption. All conversations are encrypted client-side by default. No opt-in required.
2. Zero server storage architecture. If implemented as claimed, this eliminates the most common data breach vector.
3. Comprehensive screenshot/recording protection. OS-level blocking significantly reduces the risk of chat content leaking through screen capture.
4. Multi-layer authentication. RSA for key exchange, SRP for authentication, and app-level locks provide defense in depth.
5. Double Ratchet for forward secrecy. Using the proven Double Ratchet algorithm provides strong session security.
6. No advertising ecosystem. BatChat has no ad platform, eliminating the privacy-invasive data collection that characterizes Meta-owned and advertising-supported messengers.

Weaknesses

1. Closed source. The most significant limitation. Without source code access, no independent party can verify that:
   • The encryption implementation matches the described architecture
   • There are no backdoors, intentional weaknesses, or undisclosed data collection
   • The zero-storage claim is accurate
   • The Double Ratchet is implemented correctly
2. No published protocol specifications. Signal publishes detailed cryptographic specifications at signal.org/docs. BatChat does not publish equivalent documentation.
3. No independent audits. No security firm has published a public audit of BatChat’s code, protocol, or infrastructure.
4. Chinese jurisdiction. Operating under Chinese law introduces regulatory risks. While PIPL (2021) provides data protection, national security provisions can override privacy protections.
5. No post-quantum preparation. Unlike Signal (PQXDH + SPQR), BatChat has not documented any post-quantum migration plan. RSA and the classical Diffie-Hellman components of the Double Ratchet are vulnerable to future quantum attacks.
6. No key verification mechanism. Users cannot verify their contacts’ encryption keys out-of-band, leaving man-in-the-middle detection to the protocol’s built-in authentication (RSA + SRP).
7. Limited transparency. No transparency reports, no canary, no published security policies.

Comparison with Industry Standards

Criterion	Signal	WhatsApp	Telegram (Secret)	BatChat
Default E2E	Yes	Yes	No (opt-in)	Yes
Open source	Full (client + server)	No	Client only	No
Published protocol	Yes (signal.org/docs)	No	Yes (core.telegram.org)	No
Academic audits	Multiple	None	None	None
Post-quantum	Yes (PQXDH + SPQR)	No	No	No
Forward secrecy	Yes	Yes	Limited	Yes
Server data storage	Temporary relay	No (E2E)	No (local only)	Claimed zero
Screenshot protection	Limited (Windows)	No	Notification only	OS-level blocking
Key verification	Safety numbers	QR / safety numbers	Key visual	No
Transparency report	Yes	Limited	Partial (via bot)	None

BatChat does not lead in any category against the most secure options (Signal). It does not trail in most categories either — except for transparency and verifiability, where it is significantly behind.

Recommendations by User Profile

For general users in China who want more privacy than WeChat: BatChat is a reasonable choice. It provides default E2E encryption, screenshot protection, and zero server storage claims. The practical alternative (Telegram) requires VPN, which adds its own risk. The limitation is the trust-you-must-place in a closed-source application.

For high-risk users (journalists, activists, whistleblowers): BatChat is not recommended without independent verification. The closed-source nature, Chinese jurisdiction, and lack of audits make it unsuitable for threat models where state-level adversaries are a concern. Signal (accessed via VPN) remains the better choice for high-risk users in China.

For privacy-conscious users outside China: BatChat offers no advantage over Signal. Signal provides stronger encryption (post-quantum), open-source transparency, and academic verification. BatChat’s unique features (screenshot blocking, preset passwords) are not sufficient to compensate for the verifiability gap.

For business use in China: BatChat may be appropriate for internal communications where the threat model does not include state-level adversaries. The screenshot protection and preset password features add practical value in business contexts. Organizations should conduct their own security assessment before deployment.

Conclusion

BatChat’s encryption architecture — RSA for key exchange, SRP for authentication, and Double Ratchet for forward secrecy — is built on sound cryptographic foundations. The zero server storage model, if accurate, provides strong protection against the most common data breach scenarios. Screenshot and recording protection addresses a real and common threat in Chinese digital culture.

The fundamental limitation is verifiability. BatChat is closed source, has no published protocol specifications, no independent audits, and no transparency reports. Users must trust the developer’s claims without the ability to verify them. For a security product, this is a significant gap.

The honest assessment: BatChat’s stated security posture is strong, but its demonstrated security posture is unknown. Whether this is acceptable depends on your threat model and what you are protecting. For casual privacy improvement over mainstream Chinese apps, BatChat is a step in the right direction. For high-stakes security, the lack of independent verification is a dealbreaker.

FAQ

Is BatChat’s encryption safe?

BatChat uses RSA, SRP, and the Double Ratchet — all recognized, well-studied cryptographic primitives. The individual components are sound. However, the implementation cannot be independently verified because the source code is closed. Correct implementation is critical for security, and without audit, the implementation quality is unknown.

Does BatChat store my messages on its servers?

BatChat claims zero server data storage (服务器零数据存储). According to the developer, encrypted messages pass through the server during delivery but are not stored. This claim cannot be independently verified due to the closed-source nature of the application and server infrastructure.

Has BatChat been audited by security researchers?

No publicly documented independent security audit of BatChat exists. Signal has undergone multiple academic audits (Oxford, Queensland University of Technology, McMaster University in 2016; additional audit in 2017). No comparable analysis has been published for BatChat.

Is BatChat safe for sensitive communications?

For high-stakes communications where state-level adversaries are a concern, BatChat is not recommended without independent verification. The closed-source nature and Chinese jurisdiction introduce risks that cannot be quantified. Signal (accessed via VPN) provides stronger assurances through open-source code and academic verification.

How does BatChat’s screenshot protection work?

BatChat uses OS-level screen capture blocking. On Android, this is implemented through the FLAG_SECURE window flag. On iOS, it uses platform-specific screen capture prevention APIs. This blocks screenshots, screen recordings, and recent app previews for the chat interface. It does not protect against physical photographing of the screen or compromised OS-level access.