Hacker News Reader

Comment by hnarn | Hacker News Reader

There's so much FUD here about how this must mean Telegram is now insecure, backdoored etc. I sure hope those voicing these opinions actually have used Telegram and understands how it works:

- Telegram does log chats server-side if you want them to (to be able to see your chat history across devices). You don't have to. Telegram supports end-to-end encryption ("secret chats") with no logging -- as far as I know there is no proof that these chats are untrustworthy.

- Telegram groups have never been sacred and they are deleted if they spread illegal information. This is not the same thing as leaking someone's personal chat history, which to my knowledge has still never been done.

I'd be glad to be proven wrong on any of these counts, I use both Telegram and Signal and trust the latter more for obvious reasons (it's completely open source) -- but the fact that Telegram is not perfect in every way does not make it insecure by default.

View on HN

The Pentagons guideline for secure military conversations allowed to chose between threema, whatsapp or signal - but they explicitly forbid usage of telegram.

At the time I knew about the voice call remote exploit in whatsapp due to their outdated hardfork, and I knew about the XSS RCE bug in signal’s innerHTML mess... so my personal assumption is that telegram is the only messenger where five eyes has at least no protocol level access and have to exploit the OS it is hosted on.

You can meanwhile look that information up on vault7 or snowden leaks, so it’s already publicly disclosed.

Anyways, if you feel safe using a stock Android ROM that isn’t AOSP and is still using legacy 3.x or 4.x kernels... your general assumption on what is secure is wrong.

Having said that, I don’t know whether palantir’s gotham has access to telegram’s servers. But given their workforce and sheer amount of RE they hire, the likeliness of telegram being a target is very high.

So with all that in mind I’d recommend telegram only with AOSP head and only with secret chats. You don’t stand a chance if you are using the public clearnet routing protocols either way.

And this is assuming that you don't use Windows and something like a hardened Kali or Arch-based distro that is updated regularly and uses both a secure transport layer for pacman and doesn't allow "some random guy's" gpg signatures, aka you'd have to manually check every source from AUR. If you use Windows 10, you can forget security. If you use Ubuntu or Debian, you can forget security. If you use Steam, you can forget security. If you play any networked games on any of your machines, you can forget security.

Joyful times where private organizations with nearly unlimited resources "hack the planet" and seemingly get away with it.

Is it really Clearnet if there is end to end encryption?

If I run applications as a different user or in a chroot without root access how can there be security issues for any other users even if it's some game running through steam

> chroot

Personally I wouldn't trust chroot alone. There were some privilege escalation bugs available in the past from "forgot to sandbox the cwd" [1] to more sophisticated exploits via "nsswitch in docker" [2].

But, of course, given the amount of bugs I'd say that chroot is as secure as it can get. But always take everything with a grain of salt, chroot developers also make mistakes, like everyone.

The problem with chroot is not chroot itself, but all the libraries linked in the binaries. And if I know any statement to be true, it's that game developers on Steam don't give a damn about correctly linking anything. I mean, they even don't get 64bit right. And we have 64bit architecture mainstream since 2005 or so...

[1] https://github.com/aykit/chroot-privilege-escalation

[2] https://nvd.nist.gov/vuln/detail/CVE-2019-14271

> If you use Ubuntu or Debian, you can forget security

Why do you say so?

> Why do you say so? (about Debian/Ubuntu)

Critical security fixing time is years, not days. Also in practice, a lot of people use PPAs to get work done, and this is a critical component in an audited system.

This is absurdly untrue.

> This is absurdly untrue.

I’m just gonna leave these here:

[1] https://security-tracker.debian.org/

[2] https://security.archlinux.org/

...then everyone can compare upstream/downstream fixing times for themselves.

Remember: “not yet assigned” is equivalent to “not fixed”.

> so my personal assumption is that telegram is the only messenger where five eyes has at least no protocol level access and have to exploit the OS it is hosted on.

This is a very strange assumption, you mean that the "Pentagons guideline for secure military conversations" is actually not a guideline for secure conversations, but exploitable conversations?

Why would the Pentagon tell their own people to use exploitable communications? There's no way of knowing if you are the only one with the capability.

In my eyes this information (which I haven't verified and don't have time to dig into) would rather indicate that the Pentagon believes Threema, WhatsApp and Signal to be secure while they are doubtful about Telegram -- maybe because they know something we don't, or simply because it's harder to audit.

The underlying question really is when the point is reached between "security through trust" and "security through audit".

I'm not anyhow claiming that Telegram is secure. But given the problems that legal courts have when the FBI and other three letter agencies want to get access to Telegram data (and the fact that the company moved their HQ around Europe every time a state wanted access) seems to me much more trustworthy than say, any Facebook software.

