Identity Is A Bitchat Challenge (MITM Flaw)

The Intersection of Vibe Coding and Security

Many of us have seen glimpses of what agentic generative coding does for security. We see the missteps, and sometimes wonder about the shallow bugs that pile on. Config managers that are almost always arbitrary file upload endpoints. Glue layers that become bash command launch as a service. And most frustratingly, code generation that's excellent at pretending forward progress has been made when no meaningful change has occurred. One of the most impressive parts of agentic coding is exactly that: how convincing it is by appearance and how easily we're tricked about the depth of substance in the code gen. In some ways we extend our trust of people to the stochastic code parrots, assuming that generative coding produced the actual work a human would have probably performed.

Vibe Identity: An Obvious Flaw

I'm no stranger to e2e breaks, and have been following along over the past decade. Some of my favorite breaks I have found personally include Vaudenay oracles against Kakao, LINE, and bypassable OTR signature verification in iCloud Keychain compromising the password sync.

So this morning when bitchat came up I took some time to look through the code and write up some demos. My first thought was we really don't want or need another protocol, many aspects of Noise would fit in for finer points around true forward secrecy.

But bitchat's most glaring issue is identity. There's essentially no trust/auth built in today. So I would not really think about this as a secure messenger. The protocol has an identity key system, but it's only decorative as implemented and has misleading security claims. The 32-byte public key gets shuffled around with ephemeral key pairs as an opaque blob. The user verification is unfortunately disconnected from any trust and authentication. These are the hallmarks of vibe code (in)security.

Secure messaging systems do usually provide a way for users to establish trust, and that's what bitchat does not have right now.

Some possible mechanisms:

• QR codes
• Preshared keys
• Visual fingerprint verification ^
• Third party vending

^ Visual fingerprints are very tricky. For Telegram v1, I reported a problem with the SHA1 truncation to 128 bits, leading to a 2^64 birthday attack against the visual verification. It's possible to find near matches visually that may fool humans very easily as well. The current Telegram is still missing a lot of fundamental features, so I would actively discourage its use today.

The Favorites Identity System

However bitchat does have a "Favorite" system in which a client is supposed to forever store a Public Key/Peer Id pair. This is essentially trust on first chat, but there is no trust built into the protocol because the Identity vibe key doesn't authenticate anything.

The MITM Attack

The broken identity authentication/verification enables a trivial man-in-the-middle attacks with the "Favorites" feature

You're Alice.

1. An attacker intercepts and presents Bob's Identity Key, along with their own ephemeral pair
2. bitchat accepts this because it can't verify the ephemerals belong to the real Bob, as the Identity key does no authentication
3. You think you're chatting with Bob, one of your marked "favorites", since they have a Star.
4. The attacker pretending to be "Bob" asks you, Alice, about your favorite secrets
5. Devastatingly, you leak to the adversary

Then perhaps a little bit later the real bob shows up. This is how the rest of the conversation could go.

The Cryptographic Toolbox We Should Be Using

These problems are completely avoidable. We have battle-tested protocols:

• Signal Protocol: The gold standard via libsignal
• Noise Protocol Framework: Modern, flexible framework for secure communication
• OTR: Proven secure messaging protocol
• Existing Decentralized Solutions: Briar and Reticulum have already tackled decentralized messaging. I am not familiar with the insides of these but they are worth looking into working with instead of re-rolling yet another thing to lock down.

The Bigger Picture

BitChat illustrates a common pattern: it's fun to break ground and rewrite a path as if it's new, but cryptography and trust is treacherously easy to get confused about and notoriously difficult to write cleanly and securely due to fundamental security oversights and implementation issues. Secure messaging is largely a solved problem. We have the tools and expertise to build systems that are both decentralized and secure.

Thinking more deeply about this I think cryptography is the easy part. It will be the resilience to denial of service and electronic disruption that will challenge any decentralized communication mechanism when it's most needed.

Reporting The Issue

Moving Forward

For projects like bitchat:

1. Start with security fundamentals—identity/trust isn't optional with encryption.
2. Reuse proven protocols—don't reinvent the cryptographic wheel
3. Think like an attacker

Final Thoughts

In cryptography, details matter. A protocol that has the right vibes can have fundamental substance flaws that compromise everything it claims to protect.

For users: wait for more mature implementations that take security seriously. For developers: learn from others' mistakes. The tools for building secure, decentralized communication exist. Use them.