Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Telegram - secure, free messaging

telegram.org

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Telegram - secure, free messaging

#161

Post by huhtenberg »

TelegramApp wrote: post #160
moxie wrote: post #141

The reason that cryptographers laugh at people who advertise "military grade cryptography" or "we use AES256" is because the choice of crypto primitives is often less important than how they're composed. Those phrases tend to reflect a critical misunderstanding of that, and often mean that a project is using secure primitives in a way that completely undermines their security. At a glance, while this project is using…

Two questions for you: 1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know. 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE. Thank you fo…

> this protocol is the result of thougtful and prolonged work of professionals.

Pray tell, why replay protection is done after decryption.

Re: Telegram - secure, free messaging

#162

Post by TelegramApp »

huhtenberg wrote: post #161
TelegramApp wrote: post #160

Earlier quoted context omitted.

Two questions for you: 1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know. 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE. Thank you fo…

> this protocol is the result of thougtful and prolonged work of professionals. Pray tell, why replay protection is done after decryption.

In terms of DoS possibilities, one doesn't need to replay old messages, they could just as easily send new ones or random garbage.

We could employ additional filtering techniques, but that increases processing time. And since modern hardware allows for very fast AES decryption, there is no particular gain in building additional layers of protection.

All that, naturally, implies that other anti-DoS measures are also being used.

Re: Telegram - secure, free messaging

#163

Post by yeukhon »

lazyjones wrote: post #61
yeukhon wrote: post #53

> Telegram is decentralized! Great. Then... > Telegram servers are spread worldwide for security and speed. So this is what they mean by decentralized.... > As a result, Telegram is the fastest and most secure messaging system in the world And this has exist for how many years? I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch se…

> I can probably say everything except private message, google hangout or Facebook chat is already doing it. They have some of the top-notch security, network and distributed system developers ... and they are based in US of NSA - no thanks.

As an American I fear the NSA but at the same time to be fair, NSA is not the only intelligence doing this sort of work. Let's be fair, every other governments are doing similar things anyway, so maybe we should say no thanks to every other website.

Re: Telegram - secure, free messaging

#164

Post by moxie »

TelegramApp wrote: post #160
moxie wrote: post #141

The reason that cryptographers laugh at people who advertise "military grade cryptography" or "we use AES256" is because the choice of crypto primitives is often less important than how they're composed. Those phrases tend to reflect a critical misunderstanding of that, and often mean that a project is using secure primitives in a way that completely undermines their security. At a glance, while this project is using…

Two questions for you: 1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know. 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE. Thank you fo…

> 2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE.

IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an authenticating encryption mode that works, which recently culminated in modes like OCB and GCM. I don't see any integrity protection documented anywhere in your protocol spec, so if you're relying on IGE, it's broken.

What's more, any "problems" with CBC (I assume you're referring to padding oracle attacks) are not specific to CBC, and are endemic to IGE as well.

> The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals.

I don't think their academic credentials or the amount of time they spent on this are the important metrics. If you're trying to suggest that they're thoughtful, the best metric for demonstrating that would be something like a proof for the (honestly naive-looking) KDF they made up.

In essence, the protocol seems to reflect many choices that anyone familiar with the field can immediately identify as suggesting a lack of understanding. It could be that these are simply brilliant moves that we non-ACM champions are too primitive to understand, but if that's true, you need to justify them with proofs in order to support them. Otherwise we're going to interpret them for how they appear.

> Thank you for the offer to join in the project you represent. However, we feel that what we are doing is going in a somewhat different direction and has its own potential.

Could you describe how your projects objectives are inconsistent with a protocol ratchet like Axolotol or the full TextSecure protocol?

Re: Telegram - secure, free messaging

#165

Post by oakwhiz »

dchest wrote: post #30
oakwhiz wrote: post #28

Earlier quoted context omitted.

HTTPS is fine, it's just all the x509 surrounding it that people are upset about

No, it's not fine. Currently the only secure version of TLS is 1.2 with AES-GCM; and it's still not deployed widely.

I stand corrected

Re: Telegram - secure, free messaging

#166

Post by ohwp »

ge0rg wrote: post #135
TelegramApp wrote: post #129

Earlier quoted context omitted.

That is correct, Telegram does upload names and numbers — naturally, after receiving permission to do so. (see also: http://telegram.org/privacy ) Apart from identifying Telegram users among the user's friends, this also enables us to use proper names in notifications on the iPhone, as well as facilitates moving between devices. But you have highlighted an important issue. Our android developer relied on the system p…

naturally, after receiving permission to do so. This is not quite true. I never gave anyone (especially not the users of WhatsApp or Telegram) permission to upload my personal information to any cloud services. You can not actually imply that permission from all contacts merely by asking the user. this also enables us to use proper names in notifications on the iPhone I do not know enough about the iOS internals, but…

"I never gave anyone (especially not the users of WhatsApp or Telegram) permission to upload my personal information to any cloud services."

On Android you do by granting rights to access your contacts and give full network permissions. So you never know what a program will do with your contacts and a network connection.

Re: Telegram - secure, free messaging

#167

Post by eliteraspberrie »

The authors' education credentials are impressive, and I admire their initiative. However, they do not seem to have employed a cryptographer to review their design and protocols, so I expect that serious security problems will be discovered.

Personally, my expertise is rather in application security, so I will review some of the source code over the holidays. At first glance the C client is not bad.

The real metric of this project's success will be how they react to criticism, harsh as it may be. I hope they learn from their inevitable mistakes and succeed in the long term.

Re: Telegram - secure, free messaging

#168

Post by mahyarm »

salient wrote: post #139
utnick wrote: post #120

A lot of haters in this thread. To be expected. I've been following this space for a while and telegram is the best app out there right now. The usability is great and they are trying to do the right things when it comes to security. The apps are open source and can be audited. I fully expect there to be bugs, that is part of the process! You would be insane to trust your life to a crypto app thats been around a few…

They are making a lot of bogus claims using marketing speak, and they are very low on details, while saying the app will be opensourced "eventually". For a "security" app, hell yeah you should be skeptical. Right now I think the most interesting and most trustworthy secure messaging projects are TextSecure v2 and Dark Mail (granted, that one isn't even out yet, their ideas so far sounded quite good).

But the clients are open sourced: http://telegram.org/source

Re: Telegram - secure, free messaging

#169

Post by micheljansen »

TelegramApp wrote: post #92
micheljansen wrote: post #73

Earlier quoted context omitted.

In this case, even if you remove the ad-hominem attack (a bunch of randoms), a valid point remains: implementing crypto is already notoriously difficult, let alone designing cryptographic protocols.

Still, there are sometimes valid reasons for not re-using existing solutions. In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability. Disclaimer: I work for Telegram.

Absolutely, just trying to point out that the original poster raised some valid points that didn't deserved to be dismissed as "ad hominem". I haven't had a chance to dissect your work (but appreciate that you have made that possible in the first place) and I believe extraordinary claims require extraordinary scrutiny :)
Post reply on HN