And I would also argue that given the fact that Gotham has full administrative access for anything Facebook sends and that the end-to-end encryption cannot be verified as both clients never actually connect directly would speak also contra WhatsApp when it comes to their security claims. (install a Firewall on Android and you'll see the whatsapp gateways/proxies).

To be honest, I doubt that the Pentagon would trust any software without having seen its source code or at least having full access to the data that's transferred. And I think that's a fair assumption.

The underlying issue is that the field of security has is actually that it's not a field of trust - but rather a field of mistrust. Currently I'm mistrusting the Pentagon more than some random dudes I've never seen; which might be the actual point of the discussion: Can we trust the Pentagon given their fuckups in the past?

> that is updated regularly and uses both a secure transport layer for pacman and doesn't allow "some random guy's" gpg signatures, aka you'd have to manually check every source from AUR.

To be fair, all three of those are the defaults on any distro I've ever used. You have to say explicitly "no, I do not want to inspect this PKGBUILD file" in pretty much every AUR helper (and it's worth noting AUR helpers aren't even the supported way of building AUR packages).

> Telegram supports end-to-end encryption ("secret chats") with no logging -- as far as I know there is no proof that these chats are untrustworthy.

The argument I've heard is that Telegram uses their own encryption protocol. The rule of thumb in cryptography is "don't roll your own crypto".

The reason why that statement exists is because there are _countless_ examples of teams coming up with their own, new cryptographic mechanisms that either break (intentionally or not) or were written with a backdoor. People get incredibly clever when it comes to breaking encryption.

AFAIK the only way to be on the right side of this argument is to use a time-tested encryption protocol. However, there are even instances where some protocols have been live and in production for x years before discovering that a backdoor has been in the code since day one.

This is a fun phrase, that as a non-crypto person seems reasonable, but I always wonder if there's something of a confirmation bias.

> The reason why that statement exists is because there are _countless_ examples of teams coming up with their own, new cryptographic mechanisms that either break...

But aren't there _countless_ examples of this in crypto made by cryptographers?

I'm not playing devil's advocate, I don't really have a stake here. :)

Not a crypto expert either, but from what I've gleaned listening to e.g. Peter Guttman describe evaluating new crypto mechanisms, you'll see that:

1. Actual cryptographers usually design with a set of constraints that make their crypto work: those might be about compute power, or memory bandwidth, or what have you, that make an algorithm difficult to brute force.

2. The algorithm will typically be peer-reviewed to try to weed out mistakes, either fundamental mathematical ones, or in the assumptions.

3. The implementation then needs to be high quality.

There are certainly no shortage of examples where systems which pass 1 & 2 are undermined by failures in 3. All algorithms are susceptible to the context around 1 changing (changes in compute power or whatever).

When you go it alone, you're assuming that you won't make any mistakes any of these. That seems a pretty tall order.

The principle is that cryptography is so hard that even the experts screw up, but non-expert chances of screwing up are so much greater.

I would phrase it more as "there is no margin of error in cryptography".

In machine learning, a model that works 90%, 95% of the time is pretty good.

A glitchy video game can still be fun as long as the glitches don't happen too often or cause a loss of too much progress.

Even a filesystem that doesn't lose most people's data, most of the time, will have a lot of adherents.

But if your cryptography implementation isn't completely perfect, it's frequently just 100% useless for its intended purpose.

What really sets cryptography apart is that for a non-expert, there is no way to tell whether it's correct or not. Most bad software has bugs that can be found by users. A bad ML model will do poorly in validation.

But a bad crypto implementation will work. For all intents and purposes, it will appear completely fine. Users will get their messages. The bitstream will appear completely random. At least, until somebody with expertise in breaking crypto systems digs into it.

Also notable is that it can't be fixed or patched in the way you'd expect for any other software -- once it's found broken, everything that ever used it is now broken unless they're re-encrypted. There's no migration path to the fixed version

>But a bad crypto implementation will work. For all intents and purposes, it will appear completely fine. Users will get their messages. The bitstream will appear completely random. At least, until somebody with expertise in breaking crypto systems digs into it.

And that applies even if they're using AES but wrong mode of operation. That applies even if they're using best practices like AES-GCM but the CPU doesn't support AES-NI and a cache timing attack allows key exfiltration.

Like Swiftonsecurity wrote:

"Cryptography is nightmare magic math that cares what kind of pen you use. Should math care what kind of pen you use to implement it? No, but Fuck You, this is Cryptography."

The attacks are incredibly subtle for even the best systems, and Telegram is so far away from even adaquate it's difficult to emphasize it so I'll try with my best restraint:

TELEGRAM FUCKING LEAKS EVERY GROUP MESSAGE TO THE SERVER WHICH IS THE EXACT EQUIVALENT OF A FUCKING BACK DOOR.

I hope that didn't leave anything unambiguous.

Group messages on Telegram and normal messages are explicitly not encrypted in order to allow multi-device operation. That is explicit. I don't see how that has anything to do with the security of MTProto.

If Telegram crypto actually worked, they'd make far more money licensing the crypto than just running a chat app.

Assuming that money is what they’re after. Are you reading Durov’s channel on Telegram? Also, having invented the Russian Facebook and forcefully selling it to the Kreml - I don’t think he needs any more money. He’s playing a totally different game. I don’t know which one though.

Who would buy the licenses? In a world where the libraries for the Signal protocol are free, lol.

Pavel Durov is so mindboggingly rich that he had a good shot at being a Russian oligarch, and decided not to. I don't think that's an argument.

MTProto 1 was the problematic protocol that continues to haunt Telegram despite its deprecation for MTProto 2 which is built on standard crypto primitives.

The thing about crypto is that it works in pieces. I'm sure it takes 12+ libraries to make an end-to-end encryption work. Signal has this same problem.

> The rule of thumb in cryptography is "don't roll your own crypto".

This phrase is tiring to hear in this form, and your understanding seems to be incomplete here. Signal also rolled its own crypto, but you don’t see anyone saying it’s insecure for that reason. That phrase is used to tell non-cryptographers not to roll their own crypto because of the high chances of vulnerabilities being introduced. In the case of Telegram, the company defends its protocol saying that it’s been created by people with PhD in mathematics (which is related to and is foundational for, but different from, cryptography). Telegram’s encryption protocol (the second version) has not been broken by anyone till date.

>In the case of Telegram, the company defends its protocol saying that it’s been created by people with PhD in mathematics (which is related to and is foundational for, but different from, cryptography).

It was created by Nikolai Durov who has a PhD in geometry. That's like a gynaecologist performing brain surgery. Specialization matters. Sure both took human anatomy 101 class in college, but somewhere along the way they went and spend their ENTIRE career doing different things. It's easier to get another decree in medical science sure, but in this case the gynaecologist did not, they just started cutting the brain with kitchen knife and just because their patients haven't died yet doesn't mean they have the credentials to abandon best practices.

> Telegram does log chats server-side if you want them to

Trying to assume good faith here that this is accidental and not trying to deliberately mislead but the way this is phrased strongly implies that server-side logging is off-by-default. It is not.

Nor are secret chats prompted or prominently advertised in the UI (it's the 2nd option when you go to create a new group, never seen when initiating new 1:1 conversations).

I would wager most Telegram users don't know about secret chats, or if they have heard of them they probably assume they're on by default.

> but the fact that Telegram is not perfect in every way does not make it insecure by default.

It literally does though.

Right. It has the ability to opt-in to E2EE messaging, but by default it's insecure.

- Telegram does NOT support E2E encryption on their desktop and web version of the software.[1]

- Telegram requires a phone number and in my country for example it is tied to you (yes, you need to sign a contract for even a prepaid SIM card).

[1] https://tsf.telegram.org/manuals/e2ee-simple

Also,

- Telegram does NOT support E2E encryption for group chats on any platform.

- Telegram does not use E2E encryption for ANYTHING by default.

"Telegram does log chats server-side if you want them to"

No. Telegram forces you to log all Windows / Linux desktop client chats and all group chats to their server. You don't have a choice with those. Also all chats in general are logged by server by default.

For Signal, the server being able to eavesdrop on 100% of group messages would be complete failure, a backdoor that would cause everyone to abandon Signal. For Telegram it's the primary design principle. So Telegram is in fact bacdoored by design.

>Telegram groups have never been sacred

Yeah it says that right there on the front page. This "obviously" propaganda actually hurts people, and not just in the way I die a little inside from reading it

> This is not the same thing as leaking someone's personal chat history

This is no standard of anything. "Oh it's fine that Telegram and anyone who hacks their server spies on you, it's only problem if they intentionally leak your chat history". Screw this kind of thinking.

>which to my knowledge has still never been done.

I've never seen such moving of goal posts in my life.

>I'd be glad to be proven wrong on any of these counts,

You can't just define the context to your liking and then prance about when nobody can win the argument of your rigged rules.

>but the fact that Telegram is not perfect in every way does not make it insecure by default.

This is called nirvana fallacy. Signal isn't perfect either. But it's at least E2EE by default which is the norm these days.

Your comment is not thoughtful at all, it's indistinguishable from shill arguments. I hope you feel ashamed.

For profesional cryptographers and security experts, it's enough the first protocol wan't IND-CCA secure. That alone tells the professionals the app is no good to any extent. Telegram loses at that point and it'll never advance to some next round. There will never be a community based code review or stamp of approval, that ship has sailed. The developers have lost face permanently.

The evidence of this is no professional cryptographer has recommended Telegram at any point. Instead, world-renowned experts like Schneier and Matt Green have adviced against using Telegram. There's nothing Telegram developers or the community can ever say that undoes expert opinion.

Reply on news.ycombinator.com