Rocket.Chat E2EE Cracked: 9-Char Passwords Fail

Rocket.Chat E2EE was completely broken by a predictable backup password, according to BlackHat research presented at Black Hat Asia 2026.

The open source platform deployed in over 150 countries encrypted its RSA private key backups with a 9 character password generated by Math.random and then lowercased.

How a non-crypto random broke the key backup

Hay Kimura, an applied cryptography researcher from Japan presenting joint work with cryptographers from NTT Corporation, traced three architectural smells.

Rocket.Chat uses RSA key backups encrypted by a password and stored on the server for multi device sync, RSA-encrypted group session keys, and AES-CBC messages with no integrity check.

The backup password was the root failure.

Code review showed a custom generator picking 9 characters from a 62 character set of upper, lower and digits using Math.random. Mersenne Twister is not a cryptographic RNG.

Then a toLowerCase call silently collapsed the set to 36 characters and doubled the weight of lowercase letters, creating a strong and exploitable bias.

Key derivation made it worse. The password was stretched with PBKDF2-HMAC-SHA256 at just 1 iteration, versus the 600,000 now recommended by security standards. That made offline cracking practical once the backup was fetched from the server.

What an attacker could actually do

The password is the root of the entire hierarchy. It derives the master key, which decrypts the RSA private key, which decrypts group keys.

Recover the password and you read every encrypted message and write as the victim.

Kimura also demonstrated message forgery from the CBC without HMAC or GCM, and man in the middle attacks from a trust on first use model for public keys.

Even a password reset did not help. The undocumented recovery protocol renewed the password but never rotated the group session keys, so an attacker kept access after the user thought they were safe.

Why Rocket.Chat built it this way

Rocket.Chat launched E2EE as an optional feature in 2018 and later promoted it as a core selling point for its self hosted Slack and Teams alternative.

GitHub history shows the team initially planned to use the Signal Protocol in 2017. A post credited to member Mrinal Dhar said development started with Signal but had to change because of browser requirements.

A later developer comment found by Kimura said the custom design was done to ensure users can use any device.

That tradeoff is familiar. Matrix and Element, the other major open federated chat, coordinated urgent patches in August 2025 for high severity flaws in matrix-js-sdk that broke E2EE interoperability.

Rocket.Chat chose simplicity over proven ratchets and got neither forward secrecy nor authenticity.

Why this matters now

Self hosted E2EE is a key procurement checkbox for governments, health and defense buyers who cannot use cloud SaaS. Rocket.Chat sells exactly on that premise.

A server side attacker recovering keys undetectably breaks that promise more cleanly than any server breach. It turns end to end into transport encryption with marketing.

Disclosure started in early 2024 and fixes landed in the second half of 2024. CVE-2024-42027 was assigned to the mobile password entropy issue for versions before 4.5.1, with a CVSS 6.7.

Most issues are now patched, except public key authenticity. Rocket.Chat still uses trust on first use and treats that man in the middle risk as acceptable under its threat model.

For founders the lesson is specific. If your moat is privacy, do not roll your own key management for multi device convenience. Use the Signal or MLS primitives that already solved it, or isolate a single point of failure like a password encrypted RSA key from your entire message history.

The research took two and a half years from 2023 to paper acceptance in February 2025. That gap between spec and implementation is where the bugs hid.