everyone knows that telegram owns the keys for communications in all non-secret chats, meaning it IS a point of failure and could be exploited by 3rd parties, which is the reason it is frowned upon in opsec-conscious circles. But everyone also knows that telegram has one of the best bot APIs, which can be proven empirically just by looking at the amount of user to bot ratio, no other messaging platform can even compete with this.Interestingly enough, it is not possible using regular tg tools to get your bot to make a secret chat.
I wish other platforms like matrix session or simplex took advantage of inline buttons just like in TG, but that will probably not come any time soon, feels like these platforms don't really give a damn about utility-diverse- bots, and its honestly a real problem, because it would so easily steal many users from TG . telegram as a platform also has advantages of a huge user base, so many of devs can't just ignore it.
some people on tforum suggested that you should make your users PGP their messages, which is honestly a bizarre idea, a non-starter simply because nobody is gonna do it.
another idea would be running a secure clearnet service which you'd send links of, into your bot. Something like privnote but self-made and self-hosted. It is not a too bad of an idea from UX perspective, except for the fact that you need to host it somewhere and make a secure environment, so nobody can trace you or exploit it. I think widening attack surface like that could be justified only if no other adequate options exist, which brings me to my next point.
My idea: what if developers utilized a combo of regular bot for everything non-sensitive like UX navigation, AND a selfbot with secret chat for sensitive content? that would solve a problem, at least partially. And i can easily see ways of implementing it seamlessly, making sure users don't even need to leave the app.
Now, an important remark needs to be made about the fact that to start a secret chat, you need to be contacts with the person, and by default if anyone in your contacts calls you, both of you share each other IPs. which is obviously problematic. so if you are using this setup it is important that you put the settings such that nobody can call the selfbot, and peer to peer calls are enabled to nobody.
What are your thoughts on this?
Interesting post. I believe we need to discuss strategies to expand DN usage to mainstream chat applications, because it's where the action is moving in 2025. I'm not even mad about PGP. You're right. It's definitively an obstacle to adoption and I can't wait we do better.
Nevertheless. I think the bottom line of running a shipping business through any kind of device should be actual, proven end-to-end encryption. As far as I remember, unlike Signal or Session, Telegram source code is at least partially obfuscated, meaning you just can't know for sure. In such a situation, PGP does great because you just have to post encrypted content on top of whatever messaging protocol to make it ultimately safe. That's not the only problem PGP allows to tackle. You need to provide proof of ownership over whatever channel you're building on, or impersonators will flow with phishing content. And obviously, even with adequate answers as for E2EE, you'll have a couple other issues to address, such as phone numbers, IP addresses, etc. But that's more something for /d/opsec to answer on.
Nevertheless. I think the bottom line of running a shipping business through any kind of device should be actual, proven end-to-end encryption. As far as I remember, unlike Signal or Session, Telegram source code is at least partially obfuscated, meaning you just can't know for sure. In such a situation, PGP does great because you just have to post encrypted content on top of whatever messaging protocol to make it ultimately safe. That's not the only problem PGP allows to tackle. You need to provide proof of ownership over whatever channel you're building on, or impersonators will flow with phishing content. And obviously, even with adequate answers as for E2EE, you'll have a couple other issues to address, such as phone numbers, IP addresses, etc. But that's more something for /d/opsec to answer on.
The only partially obfuscated parts in Telegram's client's code are the networking manipulations that prevent traffic to be detected as telegram communication, to fight censorship attempts from Russia and China.
And these parts still use messages from verified e2ee encryption code of secret chats.
There also have been independent audits from the community verifying E2EE functionality and general encryption of telegram
2021/2022
2023
TLDR: you don't need to trust telegram, you can look yourself. Obviously, this does not apply to telegram's servers, but in case of TG storing metadata there's nothing much we can do, and I'm personally fine with that sacrifice.
As to the pgp and integrity verification:
I certainly think that users should be able to have that opportunity and leaving it in the UI takes no extra effort. Users could also opt in for multiple methods of content delivery, with pgp offering like a 5% discount or something like that for the incentive
Also, I will make a post in a couple of days how I envision improving pgp user experience for wider adoption, thank you for hinting me on that :)
And these parts still use messages from verified e2ee encryption code of secret chats.
There also have been independent audits from the community verifying E2EE functionality and general encryption of telegram
2021/2022
Researchers at ETH Zurich conducted a deep dive into MTProto. They found several theoretical vulnerabilities (like the "HEM" attack), which Telegram subsequently patched. This audit is often cited as the most rigorous look at the protocol's underlying math.
2023
A team of researchers from the University of Udine (Italy) published a comprehensive formal verification of MTProto 2.0 in the journal Computers & Security. They used a tool called ProVerif to mathematically prove the protocol's soundness.They confirmed that MTProto 2.0 provides authentication, integrity, and confidentiality.
They also discovered a minor vulnerability to an Unknown Key-Share (UKS) attack in the re-keying protocol, which allowed them to highlight areas for improvement.
TLDR: you don't need to trust telegram, you can look yourself. Obviously, this does not apply to telegram's servers, but in case of TG storing metadata there's nothing much we can do, and I'm personally fine with that sacrifice.
As to the pgp and integrity verification:
I certainly think that users should be able to have that opportunity and leaving it in the UI takes no extra effort. Users could also opt in for multiple methods of content delivery, with pgp offering like a 5% discount or something like that for the incentive
Also, I will make a post in a couple of days how I envision improving pgp user experience for wider adoption, thank you for hinting me on that :)