Verification in band seems pretty meaningless, approaching security theatre.

For voice? It's hard to fake the voice of someone you know.

you don't have to fake the voice, just mitm and record cleartext

But they have to fake the voice, if I call the other person and say "my emoji sequence is this, this and that" for the other person to verify and vice-versa.

Person A calls you. I intercept the call, so person A is calling me, and then I call you (spoofing so I look like Person A). When you pick up, I pick up, then I transmit what you're saying to Person A (and vice versa).

How do you know I'm intercepting the transmission? Does the emoji sequence verify the call, perhaps?

The emoji sequence is a hash of the secret key values generated as part of a modified/extended version of the Diffie-Hellman key exchange. The emoji sequence is generated and displayed independently on both devices before the final necessary key exchange message is transmitted over the wire, so a man-in-the-middle has no way of modifying messages in flight to ensure that both parties end up generating the same emoji sequence.

I'm not a cryptographer, but that's what I glean from their explanation: https://core.telegram.org/api/end-to-end/video-calls#key-ver...

The emoji sequence represents the secret key exchange between you and the other party. If you intercept the call, you are making one key exchange with person A, and another key exchange with person B. Due to the mathematics involved, there is no way for you to force both key exchanges to yield the same result.

For a "standard" DH key exchange it would be possible to brute force the emoji sequence to be the same (since it's too short to be resistant to brute forcing), but the protocol that Telegram uses specifically defends against that by having both sides commit to their share of the key ahead of time, so they cannot try different numbers.

https://core.telegram.org/api/end-to-end/video-calls#key-ver...

So person A and person B are going to see different emojis no matter what you do. To fake a phone verification while performing a main-in-the-middle attack you'd also have to fake their voices to each other. That's hard.

Both connections would show different emojis on both sides then. So you would need to somehow deep fake the voice of the one telling their emojis to the other one.

If i'm talking to a person I know in person, I'd recognise their voice.

Real privacy is too burdensome for most users, so they feel just fine if the service owner promises in a stern voice that their chats are really secure.

It is not necessary to provide real security, do fingerprint verification, etc if the users are already happy with the level of security they are promised.

The emoji comparison thing is mathematically solid. Assuming the clients aren't backdoored (and the Telegram client is open source, so that's not that easy), there is no way for an attacker to make both sides show the same emoji. If they want to convince two users that they have en E2EE connection while performing a man in the middle attack, they'd have to fake their voices to each other to change what emoji sequence they each read out. That's hard, and therefore this is real, meaningful privacy.

Telegram can potentially perform mitm at any time and generate matching emoji images for both sides of conversation, since you can't really trust the app code to be the same they put on GitHub. If you've built it yourself, that'd reduce the risk, but nobody does that because blind trust is much more easy.

This is true, and IMHO somewhere that App-Stores could potentially assist in building trust for OSS Apps being distributed.

What I'm envisioning is a 'build hash' that is reproducible based on the public source code with a given set of compiler settings (i.e. same used for publish.) The systems app-management widget could then display this build hash in the app-check menu.

This would likely require more care in packaging, as well as some form of secure config API that allows companies to provide certain bits of configuration (i.e. remote servers to contact) without impacting the build output. This would mean that yes, people would still need to audit the code, but at least it's easy for anyone to canary out to the internet that the hashes are mismatching, same for when someone does find something on an audit.

OTOH, I'm sure Telegram's competitors in the chat space would love a reason to de-legitimize them, so it wouldn't surprise me if -someone- out there was already doing some sort of compare on published builds.

It is not, by default, and none of the group chats are.