In this article we provide a detailed analysis of Cryptic Whisper’s end-to-end encryption.

End-to-End Encryption in Cryptic Whisper

End-to-end encryption (E2EE) is crucial for modern messaging apps and is designed to prevent anyone other than the intended recipient of a message from reading it. When E2EE is not implemented (either knowingly or improperly), not only can the provider of the messaging app you’re using be able to read your messages but malicious hackers and even government agencies can too.

End-to-End Encryption Meaning

End-to-end encryption works by leveraging asymmetric cryptography, a type of encryption first invented by GCHQ in 1973 and kept classified until 1997. The public version of this encryption was released a few years later in 1977 by Rivest, Shamir, and Adleman, who founded the company RSA. Asymmetric cryptography is central to modern communication: almost all internet or phone communications are protected using this method, including the internet connection you’re using to read this article.

The way these algorithms work involves each participant generating a “private key,” which is kept secret. From this private key, the participant derives a corresponding “public key,” which is shared publicly. Using someone’s public key, a user can encrypt a message that only the holder of the private key can decrypt. Often, a public key is compared to an open vault, and the private key to the code for that vault: anyone can close the vault, but only the person who knows the code can open it again.

In essence, when a user wants to encrypt a message for another user, they simply use the recipient’s public key for encryption. The encrypted message is then sent via Cryptic Whisper’s servers, and the recipient uses their private key to decrypt it.

In Cryptic Whisper, RSA keys with a modulus size of 4096 bits for asymmetric cryptography are generated upon account creation, then stored and encrypted with a symmetric key in the device’s keychain.

Trust On First-Use

An attack scenario described in the previous paragraph involves how the public key is sent from the recipient to the sender. If an attacker manages to intercept and replace the recipient’s public key with one controlled by the attacker, the sender would then use the attacker’s public key to encrypt the secret message, inadvertently sending it to the attacker instead of the intended recipient.

This attack is known as a “man-in-the-middle attack.” To prevent such an attack, there needs to be a mechanism to authenticate the recipient’s public key to ensure that a legitimate public key is used later in the process.

Cryptic Whisper has multiple layers to ensure this authentication and prevent a man-in-the-middle attack:

1. Cryptic Whisper locally stores the sealdId of any user it has interacted with. If anyone tries to swap the keys with attacker-controlled public keys after they have been stored for the first time, this would be detected, and the user would be notified.
2. Cryptic Whisper maintains a signature chain for each user, where various public keys are mutually signed along with the sealdId. This setup ensures that if anyone attempts to maliciously update a user’s keyring, any newly added public keys would be detected and rejected. Here is the helper function used to detect such discrepancies:

This is known as the “Trust On First Use” (TOFU) paradigm. As soon as your Cryptic Whisper app has interacted with another user, it stores sufficient information locally (on your device) about that user to detect potential future attacks. This makes attacks much more difficult in practice, as they become easier to detect. We will cover how to detect an attacker attempting to swap the recipient’s keys before first use below.

Encrypting A Chat in Cryptic Whisper 

To encrypt a chat, a Cryptic Whisper user generates a “symmetric key” randomly and encrypts it using the recipients’ public keys. The encrypted symmetric key is sent via a server to each recipient, who can then use their own private key to decrypt it and recover the symmetric key.

Now that all participants have a shared symmetric key, they can encrypt messages using a symmetric encryption algorithm. The one we use is AES-CBC combined with an HMAC-SHA256 as detailed in [`sscrypto`’s `SymKey`]

(https://github.com/seald/sscrypto/blob/b360e47eb4e99e8fd363ea880db8191cd3a45af1/src/node/aes.ts#L7).

The same applies to images or videos, although they are encoded differently to ensure that the file name is also encrypted. An encryption session is rotated whenever a user is added or removed from the chat to maintain forward secrecy.

Checking The Encryption Keys

As mentioned earlier, Cryptic Whisper applies the TOFU paradigm, but what happens if one does not want to trust at all, at any point, data provided by any third-party (such as Cryptic Whisper’s servers)? For example, the protocol used to secure web connections, TLS, uses a chain of proof certifying that a given public key indeed belongs to a website. This chain of proof ultimately relies on a third-party authority (called an Certification Authority) we all trust to have checked that the public key is indeed legitimate for that website.

 

As the goal is to avoid relying on a third party (at all), Cryptic Whisper implements a peer-to-peer safety mechanism that allows end users to check that the public keys, the symmetric key, and the list of participants to a chat that they retrieved from the servers are indeed legitimate. This mechanism is a QRCode that any participant in a chat can generate on their phone and display so that other users can scan it when meeting face-to-face (or read it over the phone if not in close proximity). It contains the hash of a list of the participants to the chat, a hash of their public key, and a hash of the shared encryption key.

When all the users in a chat verify that they have the same QR code, they can be sure of the following:

• There is no unauthorized participant in the conversation who could maliciously read the messages.
• Every participant has the expected signature chain hash, meaning the expected public key (everyone is who they claim to be).

 

If verification is completed before the first message is sent (by selecting “verify end-to-end encryption” at the top of each chat), any man-in-the-middle attack is entirely prevented.

No Storage of Messages on Our Servers

As soon as any message—whether it includes images, videos, or GIFs—is successfully delivered to its intended recipient, it is removed from our servers and managed solely on the user’s device.

Did You Know?

Our encryption technology complies with todays and tomorrow’s regulations, like HIPAA, GDPR, CCPA, PCI DSS and more.

Summary

Cryptic Whisper’s end-to-end encryption ensures that only authorized users can access their conversations—not hackers, app administrators, government institutions, even service providers.

If security code verification is completed before the first message is sent, any man-in-the-middle attack is entirely prevented.

If you have any feedback or see room for improvement, feel free to contact us at feedback@crypticwhisper.com.